If this is true, then why should I care about how FAH internally transforms my accounting rules into PL/SQL magic?

At first sight, you shouldn't care. Because even if you build your rules in the most inefficient way possible, still the outcome will be according to your expectation. An additional understanding however will help you decrease the elapsed processing time and required computing power.

This article provides the functional insights and guidelines needed to ensure optimal FAH performance. Other factors like f.i. hardware sizing are equally important, but not subject of this article.

Let's start with some illustrations:

The event model is the foundation on which we build our accounting rules.

Next to the event model, we have the AAD (Application Accounting Definition) tree, which shows how the different AAD components tie together.

The key is to understand the relationship between the Event Model and the AAD components.

So, let's join both pictures together:

There is one AAD for each Application. This is the level on which FAH compiles the accounting rules into a PL/SQL package. So there is one PL/SQL package for each Application / AAD. Then for each Event Type, there is a Journal Lines Definition. Each Journal Lines Definition is represented as a procedure within the PL/SQL package.

Now how should you incorporate this information into your FAH rules design?

The smaller the AAD package, the better the Accounting Program will perform, and also the quicker the package will compile. To achieve optimal performance, you should therefore try to minimize the size of your AAD packages.

The following three guidelines will help with that:

1) Number of Applications

There are various implementation considerations when deciding upon the number of Applications. From a performance perspective though, the recommended approach is not to group all the rules belonging to multiple source systems within a single Application/AAD.

Instead, set up a separate Application (and therefore also a separate AAD) for each source system, or for each group of related transactions. In theory you could set up a separate Application/AAD per Event Class, assuming there are no dependencies between Event Classes, like f.i. Business Flows.

2) Number of Journal Lines Definitions

As indicated above, each Journal Lines Definition (JLD) will be presented within the AAD package as a separate procedure. So if you want a small AAD package, you should try to keep the number of procedures, and therefore also the number of JLDs, as low as possible.

To achieve this, you do not set up separate JLDs for each Event Type. Instead you build only a single JLD per Event Class, by making use of Event Type "_ALL". This way you'll end up with one JLD per Event Class, instead of one JLD per Event Type.

You can still utilize the Event Type as a condition within the Journal Line Types and Account Derivation Rules to cater for variations within the accounting logic.

3) Accounting Rules Design

There is a virtually unlimited flexibility in how you design your rules. Therefore it's very easy to build something that works. However, if you want to build something that works well, you'll need some familiarity and experience.

I'll give an example to illustrate this point:

Let's say we got these 5 events. A typical (but highly inefficient) setup approach would be to use 5 Journal Lines Definitions, all using 2 Journal Line Types, each using a truckload of Account Derivation Rules. To keep the example clear and simple, I'm only showing the Account Derivation Rules for the account segment.

The point is that in this example there's zero re-use of setup components.

Now let's explore alternatives:

First of all we replace the 5 Journal Lines Definitions with a single Journal Lines Definition, through the use of aforementioned Event Type "_ALL". You can select this Event Type in the Journal Lines Definition window.

We add conditions on Journal Line Type level to make sure each Event still generates only two accounting lines. Without these conditions, each Event would result in 10 accounting lines.

Next we tackle the Journal Line Types.

Let's assume the parameters (Balance Type, Entered Amount, etc.) on the Journal Line Types are all the same, except for the Side (Debit, Credit). So in that case we can replace the 10 original Journal Line Types with just 2 Journal Line Types, a debit and a credit. To make sure the accounting per Event Type is still correct, we add conditions on Account Derivation Rule level.

Because all those ‘if - then' conditions on Account Derivation Rule level are not very transparent and friendly to maintain, we drop the conditions altogether, and replace them with Mapping Sets.

So the original setup consisted of:

• 5 Journal Lines Definitions
• 10 Journal Line Types
  
• 10 Account Derivation Rules

And after making some quick improvements, we end up with:

• 1 Journal Lines Definition
• 2 Journal Line Types
• 2 Account Derivation Rules
• 2 Mapping Sets

Note how the original setup, the new setup, and also each intermediate phase, all produce the same accounting.

The new setup however is far "better" compared to the original one, because the size of the new setup's PL/SQL package will be much smaller compared to the original setup. This results in quicker compilation of the rules when pressing the [Validate] button in the Application Accounting Definition window, and also the Accounting Program will run faster, as its code is now much more compact.

Finding the most optimal configuration requires a thorough understanding (read: experience) of the setup components, but a generic rule is to build variations within the accounting rules as low as possible within the Application Accounting Definition hierarchy, making maximum use of Mapping Sets, and conditions at Account Derivation Rule level.

Conclusion

An understanding of how FAH transforms accounting rules into application code is essential to obtain maximum performance, with minimum investment.

The functional guidelines presented in this article are only one part of the equation however.

FAH is often used to process high transaction volumes, so if you need to f.i. process 5 million transactions per hour, you'll need hardware power, regardless how well you've built your rules.

Even with sufficient hardware power and highly efficient accounting rules, something like a missing index can still spoil the party. So also technical performance tuning (indexes, parallel processing, etc.) is equally important. See Note ID 791049.1 on How to Improve Performance in Subledger Accounting & Financials Accounting Hub for further details.

All three factors are equally important to build a successful solution. Neglecting any one of them can make your solution fall apart.

* Update: also keep in mind NOT to use Custom Sources when implementing FAH. Only use Custom Sources with SLA.

Cross-posted from sleemput.blogspot.com

TweetShare

Comments

rifnorth

0

 

 

Hi Sven,

your articles are of great help and they are the reason I signed up lol. We had FAH in PROD for a year now, but we still have a long way to go to get where we want to be. If you don't mind I had a couple of questions:
1. in one of your articles you mentioned that user transaction identifiers are displayed in the OA framework pages. In our case we defined four of them, but these fields are not available in the inquiry pages. Is there anything else we need to do?
2. we have new rules that we need to implement, In one example, the rules have to result in 2 CRs and 1 DR, and the ACCT_AMT from transaction object has to be allocated to the CR accounts based on a percentage. Did you come across such rules before or would you have an idea on how to go by to create ADRs, JLTs.. for these.

Monday 14 March 2011, 20:09

Please login to post comments or replies.