Search Results po_bc_distributions_s

Overview

APPS.PO_ENCUMBRANCE_POSTPROCESSING is a server-side PL/SQL package body in the Oracle E-Business Suite Procurement module. Its business purpose is to finalize the financial and encumbrance consequences of purchasing activity after the primary transaction has been committed. When purchasing documents such as purchase orders, releases, and requisitions generate funding or budgetary accounting entries, those entries are first staged in interface and packet structures. This package performs the postprocessing that converts staged results into their permanent form: it creates and manipulates Subledger Accounting (SLA) packets, invokes General Ledger accounting calls, updates encumbrance balances and document status, writes action history, drives reapproval workflows, and produces online exception and detail reports. It is a foundational component of the encumbrance accounting flow in Oracle EBS 12.1.1 and 12.2.2, and it is referenced by three other packages, indicating that other purchasing programs depend on its public routines.

Key Procedures and Functions

• INSERT_PACKET — Creates the accounting packet record used to carry encumbrance and budgetary entry data forward for the transaction.
• EXECUTE_GL_CALL — Invokes the General Ledger accounting call to post the prepared packet into the SLA/GL accounting stream.
• COPY_DETAILED_GL_RESULTS — Copies detailed GL results produced by the accounting call into the packet history and related structures.
• UPDATE_DOCUMENT_ENCUMBRANCE — Updates the encumbrance position of the underlying purchasing document to reflect the posted accounting.
• CREATE_ENC_ACTION_HISTORY — Writes an action history record documenting the encumbrance-related action taken on the document.
• SET_STATUS_REQUIRES_REAPPROVAL — Sets the document status to indicate that reapproval is required following the accounting or encumbrance action.
• CREATE_DETAILED_REPORT — Produces the detailed online report of the postprocessing results.
• CREATE_EXCEPTION_REPORT — Produces the exception report identifying documents or packets that failed postprocessing.
• DELETE_PACKET_AUTONOMOUS — Removes a packet using an autonomous transaction so cleanup does not affect the caller's unit of work.
• POPULATE_BC_REPORT_ID — Populates the Budgetary Control report identifier associated with the packet.
• DELETE_UNNECESSARY_EVENTS — Purges redundant or unnecessary event records generated during processing.
• GET_SIGN_FOR_AMOUNT — Returns the accounting sign (debit/credit orientation) applicable to a given amount.
• GET_EVENT_TYPE_CODE — Returns the event type code that classifies the accounting event being processed.

Tables Accessed

The package reads and writes across several functional areas. Encumbrance and budgetary control data is handled through PO_ENCUMBRANCE_GT, PO_BC_DISTRIBUTIONS, PO_BC_DISTRIBUTIONS_S, and GL_BC_PACKETS with its history and sequence counterparts (GL_BC_PACKETS_HISTS, GL_BC_PACKETS_S). Purchasing document data comes from PO_HEADERS_ALL, PO_LINE_LOCATIONS_ALL, PO_DISTRIBUTIONS_ALL, PO_DOCUMENT_TYPES, PO_RELEASES_ALL, and the requisition tables PO_REQUISITION_HEADERS_ALL, PO_REQUISITION_LINES_ALL, and PO_REQ_DISTRIBUTIONS_ALL. Audit and workflow data is stored in PO_ACTION_HISTORY and PO_ACTION_HISTORY_SV. Organizational context is resolved via HR_OPERATING_UNITS and HR_ALL_ORGANIZATION_UNITS_TL. Lookups and messages use GL_LOOKUPS, FND_NEW_MESSAGES, and FND_MESSAGE, while reporting uses PO_ONLINE_REPORT_TEXT and PO_ONLINE_REPORT_TEXT_S. Multi-organization accounting references include PO_MOAC_UTILS_PVT and PO_DOCUMENT_FUNDS_PVT, and SLA/XLA integration uses PSA_BC_XLA_EVENTS_GT, PSA_BC_XLA_PUB, XLA_DISTRIBUTION_LINKS, and XLA_EVENTS_PUB_PKG.

Usage Notes

PO_ENCUMBRANCE_POSTPROCESSING is not an end-user facing API. It is invoked internally by the purchasing encumbrance and budgetary control programs that follow document approval, generation, and change activity. It is typically reached from concurrent programs, from document action workflows, and from other packages that call its routines after the core transaction completes. Because it touches Subledger Accounting packets, GL calls, and encumbrance updates, it should be treated as a postprocessing utility rather than a transactional entry point. Custom code should not call its internal procedures directly; instead, use the documented public purchasing APIs and allow the standard postprocessing flow to execute. Parameters and return values must be taken from the live package specification, as the metadata documents procedure purpose only.