Search Results insert_packet

Overview

PO_ENCUMBRANCE_POSTPROCESSING is an internal PL/SQL package owned by the APPS schema that performs the post-processing phase of purchase order encumbrance accounting in Oracle E-Business Suite Release 12.1.1 and 12.2.2. Encumbrance accounting allows an organization to reserve, or encumber, funds at the time a purchasing document is created or approved, and to relieve that encumbrance when the corresponding invoice, receipt, or payment is processed. The package operates as the downstream half of a two-stage design: PO_ENCUMBRANCE_PREPROCESSING collects and prepares encumbrance data, while PO_ENCUMBRANCE_POSTPROCESSING validates the resulting accounting distributions, submits them to the Subledger Accounting and General Ledger interface, interprets the returned results, and records the outcome on the source purchasing document.

The package is classified as OTHER in the ETRM repository, indicating that it is not a published public API but a supporting program invoked internally by the purchasing encumbrance flow. Its documented status in the APPS schema is VALID.

Key Procedures and Functions

Thirteen procedures and functions are documented for this package. INSERT_PACKET and DELETE_PACKET_AUTONOMOUS manage the population and removal of accounting packet records, the latter running in an autonomous transaction so that cleanup work commits independently of the caller. EXECUTE_GL_CALL invokes the General Ledger accounting interface for the prepared packet. COPY_DETAILED_GL_RESULTS and POPULATE_BC_REPORT_ID retrieve and associate the detailed results returned by that interface. UPDATE_DOCUMENT_ENCUMBRANCE writes the encumbrance outcome back to the purchasing document, and SET_STATUS_REQUIRES_REAPPROVAL flags documents whose accounting failed and therefore require reapproval.

CREATE_ENC_ACTION_HISTORY records an entry in the purchasing action history trail. CREATE_DETAILED_REPORT and CREATE_EXCEPTION_REPORT produce the diagnostic output used administrators review when encumbrance processing succeeds in part or fails outright. DELETE_UNNECESSARY_EVENTS prunes redundant event rows generated during processing. Finally, GET_SIGN_FOR_AMOUNT and GET_EVENT_TYPE_CODE are utility functions that determine the accounting sign and the event type classification applied to encumbrance entries.

Tables Accessed

The package reads and writes a documented set of tables through APPS synonyms. Core purchasing tables include PO_HEADERS_ALL, PO_LINE_LOCATIONS_ALL, and PO_DISTRIBUTIONS_ALL, which supply the document structure and distribution detail being encumbered. PO_DOCUMENT_TYPES and PO_DOC_STYLE_HEADERS identify the document type and style governing the accounting rules applied. PO_DRAFTS, PO_ACTION_HISTORY, and PO_ENCUMBRANCE_GT support draft handling, the action history trail, and the intermediate encumbrance staging area respectively.

Budget and encumbrance accounting data is carried in PO_BC_DISTRIBUTIONS and PO_BC_DISTRIBUTIONS_S. Interaction with General Ledger occurs through GL_BC_PACKETS, GL_BC_PACKETS_HISTS, and GL_BC_PACKETS_S, which hold the accounting packets, their history, and their sequence values. HR_ALL_ORGANIZATION_UNITS_TL supplies organization names for reporting, and FND_NEW_MESSAGES holds user-facing messages and warnings. A dependency on PO_TBL_NUMBER is also documented.

Usage Notes

PO_ENCUMBRANCE_POSTPROCESSING is an internal component rather than a callable public API. It is referenced by PO_DOCUMENT_FUNDS_PVT, PO_ENCUMBRANCE_PREPROCESSING, and recursively by itself, indicating that it is driven from within the purchasing funds and encumbrance processing flow. Practically, it executes when a purchasing document is submitted, approved, or otherwise triggers encumbrance accounting, and it runs the post-processing logic after distributions have been prepared and submitted to the General Ledger interface. Administrators review its detailed and exception reports when encumbrances are not created or relieved as expected, and a document status of requires reapproval signals that correction and resubmission are necessary. Because it is internal and unsupported for direct invocation, customizations should not call it directly; standard Oracle APIs in the purchasing and funds control layer should be used instead.