Assume that monthly expense amounts by business unit, department and account are imported. The Key Fields consist of Fiscal Year, Month, Business Unit, Department and Account, followed by the Value Field "Amount". The data used in the explanation is shown below:

(Fiscal Year) (Month) (Business Unit) (Department) (Account) (Amount)
2016, 05, 10, 111-22, 12345, 1000

⚠ In the explanation below, "Amount" is assumed not to be defined as a Data source field. That is, Amount is treated as an "Implicit Value Field". Even if Amount is explicitly defined as a Value Field, the essence of the explanation below does not change (the Amount field simply becomes one of the Data source fields).

The label of the import destination ledger is "EXPENSE". For each dimension that composes this ledger, the member label setting requirements at import are as follows:

When one import data record is read, first, the values of each Key Field from the import data are set to the "Data source fields" defined in the Import Specification. Each field has two areas: "Pre-translation Value" and "Post-translation Value". At this stage, values are set to the "Pre-translation Value".

Regarding how to assign Field Labels:
For fields whose "Post-translation Value" directly becomes the member label of a dimension used in the target ledger, set the Field Label to the label of that dimension. In this example, Fiscal Year (#FY), Relative Period (#PERIOD) and Accounts (#ACCOUNT) fall into this category.

For other fields, assign Field Labels that are different from Dimension Labels. In this example, Business Unit (DIV) and Department (DEPT) are such fields.

In the next step, Translation Tables are applied to the "Pre-translation Values" of each Data source field, and "Post-translation Values" are obtained. For fields for which no Translation Table is specified, the Pre-translation Value is used as-is as the Post-translation Value.

In this example, Translation Tables TBL_PER and TBL_DEPT are applied to the fields #PERIOD and DEPT, respectively. Their contents are as follows:

Up to Step 2, member labels for the dimensions #SCENARIO, #VIEW, #CHANGE and DIV_DEPT are not yet determined. Therefore, in the Import Specification, Derived fields with these Dimension Labels are defined so that member labels can be determined.

By setting appropriate expressions in the "Expression" field of each field, the "Pre-translation Value" of each field is calculated according to the expression.

The Pre-translation Values of Derived fields can be set as fixed values as shown for #SCENARIO, #VIEW and #CHANGE above, or calculated from the values of other fields as in the DIV_DEPT field.

The expression DIV & DEPT specified for the DIV_DEPT field in the figure above means concatenating the Post-translation Values of the DIV and DEPT fields. Note that expressions always reference Post-translation Values.

Next, Translation Tables are applied to the Pre-translation Values of Derived fields to obtain Post-translation Values. For fields for which no Translation Table is specified, the Pre-translation Value is used as-is as the Post-translation Value. Except that the target is Derived fields, this processing is exactly the same as in Step 2.

In this example, the Translation Table TBL_DIVDEP is applied to the field DIV_DEPT. The contents of this Translation Table are as follows:

In this example, there are no Derived fields that reference other Derived fields in their expressions, so at this point, the "Post-translation Value" fields for all fields are filled. If there are Derived fields that reference other Derived fields, Step 3 and Step 4 are repeated until the "Post-translation Value" fields for all fields are filled. Note that expressions that cause circular references among Derived fields are not allowed and are checked as errors when the form is registered.

By Step 4, the "Post-translation Value" fields for all fields are filled. As the final step, treating the "Post-translation Values" of fields that have the same labels as the dimensions of the target ledger as member labels, the cell values of the target ledger (specified in the Import Specification) are updated with the Post-translation Values of the Value Fields.

If there are multiple import data records for the same member label combination, amounts and numbers are accumulated, while non-numeric cells are overwritten with the last value.

If the calculation result of an Expression or the translation result from a Translation Table becomes the value #IGNORE (string), the data of that Value Field in that row is skipped and excluded from writing to the ledger. Refer also to the Translation Table description.

This includes cases such as code translation errors, field values with the same labels as the dimensions of the target ledger being inappropriate as member labels and data outside the import range being included without being skipped.

Of the two types of exception handling above, "Intended Exception Handling" takes precedence. That is, rows skipped by Intended Exception Handling do not result in errors even if they also meet conditions for unintended exception handling such as code translation errors.

In all cases, messages and a code representing the severity of the exception (#SEVERITY) are displayed in the import processing log. In case (1), the value of #SEVERITY is INFO. In case (2), depending on the severity, it is WARNING or ERROR.