11i10 Patch 8448145: Allows entry of FV Budget Execution Entries for Expired Appropriations
I wanted to share an enhancement that we got Oracle to deliver a ways back for USAF DEAMS & share that the patch is available for download.
We have a requirement to enter Budget Authority increases/decreases, even after Appropriations are expired. This is because we need to move money around to cover various Expired Year adjustments necessary. I’ve seen other Federal organizations that have the same requirement, so wanted to pass this along. Until recently in 11i10, these adjustments could only be done via GL journals, since the FV Budget Execution functionality had a constraint to prevent Budget Execution entries against Expired Treasury Symbols. We had noticed this constraint had been removed from R12 Fed Financials and asked Oracle for the same capability in 11i10. They came through for us with patch 8448145 which removed the constraint and allows us to enter Funding Decreases/Increases through the standard Fed Admin Budget Execution form Functionality. To fully utilize the new capability, we then setup some new Budget Execution Transaction Types/Transaction Codes to use for Expired Funding Adjustments to drive the proper USSGL accounting for Expired Year transactions. The removal of the constraint along with the set of Expired Approp TransTypes/TransCodes provided what the Budget Users needed to allow the standardized use of Fed Admin Budget Execution functionality for both current and expired funds.
This consistent, standardized Increase/Decrease adjustment method provides a one-stop shop for adjustments and eliminates the need of the manual journals for the expired year Budget Authority adjustments. The elimination of the manual journal need is key, because it mitigates the risk of erroneous entries being created. As of now, we’ve focused on utilizing the capability via the forms. As time permits, we also want to explore if the constraint has also been removed from the FV Budget Execution Interface as well.
If your agency deals with this requirement/issue, I believe this functionality could benefit.
Read Full Post | Make a Comment ( None so far )Validate updated version of FVBEFDCB.pls is installed to leverage ‘FV: Enable funds check / reservation based on the line level’ profile option functionality
I’ve run into 2 instances just recently related to the profile option ‘FV: Enable funds check / reservation based on the line level’. One is where we’re doing testing on my current USAF implementation (discovered the profile option wasn’t having any effect) and the 2nd was in helping a different agency through some year-end stuff. I first learned about this profile option a while back in reviewing metalink note: 430836.1 titled “US Federal Financials Budget Execution – New Profile Options”. This profile option is intended to control how the FV Budget Execution transactions create the Accounting Flexfield (AFF) values (aka GL code
combinations) for the Debit and Credit entries generated. Here’s an explanation of what it does and the issue we seemed to have.
The Old School Way:
For background, the method I remember seeing historically for creating the Debit & Credit entries from the budget execution transactions was that both the DR & CR were created based on the AFF elements entered on the budget transaction line (table: fv.fv_be_trx_dtls). So for example, the following would occur (just using a sample basic AFF of Fund, Org, USSGL, ObjClass):
Approp:
DR 0100.0.411901.0
CR 0100.0.445001.0
Apportionment:
DR 0100.0.445001.0
CR 0100.0.451001.0
Allotment:
DR 0100.A.451001.200
CR 0100.A.461001.200
Then subsequently, the funding is obligated:
DR 0100.A.461002.211
CR 0100.A.480101.211
For the above example, assume that funds are managed by a summary template where Fund = D, Org =D, USSGL = ALLOTMENT, ObjClass = OC_RG (a rollup group to control at the labor (100) vs non labor (200) summary balances. This method creates a problem at year-end. When the balances from 445001, 451001, 461001, 461002 all roll into 465001, then the balance in the 0100.0.465001.0 is positive (funds available), yet the balance in 0100.A.465001.200 is negative (deficient/overspent). These funds balances need to be realigned back into the proper place if detailed level funds controlled is continued to be desired (i.e. below the fund level).
New way, achievable with FV: Enable funds check / reservation based on the line level set to ‘No’:
Utilizing the referenced profile option set to ‘No’, will enable the following behavior (notice the difference between the AFF values created in the Allotment Debit):
Approp:
DR 0100.0.411901.0
CR 0100.0.445001.0
Apportionment:
DR 0100.0.445001.0
CR 0100.0.451001.0
Allotment:
DR 0100.0.451001.0
CR 0100.A.461001.200
Then subsequently, the funding is obligated:
DR 0100.A.461002.211
CR 0100.A.480101.211
This option preserves keeping the funding in the proper distributions throughout the closing process. It also provides additional flexibility for distributing and controlling funds in the budget execution process. Note 430836.1 mentions this functionality is “highly recommended for US Federal Financials implementations using Budget Execution functionality.”
Supposedly, per the metalink docs and in looking at patch 4699472, this profile option and the updated FVBEFDCB.pls (115.28 2005/10/03) are delivered in the same patch. However, we were seeing that the profile option existed, yet we had an older version of the package. If anyone else notices these are out of sync, suggest applying/reapplying patch 4699472 (4699472 is for 11i10 customers, other patches available for 11i8,11i9 customers). There isn’t much on this patch, but Note: 341043.1 is the metalink reference note for it. This patch provides an updated version of the Fv_Be_Fund_Pkg body (FVBEFDCB.pls). This package does funds checking for the Budget Exection transactions and produces the AFF values to be used for funds checking in gl_bc_packets and eventual journal posting in gl. Prior versions of this package don’t check against the profile option value, but this package introduces the condition to check against the profile option thus making the functionality available, i.e. it now includes the following:
IF
fnd_profile.value(‘FV_BE_FUNDS_CHK_LINE_LVL’) = ‘Y’ THEN
–Initialize dr arrays with values from document header
–Initialize cr arrays with values from document detail
–Modified the following line for bug# 3870382
–initialize_gl_segments(l_header_segments,l_gl_dr_segments);
initialize_gl_segments(l_detail_segments,l_gl_dr_segments);
ELSE
initialize_gl_segments(l_header_segments,l_gl_dr_segments);
END
IF;
initialize_gl_segments(l_detail_segments,l_gl_cr_segments);
Good Luck.
Read Full Post | Make a Comment ( None so far )
Oracle Federal Applications 