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 ;-)