1      Business context

Currently, both currency translation and consolidation processes will consolidate data according to what is the storage type for the model, periodic or year to date (YTD). In other words, in a periodic model, both currency translation and consolidation will process periodic data, resulting in a periodic consolidation. In a YTD model, YTD data will be translated and consolidated. In a generic way, the consolidation process is using the physically stored data of that model to generate the consolidated results. However, it turns out that some customers need to consolidate numbers using periodic translation and consolidation, even though their model is defined and stored as year to date data.

As far as periodic translation is concerned, the current engine can manage all cases as translation rules are account based on the one hand, and each rule applied to an account can use a Periodic calc flag which is useful in a YTD model where a periodic translation is required.

However,when looking at the whole consolidation process, 3 main steps can be identified, one of which is not fully supporting periodic calculation, as shown below:

Generally speaking, in a YTD model, there is only one step for which we do not support periodic processing, which is the second step in the translation process. On top of that, it must be noticed that this step is not really about currency translation, as its current purpose is to integrate translated amounts into the consolidation.

We will from now on call this step INTEGRATION (See SAP Note 1665088 - Integration mode in consolidation)

2      Enable Integration mode in consolidation

 Before enable Integration mode in consolidation, users should first upgrade to BPC 10.0 NW SP05 or later support packages. Currently the integration is only supported for BPC NW version.

To enable Integration mode, from start page, navigate to administrator page.

Find the related model. Please notice that only the consolidation type model can be enabled with integration mode.

Select the check box for ‘Consolidation –Use Integration Rules’, and save the change for this model.

3      How integration mode works in consolidation

3.1   Currency translation

When integration mode is enabled for one particular model, the behavior of currency translation would be changed accordingly.

The currency translation would only translate the transaction data from local currency to reporting currencies (decided by the group currencies of the given scope/group). But it will not post data to group level any more. This step is just the one mentioned in section 1 and will be done by integration instead of currency translation.

The following example will show the change.

In previous release, or in consolidation model without integration mode, image we have the following transaction data:

The hierarchy would be looked like this:

CG1                      (group currency USD)

└-- CG2                (group currency EUR)

                         └--- C1000

And the business rule would be the simplest one using [END].

When after run currency translation for scope CG1, the result would be:

If the integration mode is enabled, then only the first two records for reporting currencies (scope dimension remains G_NONE) would be generated after currency translation.

 3.2   Elimination and Adjustment

As mentioned above, the step 2（Copy translated G_NONE data to G_CG1 and G_CG2） would be done by the new introduced Integration business rules which will re-use the framework of Elimination and Adjustment rules.

A new type of Elimination and Adjustment rule will be introduced for Integration.

3.1.1     Rule definition

3.1.1.1       Rule type

For a model NOT enabled with Integration mode, there will be 5 different rule types when create a new elimination and adjustment rule.

When a model is enabled with integration mode, then except the generic type (blank), other types like E/P/N/L would be hidden. And a new type with ‘I’ (Integration) would be added to the rule type.

When a model is enabled with integration mode, the previous defined business rules with type E/P/N/L will be hidden, and will not be taken into consideration during the calculation. When the integration mode is disabled, these rules will appear again.

3.1.1.2       Rule with integration type

The integration rule definition re-uses the framework of Elimination and Adjustment rules, but has some differences:

• Destination audit member (former data source) must be blank. As a matter of fact, data are to be integrated to the same destination audit member as the source one.
• Method based multipliers to be used for that rule must have ‘99’ as the intercompany method. No other value is permitted.
• Entity property filter is disabled
• Other dimension filter is disabled
• Force destination member is disabled
• In rule details:
  • Force interco member id disabled
  • Swap entity interco is disabled

Please notice that these fields are not disabled in the UI directly. But when save and validate the rule, these fields would be checked.

3.1.1.3       Rule calculation

When integration mode is not enabled (traditional case), the consolidation engine would read translated data from group level, and use these data as input of consolidation logic.

When integration mode is enabled, the consolidation engine would read translated data from reporting currency (group currency) directly, instead of from group level. That’s why in integration mode, the currency translation would not post data to group level any more.

The integration rule re-uses the original calculation framework of elimination and adjustment, so the calculation logic would be almost the same. Actually the execution of integration rule could be treated as a generic rule with the limitation mentioned above.