Here’s a PDF copy of it to print off: R12 Simple ERD of SLA AMB Components

In addition, here’s the SQL from a SQL Developer report I’ve developed to provide a data extract from the above which documents most SLA configs: SLA JLT and ADR Detail for AMB Components SQL.

Hope it helps..

FYI if using #FedR12 PPD+ Payment formats, the Header TRAVEL/FEDTVL (& similar) identifiers are no longer driven by the FV Paygroup mapping.—
  (@OracleFedApps) May 27, 2011

#Winning

SLA Source values play critical roles in XLA event processing and R12 GL journal creation such as:

• fundamental data elements that drive how Journal Line Type (JLT) and Account Derivation Rules (ADR) are selected through the use of Sources in JLT and ADR conditions
• fundamental data elements which are assigned as XLA Accounting Attributes (e.g. the value of the accounted_amount) to the JLTs
• often used in XLA Journal Line descriptions defined

To really understand why the XLA engine selects applicable JLTs/ADRs and how the accounting attributes are derived, a solid comprehension of what’s behind SLA sources is key.  At the most basic level, Sources are data elements related to the specific detail transaction being processed by XLA event processing.  These data elements may be:

1. static and directly related to transaction being accounted, e.g. the CCID for an AP Invoice Distribution event being processed (ap_invoice_distributions_all.dist_code_combination_id),
2. static and indirectly related to the transaction, e.g. a DFF value related to a Vendor for an ap invoice (hz_parties.attribute1 joined in via ap_invoices_all),
3. dynamically generated or calculated during XLA Event processing and temporarily populated into a global temporary table for use by the XLA processing engine, e.g. the Upward Prior Year Adjustment Amount calculated for an AP Invoice matched to a PO distribution where the invoiced quantity exceeds po distribution quantity within tolerance (fv_extract_detail_gt.acc_unpaid_obl_pya_amount).

The Sources available for an Application (e.g. Purchasing) and the Source Assignments to Application Event Classes (e.g. Purchasing Requisitions) can be queried by navigating Setup > Subledger Accounting Setups > Accounting Methods Builder > Sources > Sources  or ….  > Sources > Source Assignments.

Great, right??  Well, being the control-freak I can be sometimes, I really needed to know more.  What tables or whatever are these Sources pulling from?  How are they getting their values?

Upon further analysis and digging, I started understanding that these Sources map directly to numerous database views.  The Source_Code is a direct key to the column names within views.  These views then can often be deconstructed to figure out the source table data element which is driving the source.  For sources which are already utilized in an existing Application Accounting Definition (AAD), the Source to View (aka extract_object_name) relationship can be shown by querying the xla_aad_sources table such as the following:

Furthermore, here is a query I’ve developed to be able to analyze the universe of various SLA sources available by Entity and Event Class (these are bind variables in the query) in SQL Developer:  Available SLA Sources by Event.

So that’s it, right?  Well, not quite.  Some views are simple to deconstruct to find the source data, whereas others point to tables like FV_EXTRACT_DETAIL_GT (for Federal Financials).  For example, the FV_XLA_PO_REF_V is like: select ….   prior_year_flag…. from fv_extract_detail_gt.  This table wasn’t something I was familiar with.  The …gt (Global Temporary) tables are tables that are temporarily populated during XLA event processing by some PL/SQL logic and then those derived/calculated values are made available to the XLA event processing engine via the views looking at the ..gt tables.  For example, when the XLA event processing engine detects the EBS environment is a federal environment, the XLA event processing will engage an FV “hook” which will then execute add’l FV-specific code as part of the XLA processing.  An example, is when the FV_SLA specific code will look at the BFY on a transaction vs the Period Year of the event being processed and then determine if the transaction is a Prior Year (prior_year_flag will be set to ‘Y’) or a Current Year transaction (prior_year_flag will be set to ‘N’).  Then an agency’s JLTs (& the standard Federal JLTs) can look at the Federal Prior Year Flag source value to determine if an Upward/Downward Accounting adjustment may be necessary.  For troubleshooting SLA, typically the values written to fv_extract_detail_gt can’t be analyzed outside of the XLA event processing db session, however there is an option to dump the source values written to a fv_extract_detail_gt_logs table if the FV: Debug profile is set to Yes.

Kindergarten stuff, right??  Hope this helps and good luck.

For example, in my years working in the Federal Financials space, I’ve seen a fairly heavy reliance on the gl_je_lines.referenceX (journal import references) columns for creating custom reports that provide subsidiary information (e.g. PO Number, Vendor, etc.) and gl information together.  I’ve seen reports/interfaces often built from gl_je_lines up to best ensure the detail reports balance with trial balance amounts.  In R12, the gl_je_lines.referenceX columns are no longer populated or are populated in a different manner.  Thus any custom report, interface, etc. that leverages these fields will likely have to be reworked (or overall approach addressed) to continue to meet end-user requirements.  The R12 GL -> Subsidiary drilldown path now runs through gl_import_references and a new suite of XLA tables as shown in this diagram.

An additional problem that confronts Federal Financials customers with this change is that the R12 Historical SLA Upgrade process does not upgrade 11i Accounting Events that are created from USSGL Transaction Codes (e.g. Budgetary Entries) into the new XLA tables.  Commercial R12 upgrade customers could likely just throw out the old model, assuming they upgrade all their old data necessary into the new XLA model, and re-build reports entirely off the XLA model.  However, to get a proper one-stop-shop blend of 4801 Obligation data that spans 11i and R12 for example,  Federal Financial customers have to blend queries utilizing both data-models.  This required blend can then have a detrimental performance impact on the underlying queries, so then it may also be likely that additional performance tuning may be required with the R12 rework effort.

Another R12 data model change that could impact a decent number of custom reports and potentially other objects deals with the new ap_invoice_lines architecture.  Any custom objects leveraging joins based on ap_invoice_distributions_all.distribution_line_number will certainly have to be reworked due to the change shown in this example to avoid cartesion products and/or errors with subqueries returning multiple rows.

There are numerous data-model changes with R12.  Oracle has recently provided the new EBS Data Model Comparison Report tool which is a good tool, but it is definitely going to take time to properly identify the impacts for each entity.  Other data model change areas I’ve been running into deal with include: 1) the new IBY Payments architecture (vendor payment and bank account information) , 2) Migration of vendor information to the TCA architecture (po.po_vendors, po.po_vendor_sites_all tables no longer exist, but there are apps views of po_vendors and po_vendor_sites_all that could be utilized), along with other miscellaneous changes.

I wanted to get the word out to help prevent underestimating the level of effort required for reworking custom objects with the R12 upgrade.  Hope it helps.

Fully understanding and implementing SLA for Federal Financials continues to be quite a challenge in a current upgrade I’m working on.  This is especially true when trying to ensure all the proper Upward/Downward accounting is properly done, but at the same time ensuring the PYA adjustments are not overstated as part of document revisions.

So, we thought we’d have a little fun and honor Colorado’s Microbrewing heritage with a nice new little home-brewed special for our team to help us enjoy our breaks away from the SLA grind.

I present: SLA Insanity.

Enjoy the pic…

These enhancements have been released for R12 Fed Financials only and the patch is currently in a controlled status for the 12.1 release.  I’ve been focused on a Federal 12.1.3 upgrade for the last few months and we made the decision to start trying out the new CGAC patch in January.  We ran into a few different issues resulting from the patch, but have been able to resolve them through a variety of additional patches, including the just released FV Consolidated patch 9000001 (also in a controlled status).  Some of our issues with the CGAC patch were due to invalid object conditions caused by some FV objects (views, PL/SQL packages, etc.) getting out of sync with each other.  The goal of this latest FV Consolidated patch is focused on providing the latest and greatest set of compatible FV objects.  We are continuing to test, but our initial experience with the 9000001 patch on top of 9307787 has been positive, with the exception of having to rework a variety of our different Subledger Accounting (SLA) configurations a bit to deal with some changes.  If looking at the CGAC patch, any agency will almost certainly need to go to the 9000001 patch as well.

Moving forward to uptake new enhancements is usually always a good thing, but due to the sensitivity and complexity of the R12 Federal SLA functionality, we must be a bit more careful with patching at this point in R12 than we might have been w/11i recently.

We’re used to the 11i10 accounting and USSGL transaction code model being very stable for a good number of years now, with patches hardly ever impacting the fundamental accounting process functionality.  For those who haven’t experienced it, the Federal R12 SLA Accounting Methods Builder (AMB) configurations and underlying code that drives some of the FV SLA Source values, has been fairly dynamic with R12.x.  A number of patches have changed around the behavior of the standard FV SLA functionality throughout the Federal Financials R12 maturation process.  Examples of these changes include: changes to standard FV Journal Line Type (JLT) and Account Derivation Rule (ADR) conditions, changes to JLT Accounting Attribute mappings, changes to the use/non-use of Business Flows in JLTs, changes to the underlying PL/SQL logic (FV_SLA_% PL/SQL packages) which drive the values of key FV sources, changes to FV_% views which provide SLA sources utilized in the AMB rules, etc.

These changes, while serving a proper cause to continually provide a better “Out of the Box” FV SLA template for Federal Financials customers, are a risk to entities on R12 in Production or in the process of upgrading R12.  Federal entities working with R12 must scrutinize new patches that could alter SLA functionality and test accounting models well to mitigate this issue.  If changes that impact are present, best-case is that rework to existing SLA configurations will be required (which could cause an upgrade or patch cycle to go a bit longer), worst-case is that accounting models are altered but go unnoticed in Production for some time.  The standard FV SLA definitions provided by development provide a solid jump-start to help agencies implement R12 SLA.  However, it is most likely that an agency’s SLA implementation will require a combination of Agency-specific SLA configurations along-side the standard FV rules provided.  This combination will likely work very well (ideally perfect, right?) based on a certain, specific SLA AMB Component & supporting object (pl/sql code, views) baseline.  However, if any changes occur to the rules and/or underlying objects that alter an agency’s SLA baseline, it could throw accounting processes for a loop.  An agency can insulate itself from JLT & ADR Condition & Accounting Attribute changes fairly easily by creating/utilizing agency-specific JLTs and ADRs (e.g. XXABC PO Unpaid Obligation instead of using the seeded FV PO Unpaid Obligation JLT).  However it requires significantly more work to protect against changes of how underlying source values are derived (e.g. FV Commitment Amount).  It seems that the primary option to protect against changes to underlying sources would to be just disregard the standard FV sources entirely & build a client-specific suite of Custom SLA Sources (aka PL/SQL Functions) in their place.  However, we really shouldn’t have to do that.

Oracle makes mention of this issue I’m describing in the patch 9000001 readme:

"If customer has customized the following AADs, they might need to revisit the below AADs to make sure they
have uptaken their Customized JLT per the new changes."

…however if you ask me, it should be in bold, so I wanted to take some time to highlight this consideration here.  There are definitely a good number of changes associated with the CGAC and 9000001 patch which alter the way the standard Federal SLA objects work.  So keep that in mind, when uptaking these patches.

Just to recap, I’d like to sum it with offering these couple quick recommendations:

• Try to make sure your agency (& supporting contractors if applicable) gets to know what is really going on with SLA under the hood.  This will help you be able to identify what kind of patches could impact your SLA configuration and assess any level of rework required.
• Insulate your environment from changes to JLTs and ADRs by creating agency-specific versions.
• If you’re in the process of an R12 upgrade project, try to baseline your SLA configurations & objects as best as possible, to mitigate re-work from additional changes that could come about from future SLA-related patches (rework would likely include reconfiguration time & re-testing).  Having to restart a R12 upgrade testing cycle due to a bunch of SLA Accounting updates won’t make our R12 Upgrade Project Managers too happy.
• Once stable/in production, keep an eye out continually for patches that could throw your SLA rules for a loop, especially changes to the FV_SLA% packages.

Hope this helps…

Here’s an attempt at sharing some of the past week’s events, announcements and information of Federal relevance (with a few other items) that I picked up.  The link to the Oracle Collaborate 09 Media Kit, which provides press-releases and additional info on a number of these items is available here.

E-Business Suite 12.1 Released – 12.1 (12.1.1) was made Generally Available on Monday, May 4th.  12.1 brings a variety of new capabilities to the table, but for the Federal community, the biggest news with 12.1 is the important step forward in the long awaited “Projects Federalization“.  12.1 now provides the capability to create the required USSGL Budgetary postings from PA Agreements/Fundings, Revenue and Costs.  Projects has never provided USSGL Transaction Codes or any other solution for creating these entries and this gap has been a long-time Federal Top-Ten enhancement request.

Other top 12.1 new features include:

-Practically all standard Oracle Reports now can be generated through BI Publisher (v 12.0 = 852 seeded BI Publisher templates, v 12.1 = 2600+ seeded templates)
-PA Agreement Definition Enhancements
-PA Agreement “Date Effective” Funds Consumption controls for revenue and invoicing
-The association of PA Agreements with AR receipts (to handle Unfilled Order with Advance Scenarios) and flexibility in controlling the proper accounting for associated revenue (e.g. drawing down the advance instead of recognizing a receivable and having to manually adjust)
-Revised AP Third Party Payment capability which provides the capability for associating a “Remit to Supplier” on an Invoice
-The capability to maintain line-level transaction balances for AR Invoices
-Additional standard data elements in Purchasing to support FPDS-NG reporting
-A bunch of new features in Sourcing including enhancements to capabilities for segregating Cost vs Technical proposal evaluations (“Two-Stage Evaluation for RFPs”)
-Secure Enterprise Search right out of the box (think of being able to use a Google-like search from any OAF page (i.e. your home page) & getting links to take you straight to the documents).  This capability is available for implementation in earlier EBS versions, but for 12.1, its available straight out of the box.
-Enhanced BI Publisher integration with OAF pages through the capability of a new Print button/link (or capability to add) on any OAF page, that will allow the initiation of BI Publisher requests (so for example, in iProc, then users don’t have to launch the JRE & submit a normal concurrent manager request just to print a hard-copy of a requisition)
-OAF Flexfield references: This brings the capability of core forms Context-Sensitive Reference Field-type functionality to OAF forms.
-Diagnostics Upgrades
-The capability to see record history in OAF pages (e.g. created by, last updated by)
-A variety of OAF personalization enhancements
-Announcement of the Application Change Management Pack (this is a new Oracle Enterprise Manager component available to assist with patch, customization, setup/config management, etc. across instances).
-iSetup enhancements
-E-Business Suite Native SOA Enablement (less need for the use of adapters)
-Enhanced User Management (UMX) reporting

Of course there’s more, but that’s probably enough to start with.  The 12.1 software is now available on edelivery.oracle.com, the 12.1 documents are available from OTN and Support Note 790942.1 is a good starting point for 12.1 resources.  I look forward to sharing more info on 12.1 over the next few months.  I actually was working on getting a 12.1 instance up & live during the event, but ended up needing to do more patching than I’d initially anticipated (I was hoping a quick, flawless rapid-install would be all that was needed) to support the latest Forms/Application Server version, so I wasn’t able to get it done yet.  But hopefully in the next few weeks, I can start playing with it hands-on and I’ll work to share what I find.

Per Oracle, the paperwork for FSIO certification of 12.1 has already been submitted.  Since nothing changed fundamentally and we’re only talking enhanced functionality here, this should be just a paperwork drill, so hopefully FSIO won’t wait too long in providing the go-ahead on 12.1 (it only makes things better, so why hold anything up).

BI Apps 7.9.6 Released – This is the latest version of the BI Apps content for OBIEE.  I blogged about this here for a bit more detail. I found it interesting to see in a couple sessions (even in Charles Phillips’ keynote) that the new Federal Financials Analytics were specifically called out on the slides or by the speaker.  Besides the Federal Financial Analytics, BI Apps 7.9.6 now provides Projects Analytics, in addition to other various enhancements.

11i10, 10gR2 DB and other software Extended Support fees waived for another year – Typically, Oracle provides premier support for a platform for 5 years and then starts to up the price if entities don’t upgrade, charging extra for “Extended” and “Sustaining” support.  Believe it or not, 11i10 has already been out for almost 5 years and although the 11i10 premier support had already been extended through Nov 2010, now 11i10 premier support has essentially been extended through 2011.  So, organizations that haven’t upgraded yet, can still get the same level of support through most of 2011 without having to pay extra fees for the Extended support.  10gR2 DB Extended support fees are waived through July 2011.

The Oracle messaging at the conference was pretty clear.  It was pretty much “We understand the current economic climate and know organizations don’t want to embark on large projects that take a while to show ROI, so here are the offerings we want to push that are smaller projects and result in a quicker ROI”.  Oracle was pushing BI Apps, the User Productivity Kit (UPK), Secure Enterprise Search (SES), the Application Integration Architecture (AIA) Process Integration Packs (PIPs).  The latest release of Beehive (Oracle’s new collaboration tool announced at OpenWorld last fall) was also announced.

A couple other nuggets I thought I’d pass along:

-Oracle is working on building integration with Federal Financials and the Hyperion Budget Planning/Formulation product.  So then, that should make for a potentially slick integration between the Budget Planning & Budget Distribution side of things.  It sounds like integration is also being built with HR Apps to facilitate the position budgeting integrated capability

-With all the talk about enhanced integration & AIA, I asked one of the Advanced Procurement speakers from development about if there are any plans to enhance the flexibility of the Purchasing APIs.  Of course he didn’t get specific, but mentioned that increased openess of the APIs is definitely on the roadmap.

-Regarding Fusion Applications, it seems that the Public Sector is on the back-burner for Fusion Apps.  So the apps will become available for commercial before being able to support all the specific Public Sector requirements.

Hope that gives a decent overview for now.  I’m sure I’ve got some other stuff in my head that I just can’t think of at the moment.  There are a bunch of other blogs I’ve seen talking about Collaborate announcements/events such as the Triora Group Blog, so be sure to Google for additional info or feel free to comment here if there’s anything else to share or if you think I can help with.

“The CGAC call for the FedSIG with Mike Barker, Director of Public Sector Development, will be a concall / web conference.  Here are the logistics:

Participants should use Internet Explorer for the web conference.  Participants should,  at their earliest convenience, go to https://conference.oracle.com and click on “New User” to ensure that their system is compatible to the Oracle web conference system.  To ensure success, please make sure that your pop-up blockers are turned off.  You might need to turn the blocker off, exit Explorer and then start it back up again.

If a user does not have admin rights to accept the downloaded applet to initialize the web conference, they will not be able to view the slides and, if possible, should join other participants in a conference room to view the slides.

Date: Wednesday, April 1, 2009
Time: 1:00 pm ET
Duration: 90 Minutes

Call In: XXXXXXXXX
ID and Passcode: XXXXX
Web Conference ID: XXXXXX

Please encourage all participants to call in about 10 minutes before the start of the call at 1:00 pm ET, so we can start on time.

The intended audience for this call is existing Oracle customers, who are subject to the non disclosure in their Oracle License Service Agreement.”

CGAC is the Common Government-Wide Accounting Classification Structure as published not too long ago by OMB FSIO.  I’ve heard that Oracle has  been making some changes in some of the table structures to better accomodate the definitions of some of the CGAC elements.  More info on CGAC is available at http://www.fsio.gov.