New R12 CGAC & FV Consolidated Patches, Good, But…
Federal Development released a patch (9307787) for R12 in late December that provides a number of Federal Financials enhancements focused on better accommodating the OMB Common Government Accounting Classification (CGAC) attributes. The most obvious enhancements included are changes to the Treasury Symbols forms and related functionality. There is certainly more to the changes and a comprehensive document on the enhancements provided is available as MOS Note: 1277072.1.
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…
Oracle Federal Applications 
Leave a Reply