Multiple Charts of Accounts and their impact on FAH/SLA

Let me first remind you how we got here:

We discussed the FAH to PeopleSoft General Ledger integration pack, and then looked at how to set up E-Business Suite General Ledger within the context of that integration. We left with the conclusion that depending on the PeopleSoft setup, each PeopleSoft business unit might require you to create a separate accounting flexfield within E-Business Suite.

We'll pick it up starting from that scenario again, and have a look at the impact of multiple charts of accounts (i.e. accounting flexfields) on our FAH setup.

But first a message to the reader who just stumbled on this article while looking for E-Business Suite's multi-GAAP options: this article is completely useless to you. Seriously. We're discussing a very specific scenario here, where multiple primary ledgers are each using their own distinct chart of accounts. Although this might give the impression that this article is related to multi-GAAP, in reality it has absolutely nothing to do with it. That being said, you're of course welcome to just hang around :-)

We'll use the example from this post and expand on it by assuming that there are two business units in PeopleSoft, and because some of their chartfields are using Set ID at business unit level, we need two separate accounting flexfields in E-Business Suite.

To see the impact, let's first take the original setup again, which you can read all about in this post.

Save your eyes - click the illustration

Then if we throw our multiple charts of accounts scenario on top of that, we get this:

Save your eyes - click the illustration

The six dark blue boxes represent E-Business Suite applications (see Step 1 of the Basic Setup Steps).

So does the multiple charts of accounts scenario mean we have duplicated the entire setup?

No, not everything has been duplicated.
The Subledger Accounting Methods, Application Accounting Definitions, and Journal Lines Definitions are all chart of accounts specific. So in our example, those require a separate version per PeopleSoft business unit.

Then the Journal Line Types are not related to a chart of accounts, and can therefore be re-used by all PeopleSoft business units.

The Account Derivation Rules would be a mix of re-usable and chart of accounts specific, depending on if the Account Derivation Rule uses a chart of accounts, or if it uses a value set. In which case it depends on if that value set is shared by multiple chart of accounts. If yes, then also the Account Derivation Rule can be shared.
The same holds true for Mapping Sets.

Note that we do not set up additional E-Business Suite applications (the six dark blue boxes).
We simply create extra Application Accounting Definitions, but within the context of the same E-Business Suite application.

I'm using a fictive example now, but in reality you should of course check if it makes sense to set up an additional Application Accounting Definition for each source system.
Take for instance the Pensions system. Pensions is a specific line of business which will probably be accounted for in an entirely separate business unit. In such case you would only set up the particular combination which is relevant, and ask yourself the same question for all the other combinations of source systems / business units.

As mentioned above, in this example the Subledger Accounting Methods, Application Accounting Definitions, and Journal Lines Definitions are all chart of accounts specific. However, as explained in this post, that does not necessarily always have to be the case, because it is also possible to go for a chart of accounts independent setup (all the seeded SLA setup is an example of such).
In that case you could simply use your single Subledger Accounting Method and its underlying components against all your primary ledgers / chart of accounts combinations.

The reality of things though is that when implementing FAH, we nearly always end up with chart of accounts specific setup. And this definitely isn't a bad thing - more details on this in a future post, but let's take a quick example: Mapping Sets. Mapping Sets are good. They target a specific list of output values; values which relate to a chart of accounts. Therefore Mapping Sets will by default make your accounting rules chart of accounts dependent.

So my point definitely isn't to push you towards a chart of accounts independent FAH setup.
Instead, the key takeaway is that the PeopleSoft configuration can have an impact on your FAH rules design, and the above example demonstrates how to deal with this impact, by utilizing standard FAH/SLA functionality.

How to mirror PeopleSoft General Ledger into E-Business Suite General Ledger

Following the FAH to PeopleSoft GL integration pack post, I''ll now highlight how to set up E-Business Suite General Ledger, within the context of a FAH to PeopleSoft General Ledger implementation.

Note that this article is written from an E-Business Suite perspective, and that it covers only a certain aspect of the integration. If you wish to understand the other aspects as well, you can find the implementation guide (version 2.5) in the AIA documentation library.

First we need to understand PeopleSoft's Set ID feature.

For the purpose of our integration, I'll use an example to illustrate this conceptually.

The shared Set ID resembles data which can be used by all business units.

Then you can make up Set ID's for whatever levels you like e.g. continent, country, region, etc.

The lowest possible value at which Set ID can be used, is at business unit level.

Set ID's make it very easy to re-use data across the application, which is why this concept is also present in Fusion Applications.
For our purpose, the following would be an example of Set ID usage:

Here the accounts are shared by all, products are business unit specific, and cost centers are country specific.

This means that for instance business unit "US002", makes use of the values highlighted in yellow:

Now how does this PeopleSoft feature translate to the E-Business Suite Financials world?

The magic formula is:

Applying this to our example, we get the following:

So each combination of PeopleSoft Chartfield and Set ID, results into an E-Business Suite Value Set.

The E-Business Suite accounting flexfield for business unit "US002", is using Value Sets: Account-SHA / Product-US002 / Center-US.

This means that if one or more PeopleSoft chartfields are using Set ID at the lowest possible level, which is the business unit level, then in E-Business Suite you'll be setting up a separate accounting flexfield for each PeopleSoft business unit.

The PeopleSoft business unit concept is richer compared to what we call a business unit in E-Business Suite. In PeopleSoft the opening / closing of accounting periods, can for instance happen at business unit level. While in E-Business Suite this is held at ledger level.

Then a PeopleSoft ledger is used to hold a certain representation of a business unit's account balances (e.g. actuals, budget, ...).

Throwing this all together, we get the following formula:

Meaning that every combination of PeopleSoft business unit and PeopleSoft ledger, results in an E-Business Suite ledger.

But hold on, does this tie in with the first formula?

Let's assume the scenario where one or more PeopleSoft chartfields are using Set ID at the business unit level.

As explained above, in such case we would set up a separate E-Business Suite accounting flexfield per business unit, which results in a separate E-Business Suite ledger per PeopleSoft business unit.

This indeed ties nicely together with the other formula, which states that we need at least an E-Business Suite ledger per PeopleSoft business unit.

You won't necessarily always run into this particular scenario, because I've encountered PeopleSoft GL implementations where all chartfields were happily being shared across the board.
So to mirror that, you would set up a single accounting flexfield in E-Business Suite, and use this single accounting flexfield for all your E-Business Suite ledgers / PeopleSoft business units.

In a future post, I'll explain how the above can have an interesting impact on your FAH rules design.

Newsflash: PeopleSoft sub-ledgers are bypassing FAH!

This is a misunderstanding I've run into on a number of occasions. Enough to merit a quick clarification:

When deploying the FAH to PeopleSoft General Ledger integration, the aim should be to have external feeds to PeopleSoft General Ledger flow via FAH. If not then... there's no point in implementing FAH in the first place.
Just like implementing FAH against E-Business Suite General Ledger serves the purpose of having external feeds to E-Business Suite General Ledger flow via FAH.

There is one difference though:
When using E-Business Suite General Ledger, Subledger Accounting (SLA) connects the E-Business Suite subledgers with the E-Business Suite General Ledger. Hence (as explained in this post) all subledger data (both E-Business and non-E-Business) is flowing through the common XLA framework, towards E-Business Suite General Ledger (XLA = FAH/SLA):

But in the FAH + PeopleSoft General Ledger scenario, the PeopleSoft sub-ledgers continue feeding PeopleSoft General Ledger directly, without any FAH/SLA involvement what-so-ever:

Sure, you could connect the PeopleSoft sub-ledgers through FAH. That would definitely be an entertaining project. But from cost/benefit perspective it wouldn't make much sense.

So when using FAH in combination with PeopleSoft General Ledger, the integration between PeopleSoft sub-ledgers and PeopleSoft General Ledger remains untouched, and the PeopleSoft sub-ledgers continue feeding PeopleSoft General Ledger just like they've always been doing: without FAH.

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.