8 Doubts on Oracle SubLedger Accounting

Time to answer some questions on Oracle SubLedger Accounting! Last week we had our webcast “Everything You Didn’t Know about SLA” and we had a lively Q&A session with more questions than we could answer live. Our CTO has taken the time to answer all doubts and today we bring you a transcript. If you missed the webcast and would like to review the recording, click here.

What are the changes in SLA R12 versions?

SLA was first introduced in 12.0, and since 2007 Oracle has released many “point” releases (12.1, 12.2 etc.) with many new features: we see integrations, additions that can help regulatory requirements. But if you are in 2.1.3 and plan to go to 12.2.4, don’t be afraid of major changes – only some items have been added. Since SLA depends on other modules, these additions are relative to each module.

In its most basic form, is SLA a “central” repository of the detailed transactions from the modules (sub-ledgers (AP, AR, FA, Projects)?

It is a central repository, but actually not a central repository for everything, as that would be GL. So it’s a central repository for each of your modules. What I was referring to is how an accountant learns: “Okay I’m going to have a subledger here, and then I’m going to have my little box here, and then I’m going to transfer that into my big book, the GL”.

How do you reconcile the differences between the final accounting in SLA/GL and the “suggested” accounting you see in the sub-modules?

With SLA we have a report, and you can either use the standard reports or others made in, for instance, CloudIO Reporting WorkCenter or Discoverer. Within SLA, you can preset the accounting general entry based on your rules, so in terms of how to reconcile your suggested accounting to the final accounting, there are many tools and many ways. It’s just a matter of which method you prefer. But let’s take a minute to consider the reconciliation: in some cases it’s just going to the source and pointing to a general entry based on a certain transaction. What you are probably going to do is change the accounting based on what you want to achieve, it’s not that you must reconcile. You’re probably going to reconcile to make sure that is the accounting you really want based on your method and standards. In terms of reconciling back to the module and back to the transaction, it’s going to be based on the drill down and the capability of adding descriptions and details of how that accounting was created.

The question is more about the functional confusion of seeing different accounts in GL than in the sub-ledgers.

Your question refers to the “suggested accounting from the module might be changed through SLA” and how that could be reconciled with the setups that were performed in the modules or the accounts that are being entered in the distributions of the transactions. There are forms that would allow you to drill down from your primary ledger to your SLA and access to the transaction that has generated that journal entry. There are also a good number of pre-built reports that will facilitate the information for reconciliation purposes from your primary ledger to SLA to transaction.

I have tried to create reports using the XLA and SLA tables.  What I find is that it takes way too long to pull any of the data.

The short answer to your performance issue will be:

  • Have you checked the table statistics?
  • Have any of the tables involved been analyzed lately?
  • Verify the explain plan for full table scans.

The XLA – Subledger Accounting schema has 153 objects so it could be difficult to work with these tables and views if you’re not familiar with them. The larger the organization, the bigger the trouble. My recommendation would be starting with the initial considerations that I mentioned to make sure it is not a database issue.

Why is SLA failing to validate transactions coming from 11i after migration to R12?

It is a very interesting error. I have not seen this error in other upgrades or our knowledge repository. I’d recommend opening a Service Request at My Oracle Support, or if you are interested in having IT Convergence help, reach out to an account manager who will be able to assist you.

If you are upgrading Projects from R11 to R12 and you already have complex AutoAccounting Rules, do these have to be “re-created” in SLA?

The best answer to this would start with a question: how do you describe complexity? Even though the rules are complex, it is not mandatory to re-create everything in SLA since it will be based on the standards and will be migrated. Now, if you have custom queries to some tables that are exceeding the standards, you might have to re-create.

How does SLA get integrated with Retek and Retail?

The documentation for the integration between Oracle E-Business Suite and Oracle Retail, including all the modules can be found in the following note at MOS (Oracle Retail/Oracle E-Business Suite Integration Guide (Doc ID 761676.1)).

Since the integration is done through BPEL, it does not interact with SLA. Oracle Retail applications populate the STG_FIF_GL_DATA staging table with general ledger transactional data related to Oracle Retail Sales Audit (ReSA) and stock ledger. Oracle E-Business Suite pulls this general ledger data from the Oracle Retail staging table, performs transformations, and populates the GL_INTERFACE table in Oracle E-Business Suite. This process is orchestrated by BPEL Process Manager using database adapters. BPEL Process Manager has error handling routines to accommodate system error scenarios.