As soon as we can get our hands on these new GTAS patches, we need to jump on them to start understanding some of the impacts to our EBS environments in further detail.  As the Federal E-Business Suite community, we don’t really have much time to be able digest, test and prepare for these changes.  First required reporting cycle for GTAS is after Nov FY13 month-end (Calendar Nov 2012) and the fact that GTAS will only accept Bulk File feeds (i.e. no pencil whipping any numbers like with FACTS today), means we’ve got to be ready with this stuff working.  If anyone is looking for more info from Treasury on GTAS, you can find it here.

For R12 Fed Financials Installs who jumped on the CGAC & FV 90000001 patches early (me and my local Denver Federal Financials Shared Service provider!), at least we have that piece behind us.  But certainly there is more coming, especially for all the agencies still on 11i.

Here’s the link to the deck I scored:

Oracle Federal Financials Spring ’12 Development Update

If you’ve been following the twitter feed, you know I’m heading to Collaborate ’12 to present two Federal Financials R12 sessions and catch-up on as much news/info as I can there.  The FED Sig meeting is on Monday, maybe that will help.  Keep watch on the twitter feed for anything I pick up relevant to the Federal EBS community.

If anyone has any comments or knowledge to share that you feel would help spread key info, please don’t hesitate to comment.

–Larry

Here is the link:

OracleFedForum EBS Directions

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…

This datafix process can now be retired due to Patch 8975321 in 11i.  This Patch provides a new concurrent program ‘Program – Restore Journals’ as a replacement for the previously required datafix steps.  The program requires journal batch name as an input parameter and the program essentially executes the same steps as the datafix did. 

The My Oracle Support (MOS) note on this new functionality is:

GLXJEENT Funds Status Is Showing ‘In-Process’, Can Not Post Journal [ID 1141794.1]

It is also interesting to note that the original bug for this issue (944420: NEED A CONCURRENT PROCESS TO FIX JE AFTER FAILED FUNDS RESERVATIONS) dates back to 1999!!

Just wanted to share as this new functionality should save a good amount of time when encountering this issue going forward and mitigate the risk of having to run the datafix update.

Here are links to two Oracle/CACI Press Releases on the new CLM product.  Press Release 1. Press Release 2.

Here is the link to the Oracle DataSheet on the new CLM product.

To help spread the word, Oracle & CACI are hosting a webcast on the new CLM offering on Thursday, November 4th at 2pm Eastern.   Click here for the Oracle Event registration page.

When Googling for any CLM-related news, I also noticed a few YouTube videos have been posted, so I thought I’d have a little fun & embed those links as well for anyone interested.