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