The Power of Mapping Sets

Did you read the GL data conversion post? Good. It provides the context of what follows next.

I'll now dive deeper in how the FAH setup on this implementation looked like.
Was it that spectacular? Not really. I was trying to build a working system, and not a fireworks show.
So I kept it simple... which makes it a pretty nice case to share.

We only required the IFRS accounting method within FAH, and used PeopleSoft General Ledger to translate from IFRS to local GAAPs.

Don't be afraid to click the illustration!

Note: I've left out some of the accounting flexfield segments, and also most of the Mapping Sets, in order to present a more comprehensible picture.

For each of the six source systems, I set up a separate application, and Application Accounting Definition. You might recognize this as rule number one of the FAH design guidelines.

Then within each Application Accounting Definition, I set up a single Journal Lines Definition. That's indeed rule number two of the FAH design guidelines.

Now onto rule number three: re-use of components within the rules design.

The source systems all presented their data in such a way that a single debit and a single credit Journal Line Type was required.
I tried to share as many Account Derivation Rules as possible across each source system’s debit and credit Journal Line Type.

For the Insurance system, this was possible for all the Account Derivation Rules.
For most other systems, I used a mixture. The payroll systems for instance could do with a single Account Derivation Rule for business unit and product, while the account and cost center derivations required separate debit and credit rules. That’s because these source systems presented the input for those Account Derivation Rules in separate columns.

As the Application Accounting Definition components are application specific, the components shouldn’t (and therefore can’t) be shared across the six applications I had created.
What I’m highlighting with the picture is that Mapping Sets are the exception to this rule.

The mapping from the legacy cost centers to the new PeopleSoft cost centers for instance could be shared by three of the source systems.
This is an excellent way to minimize rules maintenance while at the same time still splitting your rules across multiple Application Accounting Definitions (referring again to rule number one of the FAH design guidelines).

Sharing Mapping Sets across applications also means that when you update such a shared Mapping Set, you update the accounting rules for multiple Application Accounting Definitions at once. FAH therefore correctly requires you to re-validate all the Application Accounting Definitions which are using that particular Mapping Set.

Overall, most of the Account Derivation Rules were pretty straightforward, as they either used a single constant value, or a single Mapping Set. A few of the more entertaining Account Derivation Rules were:


The cost center derivation from legacy accounting system to PeopleSoft General Ledger:

The priority 40 Mapping Set was the main mapping from legacy cost centers to PeopleSoft cost centers. In the picture, the Mapping Set is called "Legacy Centers", and because this is the Account Derivation Rule for the debit-sided entries, we used the debit legacy cost center value (see column 'Input Source') to find the corresponding PeopleSoft value within this Mapping Set.

In case the cost center on the legacy system side was not present, the business unit code was provided instead. In some of such cases, the customer desired to derive the PeopleSoft cost center, based on the legacy account number (instead of the cost center).

It are the three priorities (10, 20, 30) which guide such exceptions towards the right Mapping Set e.g. the condition on priority 10 ensures that if the legacy cost center was not provided (in which case the source system field contained business unit value A), then the legacy account was used to derive the PeopleSoft cost center. See input source 'Legacy Account Debit' which is used to dive into Mapping Set 'Legacy Centers A', but only if the condition (Legacy Center Debit = 'A') has been satisfied.


The product derivation from insurance system to PeopleSoft General Ledger:

This derivation was business unit specific.
For a particular business unit, the product code always had to be a constant value (priority 10).
For two other business units, the value needed to be another constant in case the insurance system did not provide a treatment code (priority 20).

In all other cases, the PeopleSoft product code was derived through a mapping, based on the insurance system’s product code. Ideally you would combine this logic in a single Mapping Set, which is not possible if a single input value from the source system should be mapped to multiple output values. For that reason we used a split across two conditional Mapping Sets.

Alternatively you could choose to concatenate the input values in your transaction object and only use a single Mapping Set (as explained in this post) but to make the logic entirely transparent for the user, we opted to solve it with two Mapping Sets and conditions instead.

Note: the screenshots show conceptually how the setup looked like, but all content has been renamed in order to preserve customer anonymity. 

FAH / SLA glossary

In most posts I try to stay away from abbreviations as much as possible, in order not to scare away first time readers. But this list of commonly used FAH/SLA abbreviations might be useful anyhow:

• AAD: Application Accounting Definition
• ADR: Account Derivation Rule
• JED: Journal Entry Description
• JLD: Journal Lines Definition
• JLT: Journal Line Type
• MS: Mapping Set
• SLAM: Subledger Accounting Method

Using Financials Accounting Hub for GL data conversions

No, I'm not saying that you should consider licencing FAH for the sole purpose of a one-time data conversion exercise. Not-at-all. I simply wanted to avoid labeling this article as another example of a FAH implementation. But truth be told, this article is... another example of a FAH implementation, be it a somewhat interesting one :-)

This Financial Services company has systems for penions, insurances, payroll, and cash desks. These systems connect to the accounting application through an importer module which exists next to the accounting modules (similar to what we call AR, AP, GL, etc). Lastly there's a module embedded within the accounting system that deals with securities.

They were moving to PeopleSoft Financials, so in order to connect the source systems, we deployed FAH, and the FAH-to-PeopleSoft GL Integration Pack.

The source systems are now all connected to FAH, and so is the legacy accounting system. That was done because we needed to interface the data from the embedded securities system towards PeopleSoft General Ledger. We could have connected this securities system directly to FAH, by using an event based accounting approach, but at the time of implementation the customer already knew that the securities system would soon become obsolete and be replaced altogether.

So instead of an event based accounting approach, we simply connected the legacy accounting system to FAH, and used the journal pass-through approach to transform the continuous flow of securities-related journals from the legacy accounting system, onto PeopleSoft General Ledger.

This was not only a quick and easy solution to connect this soon-to-disappear securities system, but by doing this, we had instantly also covered all needs for the GL data conversion:

• mapping the old chart of accounts to the PeopleSoft chart of accounts was taken care of by FAH mapping sets, 
• passing the data trough FAH also meant it was instantly validated against the PeopleSoft GL setup,
• and the bi-directional drilldown between PeopleSoft, FAH and the legacy accounting system covered the audit requirements.

At the same time we had now also created a welcomed comfort cushion for the implementation as a whole, because we could go live with PeopleSoft GL and FAH, while still keep on using the legacy system for receivables, payables, cash management, etc. until the respective PeopleSoft modules were ready to go and take over those tasks.

Once the PeopleSoft modules had replaced the legacy submodules, and once the securities system was removed, then the legacy accounting system could be switched off in its entirety. Due to the journal pass-through connection between FAH and the legacy accounting system, this could all be done entirely at the pace the customer felt most comfortable with.

You might notice the similarity with the incremental implementation approach article, and yes the overall message is indeed alike: by first creating a journal pass-through connection between the core legacy accounting system and FAH, you can make life a lot easier.

But if we had applied that incremental approach to this implementation, then we would have first gone live with simply a connection between the legacy accounting system and FAH, and we would have left the source systems initially connected to the legacy accounting system. Such approach would look like this:

That level of comfort was not required in this case though, as we were fully ready to connect the source systems directly to FAH. But it's always good to have such backup scenario in place.

Financials Accounting Hub to PeopleSoft General Ledger Integration Pack

Open an accounting period in PeopleSoft, and woosh... the same accounting period is now open in E-Business Suite.
Add a Chart of Accounts value in PeopleSoft, and woosh again... the value now also exists in E-Business Suite.
Add an exchange rate in PeopleSoft, and... you guessed it!

It was the first time I got to see AIA in action, and yes, I was impressed.
Meanwhile it's the third time already that I'm implementing this solution, and the wow factor has disappeared, while I've gotten used to these applications being able to talk to each other, without them needing my help.

So this solution gets technology kids like myself excited, but why was it ever developed?
Very simple: Financial Services companies are heavy FAH users, and at the same time they are also steady fans of PeopleSoft Financial Management Solutions.

Putting two and two together:

This Process Integration Pack (PIP), integrates E-Business Suite Financials Accounting Hub with PeopleSoft General Ledger. In reality however, a lot of the integration takes place between E-Business Suite General Ledger and PeopleSoft General Ledger.

The accounting flexfield, calendar, currencies, ledgers all need to be set up in E-Business Suite, and they are simply a mirror image of the PeopleSoft General Ledger setup.
As part of the PIP implementation, the interface between FAH and E-Business Suite General Ledger is disabled. Accounting entries are sent directly from FAH to PeopleSoft General Ledger, with no transactional data (journals) ending up in E-Business Suite General Ledger.

So E-Business Suite General Ledger only acts like an empty shell. The PIP will make sure that both PeopleSoft General Ledger and E-Business Suite General Ledger remain in sync at all times.
When a user creates or updates a chartfield value in PeopleSoft, then this update will instantly be reflected in the corresponding E-Business Suite value set.
A similar real-time synchronization happens for exchange rates and opening/closing of accounting periods.

Therefore FAH knows at all times what the valid financial master data in PeopleSoft is. And it will use this information during its Create Accounting process. From an end-user perspective however, E-Business Suite General Ledger doesn’t exist, and it appears that FAH talks directly to PeopleSoft General Ledger.

As FAH's Accounting Program then builds accounting entries (by making use of the mirrored PeopleSoft chartfield values, exchange rates and accounting period statuses), it will ask PeopleSoft if the produced account combinations comply with the PeopleSoft combo rules - this is the equivalent of E-Business Suite's cross-validation rules.

You might wonder why a different approach is chosen here compared to the chartfields, exchange rates and period statuses synchronization, and why the PeopleSoft combo rules aren't synchronized directly with the E-Business Suite cross-validation rules.
This is because the structures of both rules are too different to synchronize them directly.
So instead, the Accounting Program builds the code combinations, but before committing, it sends the distinct code combinations to PeopleSoft and asks if any of the code combinations do not comply with the PeopleSoft combo rules. PeopleSoft instantly returns the answer to FAH, and the Accounting Program proceeds accordingly. It takes longer for me to write this down, then for the PIP to actually execute this.

The valid accounting entries are then teleported by ODI (Oracle Data Integrator) to PeopleSoft's Journal Generator. This Journal Generator is the PeopleSoft equivalent of E-Business Suite's Journal Import functionality.
Transferring the accounting entries is done through ODI, because it's better suited for bulk data processing, compared to the XML messaging which is used for all the other integration points.

Both combination checking and transferring of valid accounting entries is embedded directly in FAH's Create Accounting program. So the integration with PeopleSoft does not require users to run any additional processes, compared to E-Business Suite's internal FAH to GL interface.
And because all the validations take place within FAH, only valid accounting entries will be presented to PeopleSoft.

Once the accounting entries have been processed by Journal Generator, users can drill down from the PeopleSoft journal into FAH's accounting repository - similar to E-Business Suite's drilldown from General Ledger to FAH.

Lastly, in case a journal is deleted in PeopleSoft, the corresponding FAH accounting entries are reversed, and the FAH event status is updated in order to ensure PeopleSoft and FAH remain in sync.

Besides the functionality which this PIP provides to the customer, it's also just great fun to implement!

That's it for now. In a future post I'll dive deeper in how the PeopleSoft setup maps to E-Business Suite General Ledger.

EDIT: you can find this follow-up post here.