Financials Accounting Hub - Sharing Accounting Rules

Originally posted 10 May 2009 on oraclecs.com

In the current economic climate “sharing” is not the first thing on most people’s mind. It is on my mind though, be it in a somewhat different context. Being triggered by David’s call for more FAH material I thought I’d write something about how FAH allows sharing of accounting rules.

What I’m discussing here is also one of the very first things you should ask yourself when starting a FAH implementation. Basically the question is: should I set up one or multiple Applications? With “Applications” I mean the E-Business Suite Applications that you register under System Administrator > Application > Register, and I don’t mean the external application(s) that you will be hooking up to FAH. For the sake of clarity, from now on I’ll call those external applications our source systems.

Let’s use a basic example: we have three billing systems that we need to connect to FAH. If we map our external source systems 1-1 onto E-Business Suite applications, we get this:

The purple boxes represent the external source systems while the light-red boxes represent custom E-Business Suite Applications.
In this scenario the accounting rules are completely separated and can never interfere with each other, which might be a requirement.
It is very likely however that some of your accounting requirements will be similar across those different billing systems. For instance your receivables account might be the same. So by using the following approach:

You will only need to set up a single Account Derivation Rule for your receivables account, while in the first scenario you would need to set up the same Account Derivation Rule three times.

Let’s say you need to change your receivables account then obviously you would need to change it three times in three different places, while the second scenario only requires a single update to reflect your new rule.

All the underlying building blocks of an Application Accounting Definition are Application specific: Journal Lines Definitions, Journal Line Types, Journal Entry Descriptions, Account Derivation Rules. Therefore these items can only be shared across source systems when grouped under the same Application. Mapping Sets are the only exception as those can be used across Applications.

It’s not necessarily a share-all or share-nothing approach either, as you can pick whatever flavor you need, for instance:

And keep in mind these illustrations only represent the very top of the iceberg when it comes to implementation flavors, as within a single application you have plenty of options to make lower-level distinctions e.g. within a single Account Derivation Rule you can use multiple rows, each row with its own condition(s). This way you can for instance derive different revenue accounts depending on the source system, while at the same time still leveraging shared accounting rules.

Conclusion:
Scenario 2 is flexible as it provides you with the option to share, while at the same time you can easily add also non-shared items.

Scenario 1 however does not allow sharing rules across source systems. If at some point in time you do need to share then the only option would be to re-implement.

Therefore, before you start, first take some time to think about how many Applications you will need.

* Update: and also take into account the performance aspect of this decision.