Important R12 FV PO Commitment Accounting Attribute Assignment Updates identified in patch 13610367
Patch 13610367, released earlier this year, provided an update to the seeded Federal Purchasing AAD that is important for all R12.1 Federal PO Customers to understand, even if not using the seeded Federal SLA definitions. The AAD change included updates to a couple of the key Accounting Attribute Assignments for the FV PO Commitment JLT.
The changes were:
Accounting Attribute Assignment: Allocated to Distribution Type, changed to source: Allocated to Main Document Distribution Type
Accounting Attribute Assignment: Allocated to First Distribution Identifier, changed to source: Allocated to Main Document Distribution Identifier
The SLA configuration we’re using at my current gig is non-seeded and agency-unique but modeled after the FV.B 9000001 seeded FV SLA definitions. At first, I didn’t understand how this patch could be relevant to us, but Support and Development were suggesting it was a solution to some PO accounting issues. Upon digging deeper, I realized that the accounting assignments are a key driver in how the po_req_distributions_all.encumbered_flag/encumbered_amounts are updated upon AutoCreate.
The way these come into play is that:
1) the XLA create accounting process will leverage the specific accounting attribute assignments to drive how data is inserted into certain columns in xla_distribution_links and then,
2) the po_encumbrance_postprocessing package uses the data inserted into the specific xla_distribution_links.alloc_to_dist_id_num_1 field as a key join for going back and updating the po_req_distributions_all.encumbered_flag/encumbered_amount data.
If the accounting attribute assignments populate the xla_distribution_links.alloc_to_dist_id_num_1 with bad data, the po_req_distributions_all encumbered data is not updated properly. This causes multiple problems with other downstream PO XLA processing related to the autocreated lines, such as PO Line Unreserve/Rereserve and Cancellation actions. Also, if customers have 4700 Reconciliation analysis built off these po_req_disributions_all fields, those Recons will likely be way off.
Honestly, I was not expecting that a SLA JLT configuration such as this would be a driver in that kind of PO encumbrance functionality, but now I know and wanted to share. For anyone with custom PO Commitment JLTs in environments using Requisitions, I recommend looking hard at this to see if it helps with any issues and you’ll likely want to make these updates in your PO Commitment JLTs as well.