Translation Table

Designer Administrator
This manual is in pilot operation.

Translation tables are used for code conversions associated with data imports using forms. The contents of a translation table consist of a table showing the relationship between source codes and target codes. Which translation table is used for the import process of which form is specified by the designer in the Import Specification of the form.

Translation tables have broader applications than might be inferred from their name, such as:

  • Filtering data to be imported

  • String operations on codes in import data (such as extracting the top x digits, the bottom x digits, etc.)

The types of translation tables used in the application are determined by the designer. Any number of translation tables can be set up within a single application. The specific conversion rules (source/target code correspondence table) of each translation table are maintained by the administrator or the operational personnel (the default table by the administrator, custom tables by operational personnel—see below).

Custom and Default Tables

Designers can specify whether to allow the creation of "custom tables" for each translation table. A custom table is one that each business unit can maintain independently (users with operational authority in each business unit can maintain it). The contents of custom tables are retained separately for each business unit.

Even if the creation of custom tables is allowed, administrators can provide a "default table" common to all business units. Each business unit can choose whether to use the default table or to create its own custom table.

If the creation of custom tables is not allowed, the default table is maintained by the administrator and applied uniformly to all business units.

Case Sensitivity and Normalization of Source Code Values in Conversion

In code conversion processes, the case of letters is not distinguished. Both the source and target code patterns in the translation table are registered in uppercase.

Before applying the translation table, the source codes on the import data are formatted as follows:

  • Spaces before and after are removed.

  • Lowercase letters are converted to uppercase.

Wildcards

Both the default and custom tables consist of a correspondence table between source codes and target codes. Wildcards '?' and '*' can be used in the columns for source codes and target codes.

Using Wildcards in the Source Code Column

When wildcards are used in the source code column, '?' matches any single character, and '*' matches any length of characters (including an empty string).

Using Wildcards in the Target Code Column

When wildcards are used in the target code column, they replace the characters or strings matched by '?' and '' in the source code column.
When multiple '?' and '
' are used in both the source and target code columns, '?' in the source code column corresponds to '?' in the target code column, and '' in the source code column corresponds to '' in the target code column, in order from the front.

The ability to use wildcards means that a single source code can match multiple rows (conversion rules) in the correspondence table. In this case, the row nearest to the top of the table is applied.

Filtering Target Data (Skipping)

If the keyword #IGNORE is set in the target code column, data matching that row is skipped. This can be used to filter the data to be imported.

Please also see Example 2 in the "Specification of Conversion Rules" below.

Examples of Specifying Conversion Rules

Here are examples of specifying conversion rules using wildcards:

Example 1: Adding a Prefix
Source Code Target Code

*

PL*

The code "1234" matches the above source code, and the conversion result is "PL1234" (where * = 1234).

The code "12345" also matches the above source code, and the conversion result is "PL12345" (where * = 12345).

Example 2: Filtering Based on Top x Digits
Source Code Target Code

12????

12????

*

#IGNORE

The code "123456" matches the first row’s source code, and the conversion result is "123456" (the first ? = 3, the second ? = 4…​..).

The code "223456" does not match the first row’s source code and matches the second row’s "*", thus (by #IGNORE) the data including this code is skipped.

The code "12345" is also skipped (because the first row’s source code requires four characters following "12").

Example 3: Extracting the Top x Digits
Source Code Target Code

????*

????

The code "123456" matches the above source code, and the conversion result is "1234".

The code "12345678" also matches the above source code, and the conversion result is "1234".

Example 4: Extracting the Bottom x Digits
Source Code Target Code

*??

??

The code "123456" matches the above source code, and the conversion result is "56".

The code "12345678" also matches the above source code, and the conversion result is "78".

Example 5: Removing the Bottom x Digits
Source Code Target Code

*??

*

The code "123456" matches the above source code, and the conversion result is "1234".

The code "12345678" also matches the above source code, and the conversion result is "123456".