 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 Payment
Event Class = Refund
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).
Please click this illustration for a better understanding on how the different building blocks tie together (once the image window opens you can zoom in to get a clear view of the picture).
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.
|
Hi All,
We need to create state entries via FAH. Im assuming if I create an ...
Comments
How to implement the FSAH manual journal entry functionality?
Answer:
First setup step when implementing FSAH altogether is to register your external subledger as a custom application under Sys Admin (Application > Register). The recommended approach is to follow DEV’s example and register a separate application for each individual subledger. Then you define a responsibility under this custom application. When doing so assign a seeded menu like ‘SLA: Developer Main’ - this holds the seeded manual subledger journal entry functionality under Inquiry > Journal Entries.
Next to the seeded functionality there’s also a manual subledger journal entries API available (see section 12 of the FSAH implementation guide for further details).
Note: the SLA/FSAH manual subledger journal entry functionality allows users to create accounting entries directly in the SLA accounting repository. Let’s say for instance one of your custom subledgers fails to deliver all data to FSAH then you could make a manual subledger journal entry in FSAH/SLA to add the missing accounting entries to the SLA accounting repository. This then also ensures the desired synchronization of your primary ledger with its secondary ledger(s).
So SLA’s manual subledger journal entry functionality is different to and therefore does not replace the GL manual journal entry functionality. That is also why FSAH/SLA does not allow posting to an adjustment period: adjustments are considered a GL functionality only and therefore FSAH/SLA only allows postings to periods which exist in the real world, or in other words, periods which exist in the subledgers.
Regards
Sven
Just to clarify-- In addition to what you point out above, the specific step I was missing was to also Register the Subledger Application, this is an additional step. So, step 1 is as you say, from Sys Admin you register a custom App using System Administrator and accessing Application>Register. But then after you define your Journal Source and also after you have created your custom Developer Responsibility, you will also need to access this from the Developer Responsibility: Subledger Accounting Setups > Subledger Applications. It is on this screen that you actually register your custom application, and associate it to a journal source. Once this step is completed, only then you will be able to use the SLA Journal Entry self service form without getting an error message that indicates you are using an inappropriate Responsibility.
Yes, that's right. Once the responsibility has been defined the next obligatory step would be to complete the Subledger Applications window. Without that it won't be possible to proceed with the subsequent step, which is the creation of an event model. Come to think of it, as a very rough guideline you could say that in order to complete the setup you can just follow the menu structure and walk through the forms from top to bottom i.e. from Subledger Applications window to Subledger Accounting Methods window.
Regards,
Sven
As I already pointed out in the article: the product name (FSAH) is slightly misleading. Although the original desire for an accounting hub originated in the financial services industry, the product is being used in other industries just as well.
Therefore the product has now been renamed from FSAH (Financial Services Accounting Hub) to FAH (Financials Accounting Hub). The name change has no further impact on the product itself.
Jouke
We are implementing FAh in our company .Its in very initial level. Do you have some implementation documents for FAH . If so please mail me at This e-mail address is being protected from spambots. You need JavaScript enabled to view it
Also can you throw some light on how the tables are designed for FAH.
Regards
Monica
Let's talk to discuss this a bit more in detail.
I've sent you my phone number.
Regards,
Sven
Good to see your blog...I'm in the same boat as Monica is...started with requirement analysis in my office...Would appreciate any documentation on implementation of FAH ...
thx
sandy
If you have some material on how to implement FAH then plesea share it. I am having big problemsd in implementing FAH.
Thanks & Regards,
Akhil
I've just written a new article which walks you through the FAH setup steps. You can't see the article yet because it needs to be approved by the site owner who I think is enjoying a well deserved holiday.
But if it's urgent you can send me a private message containing your email then I'll already send the article to you.
Regards,
Sven
We are creating a POC FAH and we are facing some problems like we are not able to create multi period accounting and business flows.
Please send some more inputs at This e-mail address is being protected from spambots. You need JavaScript enabled to view it .
Good to see your blog...I'm in the same boat as Monica is...started with requirement analysis in my office...Would appreciate any documentation on implementation of FAH ...
thx
sandy
Been getting this question a number of times in the last couple of weeks (which is good!) and plan on publishing some new articles shortly.
If in the meantime you have any specific questions, feel free to post them in the forum: http://oraclecs.com/forum/subledger-accounting
Regards,
Sven
Can you send me FAH implementation documents if any to my email id?
This e-mail address is being protected from spambots. You need JavaScript enabled to view it
Thanks,
JA
Does any user manual documentation exist for the FAH? We are in the process of creating user documentation for our new HUB implementation and I can see the implementaion guide, but I don't see a users guide.
No there is no FAH user guide, although I do recommend looking through the Subledger Accounting implementation guide (as FAH is basically standalone subledger accounting).
Regards,
Sven
Supporting References Balances can be used at any level you like so when you choose a low level (e.g. maintain balances for each policy number) that could potentially lead to performance issues.
Although nothing stops you to do this, the functionality was intended to be used at a higher level e.g. maintain balances per region / state.
The only documented issue I'm aware of is one which got identified / resolved just last week, but I believe you're familiar with that one...
Regards,
Sven
I hope you are doing good. Is there any way to throw the same formatted data from the FAH to the legacy system in the way where it actually came from. I know it can be done via the fusion middleware, but if you can throw some light on it , would highly appreciate it.
Cheers
Verma Vineet
Oracle R12 Consultant.