|
Financials for R12 -
Subledger Accounting & FAH
|
|
Written by Jouke de Groot
|
|
Thursday, 11 February 2010 18:27 |
 In R11i we have a few engines to determine account code combinations. They are called AutoAccounting (in AR and PA) or Account Generator (in AP, PO, FA and OM). Note that the AutoAccounting (AA) mechanism in PA is much more flexible than the AA in AR, and the Account Generators (AG) are built with Oracle Workflow technology.
The good thing about these engines is the ability to influence the accounting flows. As every company has its own accounting requirements, the setup of the accounting engines differ in every implementation.
Account Derivation Rules
These AA's and AG's remain in R12, but with the advent of Subledger Accounting their usage has been changed. The part of SLA that's equivalent to the AA's and AG's are the Account Derivation Rules. In short, the outcome of the AA's and AG's serve as input for the Account Derivation Rules. The seeded rules pass these accounts through untouched to General Ledger. This is, by the way, the reason why instances upgraded from 11i to R12 immediately can work with seeded SLA setup.
One of the most powerful parts of SLA is the possibility to configure the Account Derivation Rules. Instead of using SQL queries (AA in Projects) or changing workflows (AG's), the full code combination (or one or more segment values) from any account can be changed. A common mistake is that people think (or expect) that the newly generated code combination by SLA will update the original distribution account. This is not true ! The changed code combination is only visible in the SLA forms. Original distribution accounts remain visible on the transactions ! This is confusing at first sight and requires a major mind change for end users. Let me illustrate this with an example.
A direct AP invoice (so not PO or PA related) invoice is entered in AP. The AP clerk enters the invoice header and the expense GL account on invoice line level. This account is also copied by AP to the distribution line. Now it is possible that an Account Derivation Rule will change the expense account during the Create Accounting process. This change is not reflected in the Invoice Workbench, both the invoice line and invoice distribution still have the originally entered expense account. The GL accounting can be checked using the Tools > View Accounting on the top menu. This opens the Subledger Accounting form with the generated journal, including the new expense account. The same behaviour could occur for matched invoices or project-related invoices. The distribution account has become a possible GL account.
Conclusions
So we now end up with a situation were we can intervene accounting on two places: during transaction validation (AA and AG) or on the back end (SLA). The advantage of doing it at transaction validation is transparency for the end user: the distribution accounts on the transactions equal to the accounts posted in GL. As long as it doesn't require customizations, I still recommend this approach. Concrete example: I still recommend to setup AA in AR the same way as we always did in 11i, unless there is a good reason to use SLA to overrule values.
This leads me to another thought. SLA was promised to be the central repository for all accounting in the Oracle E-Business Suite. To a certain extent this is true, but maybe it's better to see it as an additional accounting structure on top of existing 11i-ish accounting structures. I know SLA has much more features than Account Derivation only, but that's how I see it in this context.
So we have a new implementation consideration: where do we change accounting ? As much as possible in SLA (to keep it as central as possible, to avoid customizations, to keep it on a functional level) or in AA/AG (transparency on distribution accounts) ? Or both ?
|
Comments
Also if we have attributes for which balances need to be maintained, that are not part of chart of accounts structure we can do these changes in SLA.
Also Oracle support suggests that we move of workflow as much as possible.
Again it depends on various client requirements.
Thanks