Search Results po_update_wo_mod_pkg

Overview

APPS.PO_UPDATE_WO_MOD_PKG is a specialized Oracle E-Business Suite purchasing package that supports the "Work Order Modification" (WO_MOD) workflow associated with umbrella programs and contract-related (COTR) header attributes. Its principal business responsibility is to synchronize the denormalized columns on the PO_HEADERS_ALL record with the corresponding descriptive flexfield values stored in the DFF extension table PO_HEADERS_ALL_EXT_B, and to stamp the applicable umbrella program identifier onto the purchasing document. In the Oracle EBS 12.1.1 and 12.2.2 code lines, this behavior is significant because the header columns CLM_COTR_OFFICE, CLM_COTR_CONTACT, and UMBRELLA_PROGRAM_ID are derived from external attribute segments rather than entered directly by the user.

The package ships as a "plb" wrapped body (header reference PO_UPDATE_WO_MOD_PKG.plb 120.1.12020000.2) and is classified under the ETRM API classification OTHER. Following Oracle's standard API conventions, it publishes a single public procedure and relies on PO_LOG for instrumentation, FND_API for return-status semantics, and NOCOPY OUT parameters for performance. Only one procedure is documented, and no other packages are recorded as referencing it, indicating it is invoked from a narrow integration point rather than shared broadly across the application.

Key Procedures and Functions

• SAVE_UPDATE_WO_MOD — The sole documented procedure. It accepts a purchase order header identifier, an attribute group identifier, and an umbrella program name, and returns a standard FND_API return status. Its purpose is to persist the Work Order Modification updates: it writes the COTR office and COTR contact values (sourced from the N_EXT_ATTR1 and N_EXT_ATTR3 numeric DFF segments where C_EXT_ATTR1 equals 'COTR_OFFICE') into the corresponding PO_HEADERS_ALL columns, resolves the umbrella program identifier from the program name, and then invalidates any in-flight modification draft by setting the draft revision number to -1. On unexpected failure it sets the return status to FND_API.G_RET_STS_UNEXP_ERROR, logs the SQL error through PO_LOG, and re-raises the exception.

Tables Accessed

• PO_HEADERS_ALL — The primary target of the update. The procedure sets CLM_COTR_OFFICE, CLM_COTR_CONTACT, and UMBRELLA_PROGRAM_ID on the row identified by PO_HEADER_ID.
• PO_HEADERS_ALL_EXT_B — The DFF extension table and source of the COTR values. The correlated subqueries filter on ATTR_GROUP_ID, the segment C_EXT_ATTR1 = 'COTR_OFFICE', and DRAFT_ID = -1 to obtain the committed (non-draft) attribute values.
• PON_UMBRELLA_PROGRAMS — A lookup source that maps UMBRELLA_PROGRAM_NAME to the internal UMBRELLA_PROGRAM_ID written back to the header.
• PO_DRAFTS — Updated so that any active modification draft (statuses DRAFT, IN PROCESS, REJECTED, PRE-APPROVED, SUPPLIER SIGN; draft_type MOD) has revision_num set to -1, effectively clearing or invalidating the pending revision.

Usage Notes

The package is designed to be called during the Work Order Modification flow for contract-type purchasing documents that carry COTR and umbrella program attributes. It is not a general-purpose public API and should be invoked only after the DFF attributes have been staged in PO_HEADERS_ALL_EXT_B with DRAFT_ID = -1, since both of the extracted COTR values depend on that filter. Callers must supply a valid attribute group identifier, a valid umbrella program name, and must inspect X_RETURN_STATUS for FND_API.G_RET_STS_SUCCESS before proceeding.

Because the procedure performs direct DML rather than calling the standard PO update APIs, it bypasses certain validations and does not trigger the full purchasing document update logic. Customizations, forms personalizations, or concurrent programs that operate on COTR/umbrella purchasing documents should treat this package as an internal component and avoid modifying its behavior; the referenced "cotr_office" search term corresponds precisely to the C_EXT_ATTR1 segment value this package queries. No other packages are documented as referencing it, so impact analysis should focus on form-level or workflow-level invocations.