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.