The Financial Services Accounting Hub (FSAH) is very similar to the Subledger Accounting product (SLA). In fact, looking merely at the functionality, there’s no difference between FSAH and SLA.
The only distinction between both products is that with SLA you get seeded event models for all Oracle subledger modules that require accounting and if desired you can use the components from these seeded event models to create your own customized Subledger Accounting Method.
While with a FSAH license you get the possibility to register external applications as subledgers, from which you can build your own event model, and use the SLA functionality to create accounting for the events originating from your external application(s).
Sounds nice, but why FSAH?
Well let’s start with another question… why SLA? If you look at the history of the E-Business Suite, the development teams of the subledger applications have always been working rather independently from each other. So from an architectural point of view you had implemented one single application but your end users sometimes were left with the feeling that switching responsibility was the gateway to another world. I might be exaggerating a bit but just compare the accounting processes between AR and AP in 11i for example and you know what I mean.
So it was not a bad idea to consolidate all that scattered functionality and while doing so introduce flexibility to the product.
However, the above scenario didn’t exist just within the E-Business Suite alone. Today, also other companies are facing a very similar challenge. They have a landscape of diverse applications which all produce some form of accounting information, and each application does this according to its own rules and logic. Most people (including myself) wouldn’t volunteer to maintain and reconcile such an application landscape. Imagine, there’s a new regulatory requirement and you have to dive into each of your applications to adjust your accounting logic. Or your marketing team has suddenly come up with this idea to launch an amazing new product and don’t want to waste any time but you still need to figure out where and how you will be producing the accounting…
The above picture reflects especially how application landscapes in the banking and insurance world look like. Due to mergers and acquisitions these institutions sometimes literally have hundreds of applications, some of them which are as old as the first brick of the company’s original HQ. Let’s say for example you acquired a company which had this old mortgage system running, well you can’t switch it off, so you’re stuck with a black box and nobody knows what’s in it. It might turn out to be an unpleasant challenge when you ‘quickly’ need to adjust some of the accounting logic produced by your mortgage system.
OK, so FSAH is a product especially for the Financial Services industry?
You might think so, but it most definitely isn’t. Contrary to its name, the Financial Services Accounting Hub will be of great value to any company with a diverse application landscape as the one described above. And yes, this is especially true for the Financial Services industry (hence the somewhat misleading name) but FSAH is already being used in other industries as well; this ranges from customers in the Telco industry to paint manufacturers. You can put it very simple: if you got accounting information originating outside of your E-Business Suite which you periodically (e.g. daily) need to get into your GL, then you will want to look at FSAH.
Let’s take a real-life example: we have a government institution were EBS is being implemented. They have three legacy accounting applications. Replacing everything at once would be too much of a shock for the organisation, so instead they implement EBS by first replacing just one of their applications. At the same time they do require a daily consolidated picture so they use FSAH to pass on the journals from their two other legacy systems towards Oracle GL. And they make use of the FSAH/SLA functionality to map the legacy data onto their new accounting flexfield structure.
So FSAH just receives journals to then pass these on to GL?
No, that’s not really the idea behind FSAH but if that’s all you want it to do for you then yes, it will do just that. But the easiest way to understand how FSAH is intended to be used is by looking at how it’s being implemented within the E-Business Suite itself:
FSAH/SLA uses an Event Model consisting of Event Entities with underlying Event Classes, and at the lowest level we have the Event Types which in their turn belong to the Event Classes. An example of a seeded SLA event hierarchy:
Event Entity = AP Payments
Event Class = Refunds
Event Type = Refund Recorded
The accounting is entirely event-driven meaning that for each Event Type you can define how you would like the accounting to be created. This is done using Journal Line Types, Journal Entry Descriptions and Account Derivation Rules which tie together in a Journal Lines Definition. Conditions can be applied at various levels, and optionally you can use Mapping Sets and/or Supporting References.
For each Event Type such a Journal Lines Definition can be build. These Journal Lines Definitions roll up into an Application Accounting Definition (e.g. Oracle Payables). The Application Accounting Definitions are grouped together under a Subledger Accounting Method, which is the component that gets tied to the ledger (remember in R12 a ledger consists of calendar, currency, chart of accounts and Subledger Accounting Method).
Click this illustration for a better understanding on how the different building blocks tie together.
 |
| FAH Setup Components |
So the accounting is event driven but as stated previously, if desired FSAH can process incoming journals as well. In that case the creation of a new journal would be considered an event. And I’ll illustrate why you would want to use this:
Let’s say you’re implementing FSAH at a financial institution which has 40 source systems they want to connect to FSAH. They already have some custom build translation engine in place to rout and transform the data from the source systems to their GL. Imagine FSAH would not be able to process incoming journals but instead FSAH could only process raw event data from the source systems. In that case you would need to analyze and implement accounting for each of these 40 source systems all at once which would quickly bring you down the road of a self-destructing project (budget = null / result = null).
A more sustainable approach would be to first position FSAH in between the existing translation engine and the GL. So initially you use FSAH to simply pass on the journals from the translation engine to the GL.
Then you choose one of the 40 source systems (start with an easy one), disconnect it from the translation engine and hook it up directly to FSAH. So for this one source system you are now doing true event based accounting while the 39 other systems still use the old translation engine. But as that one is also connected to FSAH, everything flows through FSAH which has become your central accounting repository and single source of truth. Then it’s a matter of gradually linking the remaining source systems directly to FSAH. By that point the old translation engine has become redundant and can be switched off. And as these custom applications typically reside on a mainframe, your return on investment just went through the roof.
Then in order to fix the hole in the roof, you can use FSAH and……….… no, that would be taking it one bridge too far. FSAH can’t do everything, but it can do a lot, and by now I should have provided you with an overall impression of FSAH and its capabilities.
0 reacties:
Post a Comment