1      Business context

Currently,both currency translation and consolidation process will consolidate data according
to what is the storage type for the model, periodic or year to date. 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 stores 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.

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 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.