Use Supporting References in SLA and you can see SLA generated and manual JEs in the same inquiry.

Setup
First you have to define a supporting reference eg PO Number, then define which Event Classes and the source that has the PO Number, whoohooo this even goes across appl_ids so following PO example, assign it to Invoices in AP and Purchase Orders in PO.

Supporting References can be assigned to line (JLD) or header level (AAD) for Accounting Engine Generated Journals and directly entered for Manual JEs from the page.

In the JLD, you assign to the JLT, which is a bit tedious though needed if the value can be different for different JLTs in the same event class. In the AAD, choose header assignments

NOTE: If you have maintain balances, you can only assign to the line level.

Entering
For journals generated by the accounting engine your JLD/AAD setups will automatically populate, for manual SLA journals you have to remember to enter them in the UX.

Viewing
In the standard inquiry for journal header/line you will be able to see the supporting reference as a column that can be used as a query criteria.  There are no standard reports but the data model is fairly simple. There are analgous header and lines for supporting references as well as a balances table.

I’ve received some specific requests to help people out on this, but each situation is specific to setup and data sets, I’ll talk about in general.

Some questions to answer before starting to help decide what direction to take

1. how often am i going to change the rules
2. who is changing the rules – do they understand the business (ie from functional point of view) or its IT folks

Why does it matter? SLA is designed to be highly modular, but you don’t have to take advantage of it if you don’t want to.  A single ADR can be used in many places, a JLT can be reused within an event class in many JLDs.  You can be like me who thinks I want the smallest number of rules possible ie a tight solution BUT the bad thing is that unless other people understand how all the pieces fit together, you will be the person who has to keep changing the rules!  The other extreme is that you never reuse, have JLTS, ADRs used only in one place, easier for others to understand and changing one rule doesn’t affect anything else.  So what’s wrong with that method?  its mostly a maintenace issue and having a larger amount of seed data to maintain.

Ok once you’ve decided how to structure your rules, here’s what I do when customizing rules

1. enter sample transaction, create accounting using a seeded SLAM
2. review in dist links table to see which JLT was used
3. if you want to add addtional JE lines “copy” the JLT that is closest to what you want the new line to be
4. if you want a different account, look at the JLD that is used and find the ADR associated with the JLT, you can also copy ADRs and modify them
5. on your “copied” JLTs modify the conditions DR/CR or whatever else you need to meet your requirements
6. validate and hope it works! sometimes it takes a few tries and if you are just starting out there is a bunch of trial and error
7. don’t forget DRAFT accounting, this will allow you to reuse the same transaction until you get it right

Ok I’m starting off to clarify this is a hack/backdoor/”workaround” and of course not supported by Oracle development or support or anyone associated with Oracle, ie you are on your own!  So why am I telling you? its one of those tricks that can be pulled out when you need a quick cheap and temporary solution. 

The SLA upgrade flag’s intended use is to bypass the “regular” logic and use “upgrade” logic.   There are two features in SLA, Business Flows and Reversals that require previous accounting to be present in SLA tables in the “regular” logic.  The upgrade logic does not do the look back.  This feature is used by Federal and Public Sector SLAMs seeded in R12.

Why is this cool? you can use this to change SLAMs, on seeded rules this will work if you are changing to the seeded Federal and Encumbrance SLA rules, you will not have to worry about SLA erroring out or having to create the “missing” SLA journals. 

You can also use this for your custom rules if you happen to have a specific case where you want to bypass the “regular” SLA logic.  Though consider using SLA JLT conditions first!  There are hundreds of sources and you can add more via reference objects, however for a quick and temporary fix you may want to try this.

Actions that you do in the subledger (eg Validate Invoice) raises an event to SLA this is analogous to buying tickets online for a show that will be used at a later time and being held for you at the venue.

1. Event Class = choosing what type show  eg Movie or Concert or Live Theatre (Invoice, Payment, etc)
2. Event Type = the specific show you want to go to within the event class – eg Movie, Indiana Jones and the Temple of Doom (Validate, Cancel, Void, etc)
3. Event ID =  Once you have chosen and bought the ticket you are given a confirmation number

Running Creating Accounting is showing up to the venue and giving your confirmation number to the ticket booth.

The ticket taker looks up the confirmation number to determine what exact show you want to see and to determine if you want food/drinks and where you are going to sit,  she also needs to know some attributes about you based on your national identification number (NIN).

Based on the NIN they can find other information about you, your food/drink and seating preferences and also what you are allowed to choose from.

Indiana Jones is playing at 4 theaters, based on the NIN you are directed to the theater that has been assigned to your NIN and the which section, row and seat you sit in.  You are allowed popcorn but not butter, no soda but wine or water is ok.

The Create Accounting program determines how to process the event ( confirmation_number) and based on the ledger (NIN).  The SLAM is attached ot the ledger (ie rules assigned to NIN).  The event determines the event class/type (movie/indana jones) and additional information (sources) is gathered about the specific transaction being processed.  The SLA rules determine which journal lines/ accounts/description are generated ( which theater, row, seat, food options).

The NIN is the Ledger, the rules assigned is the SLAM,  the AAD is which theatre, JLD Section, JLT Row, ADR Seat.

The choice of primary ledger 4 Cs (Currency, Calendar, Chart of Accounts, aCcounting) may seem to be a choice of what the resulting journals and balances look like in your general ledger, but its also influences how transactions are captured in the subledgers.

A few things to consider:

1) Is it legal?

This is a broad spectrum, from strict rules on transaction capture on one or more of the 4Cs which gives you no choice, to legal reporting without restrictions on how your software is configured (only that you produce the report) in which you may choose your corporate 4C’s instead of local.

2) Transactions are captured ONCE

You need to capture ALL the information you need to meet all processing and legal requirements when the transaction enters the system.  Does change of any of the 4Cs affect how this information is captured?  

3) Transactions can be have MULTIPLE accounting representations

With SLA in R12 you can create many accounting representations directly from a single transaction.  (This differs from previous releases where differing accounting representations where only available at the ccid/balances level only) This frees you from 4C restrictions if the purpose is only for accounting.

In Release 12 SLA, the account that goes to GL is built by SLA rules using the hundreds of transaction attributes provided by the product teams, so  does the accounting flexfield (AFF) on the transaction doesn’t matter any more?

On the surface the AFF seems no longer important, or atleast not as important as it use to be, however with some retraining of the user of what AFF on the transaction means, it can be a way to capture non accounting related information that doesn’t already exist.

Sound like a Descriptive Flexfield to you? Yes, it is but the difference is the AFF is more prominent on the UI, its available in searches and standard reports.  

Wow that’s great you say, small (big) caveat, the AFF is still the AFF, ie the structure and values are shared by the Chart of Accounts. You can get around this by creating segment security rules to overload the value problem.  Other issue that I mentioned above, having people understand when the AFF is really the AFF or when the AFF is a structure to hold additional transaction attributes.

The SLAMs shipped by development were to replicate and preserve R11i handling of accounting.  There is no need to use these seeded SLAMs.  The whole purpose of SLA is to have a flexible rules engine, that YOU can choose what accounting is created or must be created for your legislative requirements.

Some examples:

1) Encumbrance Accural  – does not contain any rules to create accounting for Fixed Assets

Create your own custom SLAM by copying Encumbrance Accural and then adding the standard Fixed Assets Standard Accural AAD.  You do not need to worry about customization in this case as you are still using all the standard rules shipped by Oracle.

2) Encumbrance Accrual contains rules in Accounts Receivables for the multi-fund receivables which I don’t need

Create your own SLAM and replace the multi-fund AR rules with the standard accrual ones which goes to a single receivables account.