 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.
Your turn now: please share (pun intended) your thoughts.
|
Hi All,
We need to create state entries via FAH. Im assuming if I create an ...
Comments
You make a valid point about first taking the time to think about how many applications you will need. Our implementation intially followed scenario 2 where we had all accounting rules in one application.
Intially this was not a problem as we had a small number of rules but as the application grew larger we found that we could not compile the accounting package at all or add new rules.
After looking at the various options we eventually decided that spliting our applications would be the best route. Using the import/export functionality we made 3 identical copies of our large package and then trimmed down the excess in the 3 packages. It's import to determine a logical way of spliting the applications that makes business sense.
We have not looked back since that decision and we have now found that the "scenario 1" implementation is streamlined, fast, efficient and easy to use.
Thanks for your feedback - always interesting to hear these experiences.
I agree with you that scenario 1 is the safest bet, and it's also the most commonly used flavour, even though we do have customers who are happily using scenario 2 as well.
I guess it depends on the type of source systems if it even makes sense to group rules under a single Application. If it doesn't, then it's indeed better to make a split across Applications, then you've got a clear distinction in your rules and a smaller AAD package, which in its turn has a positive impact on performance.
Personally I'm also a convinced fan of scenario 1. In rare cases I would use scenario 3. And it would have to be a big coincidence and a rather small implementation for scenario 2 to become the most appropriate solution.
Regards,
Sven
I have raised an enhacement request for Oracle to provide an FNDLOAD LCT file that downloads/uploads Mapping Sets seperately from the AAD. Since, as you point out, this is a cross-application object.
Nic
Kindly guide us through to proceed further.
Thanks for the comments.
Did you first call the create event API to insert records into xla_events?
Did the Create Accounting program successfully pick up the events? You can verify this by running Create Accounting while setting the report parameter to Summary or Detailed. The first part of the Create Accounting output will show an overview of the number of events that got processed. Please try this method to verify if events get picked up successfully by the Create Accounting program.
Regards,
Sven
thanks for the well guided reply. We have run the report as per your suggestion. Events are getting picked up and are shown in the overview ( first part ) as Number of documents = 1 ; Processed = 0 ; Error = 1;
We have also verified the SLA accounting errors table and faced with the following errors :
1. The account on the gain or loss line is invalid. If you have a gain/loss journal line type defined, please verify the account derivation rule attached to it on the journal line definition. If not, verify the value of the source mapped to the accounting attributes Exchange Gain Account and Exchange Loss Account. ( we have not defined any gain/loss line types in our SLAM)
2. The entered amount and accounted amount for line 3 are not equal. The entered amount and accounted amount must be equal when the entered currency is the same as the ledger currency. Please update the entered or accounted amount for line 3.
( verified and found the amount populated are correct ; Searched Metalink and found some patches ; but they are for AP payment accounting issues;
Please suggest if the same patches resolves this issue.
thanks for your valuable time and inputs
many regards
mohan