Infosys’ blog on industry solutions, trends, business process transformation and global implementation in Oracle.

« MES for Process Industries | Main | Enterprise Asset Management - Emerging trends »

Thin Chart of Accounts within OFSAA !

Guest post by
Bhuvaneswari Venkataraman, Lead Consultant - Banking and Capital Markets, Oracle Practice, Enterprise Solutions, Infosys Technologies Ltd.

 

In older version of Oracle Financials Service Application 4.5.xx (OFSA), considerable time was spent on designing the Chart of Accounts (COA) to bring out the optimum number of members under COAs. Now with new Oracle Financial Service Analytical Application 5.xx (OFSAA) leveraging its enhanced features like conditional assumptions system can assign any combination at run time instead of pre-defined only leading to thin COAs instead of thick in earlier versions.

Coining of COA is dependent on many factors like requirements on report stratification, granularity of level to which transfer price assumption are to be adhered to, multiple currency etc. Considerable time was spent during requirements stage and design stage to ensure all combinations are captured to ensure optimal number of members under COAs. Now in new OFSAA, there is no need to define such combinations before hand as leveraging conditional assumptions system can assign any combinations at run time.

Let's take an example for better understanding,  consider the case of attaching TP methods to a product with multiple scheme code. In earlier version we needed to factor in scheme code in TP-Product dimension,  so that different TP methods can be attached to different scheme codes of a Product. Typically if we have a product code 11101 and multiple schemes under this product say 101, 102, 103...nnn, we had to coin Product Chart of Accounts as 11101101,11101102 etc so that each combination of product and scheme gets a separate TP method.  But,  now with the availability of Conditional assumption we can attach multiple TP methods to the same product under different segments. Have the Product COA as 11101 only and with conditions Scheme code = 101 TP method 1, Scheme code=102 Method 2 etc., Similarly we can take any other aspect such as maturity date, accounts belonging to a particular product falling under a maturity horizon can have one TP method and another maturity horizon can have a different TP method assigned. This goes on with combination of Product plus available cash-flow characteristic of product. This  gives more flexibility with the number of dimension members drastically reduced.

Above examples clearly articulate how conditional assumptions will help client to have thin COAs providing more flexibility and ease of maintenance.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.

Subscribe to this blog's feed

Follow us on

Blogger Profiles