Cool AIA video - An introduction to Application Integration Architecture

If you like to learn more about the why's and how's of AIA (Application Integration Architecture), then the full video on oracle.com provides a nice introduction.

The difference between FAH and SLA

FAH = Financials Accounting Hub
SLA = Subledger Accounting

What’s the difference?

From a technology perspective, there is zero difference.
XLA is the technical label for the FAH/SLA solution. XLA is the common framework which handles all accounting feeds into the E-Business Suite General Ledger. Therefore, technically XLA = SLA = FAH.

So if FAH and SLA both use the exact same technology, why are they labelled differently?
The difference is within the way how the technology should be used:

Subledger Accounting (SLA):

• Deals with the E-Business Suite subledger applications (AR, AP, etc.).
• Seeded event models which cannot be changed (extensions can be build using Custom Sources).
• Seeded accounting methods which can be customized (copied and modified) at will.
• Integral part of E-Business Suite Financials (R12 onwards).

Financials Accounting Hub (FAH):

• Deals with external (i.e. non-E-Business Suite) applications.
• No seeded event models – event models need to be build from scratch. 
• No seeded accounting rules – accounting rules need to be build from scratch.
• Requires purchasing a separate license.

Cross posted to oraclecs.com

Welcome. Oh, and I'm not going for the World Record.

No, I'm not going to continue spitting out as many posts a day as yesterday's opening posts.
(1, 2, 3, 4, 5, 6, 7)
Those were my earlier posts from oraclecs.com. My last post on there dates back to August 2009.

Did I spend all this time in between relaxing on a tropical island? No.
I've been busy with other things, and simply couldn't keep up anymore with all the requests for advice and assistance, besides having my regular job to keep up with.

On this blog I'll discuss whatever entertains me professionally. So this will be mostly related to Oracle's accounting applications, and integrations with these applications.

Happy reading!

Caution! - Custom Sources

Originally posted 30 Augustus 2009 on oraclecs.com

Sources are created by registering your Transaction Objects and clicking the Create and Assign Sources button in the Accounting Event Class Options window (see this article). We call these Standard Sources.

Next to that you can also create Custom Sources under Subledger Accounting Setups > Accounting Methods Builder > Sources > Custom Sources

As the name implies, these are Sources which aren’t standard, so which aren’t inherited directly from the Transaction Objects.

When you define a Custom Source, you enter a PL/SQL function and optionally one or more input parameters. The Custom Source will then be available within the list of Standard Sources. So you can use the Custom Source wherever you like and it will return the output from your PL/SQL function.
Incredibly powerful, isn’t it? Yes, but power often also has a sharp edge:

Let’s say my Transaction Object contains a column Contract Type and a column Product Number, while the business rule is that the combination of contract type and product number determines the product code used for accounting.
To derive this product code value, I make use of a Mapping Set. So I need a combination of two Sources (contract type and product number) to serve as input for my Mapping Set.

The wrong approach:
I can define a Custom Source in which I use the two input parameters, and my PL/SQL function will then return the combination of both Sources into a single string. This Custom Source serves as input for my Mapping Set to derive the product code.
What’s bad about this solution is that when I run Create Accounting, my PL/SQL will be executed for every single accounting entry line that’s generated. This negatively impacts performance.

The right approach:
Instead I should add a separate column to my Transaction Object view in which I join Contract Type and Product Number into a single string. This additional column (i.e. Source) I can then use as direct input for my Mapping Set. The Accounting Program will fetch the values from the Transaction Objects in bulk, which is why this solution outperforms the Custom Sources approach.

Conclusion:
Never use a Custom Source when implementing FAH (Financials Accounting Hub), as you can simply alter your Transaction Objects to directly include any values you need.
When you’re a regular SLA (Subledger Accounting) customer though, you are not allowed to make changes to the seeded Transaction Objects. Custom Source functionality can then be used in case the seeded Standard Sources are insufficient.

Tip: If you can't find the Custom Source, then the first thing to check is if the Standard Source(s) which are used as input parameter(s) in your Custom Source belong to the same Event Class as the Event Class under which you are trying to use the Custom Source.

Note 790945.1 [Frequently Asked Questions about Custom Sources] contains further information and examples on Custom Sources. But remember: as a FAH customer, you shouldn’t even use Custom Sources.

Financials Accounting Hub – Basic setup steps

Originally posted 12 July 2009 on oraclecs.com

In the past few weeks I’ve been approached by a good number of people asking me for more information on FAH. Especially the “How do I set it up?” question seems to come back often.

Understandably I’m not able to provide you with the best possible answer to this question, because I don’t know the specifics of your implementation: source systems, requirements, architecture, etc. That’s also why I’m a bit reluctant writing this article, as I don’t want it ending up serving as invalid input for implementation decisions. So before reading on any further, please first satisfy yourself with the thought that this is just a basic example, and NOT a guideline on how you should implement.

In my example I’ll be using a journal pass-through solution, which I described earlier on in this article. As a quick reminder: journal pass-through is a technique used when the source system already provides journals, and you want to process those journals through the accounting hub. It’s the easiest and most straightforward implementation flavor, making it an ideal candidate for the purpose of this article.  

What I won’t be covering in this article is the technical part of the setup (i.e. the creation of events), but briefly said: you need to call the create_event API or create_bulk_events API in order to insert records in the xla_events table. After you have completed all functional setup, you can run the Create Accounting concurrent program. That will scan the xla_events table for unprocessed records and create the accounting for those events based on the functional setup, which is the part I will describe in the subsequent steps.

1.       Register Application

N > System Administrator > Application > Register

FAH generates accounting for external (non-E-Business Suite) applications. So we first need to make our E-Business Suite aware that this external application exists.

2.       Create Responsibility

N > System Administrator > Security > Responsibility > Define

Then we create a new responsibility which we tie to the new application we just registered in the previous step. Use the “SLA: Developer Main” menu and the “Subledger Accounting Reports” Request Group.

Optionally, under System Administrator > Application > Menu, you may want to tie the “SLA:  User Main Menu” submenu to the “SLA: Developer Main” menu.  

Assign the new Responsibility to your User and switch to the new Responsibility.

3.       Complete Subledger Applications setup

N > Custom Responsibility > Subledger Accounting Setups > Subledger Applications

From here on we’re just going to walk through the setup menu. First stop: completing the Subledger Applications window. Here the mandatory step is to assign a Journal Source. You can set up this new Journal Source under General Ledger > Setup > Journal > Sources.

4.       Create Event Model

N > Custom Responsibility > Subledger Accounting Setups > Accounting Methods Builder > Events > Event Model

The Event Model, the most important part of your implementation.

Together with the number of Applications you register (see this article), the Event Model is the foundation of your FAH implementation. This will determine if you’ll end up with a world-class-easy-to-maintain-high-performing super hub, or some second-rate-headache-causing reject. My sense of exaggeration should make you realize how significant this topic really is.

Although this setup again depends entirely on implementation-specific factors, I’ll attempt to give some generic guidelines:

Different events take place in the source systems, and those events need to be accounted for. So you need to determine the different types of events that take place in the source systems. The most important word in this sentence is “YOU need to determine”. You shouldn’t ask someone in the customer’s organization to give you a list of all different events that can occur in source system X, and then setup all those events as Event Types within your event model. No, you need to rationalize the different types of events and analyze them from a business perspective: which events have similar accounting and can therefore be grouped together under a single Event Type. That’s easy said, but how to determine this?

Well, before you can do this you will first need to get a good understanding of how the different elements within the FAH setup relate to the event model. 

The Transaction Objects (database tables/views in which the source system data resides) are linked to the Event Class. So when you can work with a single Transaction Object, why would you want to use different Event Classes? Perhaps because you need to use different Journal Categories (Journal Category is tied to the Event Class). That can be a valid reason, but you should evaluate its importance and also understand the impact because for each additional Event Class, you will need to define a separate set of Accounting Attribute Assignments, and at least one Journal Lines Definition. And as each Journal Lines Definitions requires Journal Line Type(s), you will need to set up separate Journal Line Types, as those are also tied to the Event Class. This might not make much sense now, but once you get to play around with the system it will become more obvious.

Then how many different Event Types within each Event Class should you define? This is the part where you need to get creative and make use of clever conditions on Account Derivation Rule and Journal Line Type level. The possibilities are virtually endless, so explore them to the fullest. If you plan on setting up a separate Event Type per account code combination, then you’re still miles away from understanding how the concept should be used.

By looking at the seeded Application Accounting Definitions for the Oracle subledgers (AR, AP, FA,…), you can get a flavor of how to utilize the functionality. Keep in mind those Application Accounting Definitions have been built by the very people who have build the product, so you can pick up on techniques which work best. But don’t let those Application Accounting Definitions scare you, they are pretty advanced and at your first attempt of building an Application Accounting Definition you shouldn’t try to aim for the same level of complexity.

Each event will generate (at least) one subledger journal entry. So what you don’t want to do is setting up separate Event Types for your debit and credit journal entries, because that will slice your subledger journal entries in half.

Play around with the functionality, that’s the only way to really get your head around it. The possibilities are virtually endless, but just try to keep it simple. That’s also what I will do in my journal pass-through example.

Here I’m using the minimum setup required, which is: 1 Event Entity / 1 Event Class / 1 Event Type. That’s also the recommended configuration when implementing journal pass-through.

Under the [Identifiers] button, we uniquely identify our transaction. So in this case, JP01_JRNL_NBR is what uniquely identifies each transaction.  It’s the primary key in my header Transaction Object. This will all make more sense once you’ve read point 6.

Under the [Event Classes] button, we set up the Event Classes (in this case only one), and for each Event Class the Event Types (again only one in this case).

Don’t forget to tick the “Accounting” flag, else your Event Type won’t be generating any accounting.

To taste a different flavor, also have a look at the seeded Event Models for the Oracle subledgers (AR, AP, FA,…). 

  

5.       Create Process Categories

N > Custom Responsibility > Subledger Accounting Setups > Accounting Methods Builder > Events > Process Categories

Process Categories will in the next step get tied to the Event Class. Process Categories are an optional parameter when running the Create Accounting program, so in effect they allow launching Create Accounting runs per Event Class, instead of for the entire Application.  

6.       Set Accounting Event Class Options

N > Custom Responsibility > Subledger Accounting Setups > Accounting Methods Builder > Events > Accounting Event Class Options

Don’t let the name fool you, the Event Class Options aren’t optional, or at least not all of them.

What is optional is the first tab, the “User Transaction Identifiers”. Remember under 4) we defined the System Transaction Identifier(s) allowing the application to identify each distinct transaction. For an end user however, an internal ID doesn’t say much. So that’s where the User Transaction Identifiers come into play. For instance: INVOICE_ID would be a System Transaction Identifier, while INVOICE_NUMBER could be a corresponding User Transaction Identifier.

In order to be able to add User Transaction Identifiers, you first need to specify the name of the database view from which you will be selecting the User Transaction Identifiers. Add this name in the Transaction View field. Then under the User Transaction Identifiers tab, you can add up to 10 User Transaction Identifiers.

In this example I didn’t add any, just to demonstrate that it’s an optional step (and also because I got lazy). If you do add User Transaction Identifiers, then these will be displayed in the OA Framework pages where the user can query accounting events (remember under point 2, I mentioned adding the “SLA:  User Main Menu”).

And you also have the option to display the User Transaction Identifiers in your Create Accounting concurrent request output file, by running the Create Accounting request with parameter “Include User Transaction Identifiers” = Y. Just have a play with this; it will make perfect sense once you see it, and your users will like it.

Also note that in the top region of the screen, we added the Process Category which we created in the previous step. And we also added a Default Journal Category. This Journal Category can be created under General Ledger > Setup > Journal > Categories. It’s called “default” because the Journal Category can optionally be overridden at ledger level.

Under the Objects tab, you register your Transaction Objects, and this is a crucial step in your setup. The Transaction Objects are the tables or views in which the data from your external source system resides. It is recommended to use views instead of tables (even if the view is a simple select * from table), as views provide you with flexibility you may need at a later stage in your implementation.

In this journal pass-through example, I’m using a header Transaction Object which contains my journal headers, and a line Transaction Object containing my journal lines. I don’t want to get sidetracked by going into the details on why you need to do this, but if you’re using journal pass-through, then always use a header and a line transaction object.

Once you’ve registered your Transaction Objects, click the [Create and Assign Sources] button. This will read the Transaction Objects’ definitions and load the object’s columns as - what we call - “Sources”. So in effect, the structures of your Transaction Objects are being read and the columns from the registered views will be created as Sources. If you got a column named “JOURNAL_DATE” in your Transaction Object, then a Source named “JOURNAL_DATE” will be created for you. Sources are the building blocks you will use during the rest of your setup.

You can see the Sources under the [Source Assignments] button.

Now we will define the Accounting Attribute Assignments. Most of the FAH setup is used to derive the accounting flexfield combination, but there are of course other elements that constitute a journal, and those other elements we define under Accounting Attribute Assignments.

I’m again setting up the plain minimum, which are the below five Accounting Attributes.

In this example, Source “JP01_AMOUNT” serves as input for my Entered Amount. Because “JP01_AMOUNT” has been marked as the default, any Journal Line Type which I will build in the next step will automatically inherit this default value. If I have the need however to overwrite the default value on individual Journal Line Types, then this is possible, but any Source which you want to use as an Accounting Attribute Assignment somewhere in your setup, first needs to be registered in this Accounting Attribute Assignments window.   

In my example Transaction Object, the Debit and Credit amounts can be found in the “JP01_AMOUNT” column. If however your Transaction Object would contain separate Debit amount and Credit amount columns, then in your Accounting Attribute Assignments window, you would register two rows: one with Accounting Attribute Entered Amount = Source “Debit Amount” and the other one with Accounting Attribute Entered Amount = Source “Credit Amount”.

This would then allow you to select the appropriate Accounting Attribute Assignment at Journal Line Type level.

So you should look at (some of) these Accounting Attribute Assignments as the pool of Accounting Attributes which you can utilize further down the setup chain.

The Default flag region is grayed out. The background to this is that this form is also being used by the seeded Application Accounting Definitions for the Oracle subledgers, in which case users are not allowed to touch the default flag. There is a Profile Option which allows FAH customers to make the flags updatable, but I suggest you just use the Tools > Diagnostics > Examine functionality to set default_flag = Y

Click the [Validate Assignments] button to check if everything is complete and correct.

7.       Create Journal Line Types

N > Custom Responsibility > Subledger Accounting Setups > Accounting Methods Builder > Journal Entry Setups > Journal Line Types

Again I’m not using any clever options. The only things to note: I’ve set up a Debit Journal Line Type and set Switch Debit/Credit = Yes. Not using any conditions and haven’t updated the Accounting Attribute Assignments on Journal Line Type level.

8.       Create Account Derivation Rule

N > Custom Responsibility > Subledger Accounting Setups > Accounting Methods Builder > Journal Entry Setups > Account Derivation Rules

Here I’ll just make up some random stuff.

This is an Account Derivation Rule which populates the entire accounting flexfield with a constant value:

This is an Account Derivation Rule which populates the Cost Center segment with a value directly inherited from the Source system.

And this is an Account Derivation Rule which derives the Account segment while making use of a Mapping Set:

While this is the Mapping Set used in the above Account Derivation Rule.

Note that in the Account Derivation rule you have the flexibility to set up a hierarchy of rules each to which you can tie conditions, something which I didn’t do in this example. 

9.       Create Journal Lines Definitions

N > Custom Responsibility > Subledger Accounting Setups > Accounting Methods Builder > Methods and Definitions > Journal Lines Definitions

The Journal Lines Definitions is where we bring things together and tie Journal Line Type(s) to Account Derivation Rules.

Note how I’ve used the “All Segments” Account Derivation Rule to first populate my accounting flexfield with my default account combination. This technique ensures that all my segments will be populated. Then the subsequent Account Derivation Rules will be evaluated and if a value can be derived from those Account Derivation Rules, then that value will override the individual segment value from my default Account Derivation Rule.

10.   Create Application Accounting Definition

N > Custom Responsibility > Subledger Accounting Setups > Accounting Methods Builder > Methods and Definitions > Application Accounting Definitions

Here you tie the Event Type to the Journal Lines Definition. Click the [Validate] button to confirm your setup is complete.

11.   Create Subledger Accounting Method

N > Custom Responsibility > Subledger Accounting Setups > Accounting Methods Builder > Methods and Definitions > Subledger Accounting Methods

In the final step we attach the Application Accounting Definition to the Subledger Accounting Method. The Subledger Accounting Method is tied to your ledger.

To complete the circle: in the introduction I said you will need to call the create event API. One of the API input parameters is the ledger_id. The ledger you use there should be a ledger which is using this Subledger Accounting Method.

And that’s it. Now you’re ready to create accounting. From here on you can start exploring all the other functionality FAH has to offer.

Hopefully this has been of use to you, but if you managed to read all the way up until here then I guess it has. Have fun playing around, and be careful ;-)

Financials Accounting Hub - Sharing Accounting Rules

Originally posted 10 May 2009 on oraclecs.com

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.

* Update: and also take into account the performance aspect of this decision. 

I like my SLAM – why can’t I reuse it?

Originally posted 7 January 2009 on oraclecs.com

Recently I had a discussion regarding custom Subledger Accounting Methods and their reusability. As you know, out of the box we provide 4 seeded accounting methods (Standard Cash, Standard Accrual, Encumbrance Cash, Encumbrance Accrual) and these can be reused at will as such a seeded SLAM can be attached to any ledger, regardless how that ledger’s chart of accounts looks like. 

So why is it that when you build a custom SLAM the above isn’t always the case?

The answer is simple: the seeded SLAMs are accounting flexfield independent: if you look at the seeded SLAMs you’ll notice they don’t have a chart of accounts assigned to them.

This will allow you to use the SLAM against any ledger you like.

Such an accounting flexfield independent SLAM is made up of individual underlying components which in their turn or also all accounting flexfield independent, like for instance this Application Accounting Definition:

So why not always use an accounting flexfield independent SLAM then?

The reason why you would choose to build an accounting flexfield dependent SLAM is because if you nominate a chart of accounts SLA will allow you to derive each individual segment of your chart of accounts.  

While in case of an accounting flexfield independent SLAM, you can only nominate the accounting flexfield segment qualifiers.

But of course in the case of the second example this does not mean that the remaining segments are left alone. Even when SLA is not aware of the chart of accounts, it can still look in the subledgers and take the full accounting flexfield directly from the subledgers.

So when you’re building a SLAM (either based on a seeded SLAM or you’re building a SLAM entirely from scratch e.g. when implementing FSAH) then first take a minute to think about how you would like your SLAM to behave: dependent or independent of a chart of accounts. 

Create your own workspace - Set an Accounting Methods Builder context

Originally posted 12 January 2009 on oraclecs.com

Using the AMB (Accounting Methods Builder) context functionality you can create a dedicated work area which allows you to copy over AADs (Application Accounting Definitions) from the default context into your personal context, make changes to these AADs, and when satisfied, copy back the AAD to the default context.

  

The following is intended as a quick tutorial on how to use the AMB context functionality.

1)      Define a new context value under subledger accounting lookup “XLA_AMB_CONTEXT_TYPE”

2) Assign the new context value to profile option “SLA: Accounting Methods Builder Context”

Note: to avoid mistakes the tidiest thing to do would be creating a new application responsibility and assigning your context at the responsibility level of this dedicated responsibility. This allows you to quickly switch between contexts just by switching application responsibility. Alternatively, you could of course also choose to switch the profile option back and forth.

Now that you have activated your new context, the Application Accounting Definition and all the underlying components striped with an AMB context will show the context value in their respective windows:

So at all times you can see under which context you are working.

You can now use concurrent requests “Import Application Accounting Definitions” and “Export Application Accounting Definitions” to export your AAD from the default context and import it into your custom context. You can make the wildest changes you can imagine in your custom context because if things go wrong you can always revert back to your default context (kind of like a mini backup). But if you like your experiments and they turn out to be successful you can copy the new AAD from your custom context into the default context.

Tip: when exporting an AAD a .ldt file is written on your file system, in the destination path specified when submitting the request. The import program then picks up this file. But you can of course pick up the physical file yourself and apply it to other instances just as well. So when you have built a custom AAD (e.g. you have made modifications to a seeded AAD in order to fulfill country x’ statutory requirements) then you should export this AAD and slip it into your consulting briefcase because you might be able to reuse this AAD at your next project. 

Profile Option “SLA: Enable Diagnostics” : How not to use it

Originally posted 23 December 2008 on oraclecs.com

As diagnostics functionality tends to be very useful, most implementers when arriving at a site immediately enable all diagnostics. In case of profile option “SLA: Enable Diagnostics” this might cause more bad than good, and here is why:

First of all it’s important to understand the basic concept of SLA. When SLA creates accounting it doesn’t physically store all the data from the subledgers into the XLA tables. Instead SLA uses views to look directly at the subledger data it requires (you can see these views in the SLA Accounting Event Class Options window under the Transaction Objects tab).

But when profile option “SLA: Enable Diagnostics” is set to Yes, SLA will not only look at the subledger data through the abovementioned views, but it will also physically copy over all that data into an SLA diagnostics table (XLA_DIAG_SOURCES).

The reason why SLA does this is because you enabled SLA diagnostics, so SLA expects that you will want to run the Transaction Objects Diagnostics report. But in order for this report to be able to pick up data, SLA first needs to make the data available, therefore it copies over all the subledger data to the SLA tables so afterwards the Transaction Objects Diagnostics report can print the data for you.

This copy process happens during Create Accounting so when you run Create Accounting while the profile option is set to Yes you should also notice a decrease in the Accounting Program’s performance (because all the inserts into XLA_DIAG_SOURCES are being executed).

Correct order of events when diagnosing SLA:

1) Enable profile option “SLA: Enable Diagnostics”
2) Run “Create Accounting”
3) Disable profile option “SLA: Enable Diagnostics”
4) Run “Transaction Objects Diagnostics” report
5) Run “Purge Transaction Objects Diagnostics”

Conclusion:
Keep the profile option away from so-called “overenthusiastic profile option switchers”. I’ve seen a case where the profile option was set to Yes at Site level meaning every single run of Create Accounting copied all source data from all subledgers to the XLA scheme eventually causing the database to run out of space. Although this was in a DEV instance without security policy it still proves that this (and in fact any) profile option should be handled with care - if you don’t know it then please don’t touch it.

When you do use the profile option then use it as it was intended to be used: run Create Accounting for a very small amount of data. It really doesn’t make any sense to try and diagnose a large volume of data because you will get lost in the Transaction Objects Diagnostics’ output file.

When you’re done diagnosing do not forget to switch the profile option back to No.

As soon as you’ve run your Transaction Objects Diagnostics report you can run Purge Transaction Objects Diagnostics request. This will purge the diagnostics data from XLA_DIAG_SOURCES. You can still continue looking at the data because that’s saved in the Transaction Objects Diagnostics’ output file.

An introduction to the Financial Services Accounting Hub (a.k.a. Financials Accounting Hub)

Originally posted 15 November 2008 on oraclecs.com

Note: since the original publication of this article back in 2008, the product has been renamed from FSAH (Financial Services Accounting Hub) to FAH (Financials Accounting Hub). The name change has not been reflected in this article.

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.