Search Results copydoc_shipment_failure

Overview

APPS.PO_COPYDOC_S4 is a PL/SQL package body belonging to the Oracle E-Business Suite Purchasing (PO) module family. Its role is to support the document copy and validation logic used when creating or duplicating purchasing documents, specifically validating shipment-level (line location) information before that data is written into the destination document. The module header indicates a shared procedure origin ("Shared Proc FPJ") and carries the file revision identifier POXCPO4B.pls, with the last source control update dated January 2011, consistent with the 12.1.1 and 12.2.2 release lines.

Within Oracle Purchasing, a document copy operation must carry forward pricing, sourcing, receiving, inspection, and matching attributes from an originating document to a target document. The package encapsulates a substantial portion of that shipment-level validation work, ensuring that each copied line location row is internally consistent and compliant with system parameters before being inserted. The copy routine is also designed to operate alongside debug logging booleans drawn from PO_DEBUG, allowing developers to trace statement-level and unexpected-error conditions during troubleshooting.

Key Procedures and Functions

The package exposes a single documented public procedure: validate_shipment. It is the central entry point for validating an individual shipment (line location) as part of a copy document transaction. Its stated purpose is to evaluate the shipment attributes against the requested action code and target document subtype, and then return a populated line location record together with a sequence value and a return code indicating success or failure.

From the declared local structures, the procedure clearly performs a range of checks and derivations rather than a single comparison. It maintains local variables for the quotation class code, originating header and line identifiers, vendor and vendor site identifiers, invoice match option, unit price, payment terms, ship-via, FOB, freight terms, quantity tolerance and exception code, receiving flag, inspection flag, secondary quantity, and item number. These locals indicate the procedure reconciles sourcing and receiving attributes sourced from the originating document against the destination document's requirements. A dedicated COPYDOC_SHIPMENT_FAILURE exception is defined to signal a validation rejection back to the calling copy routine, and both an internal return code and a progress marker are tracked to support error reporting. The two NOCOPY output parameters for the shipment record and sequence are updated in place to avoid unnecessary copying overhead.

Tables Accessed

• PO_LINE_LOCATIONS, PO_LINE_LOCATIONS_ALL, PO_LINE_LOCATIONS_S — the primary shipment tables read to resolve the originating line location and used as the source for the destination row structure.
• PO_HEADERS, PO_LINES — read to obtain header-level and line-level attributes such as vendor, terms, pricing basis, and document type.
• PO_SYSTEM_PARAMETERS, FINANCIALS_SYSTEM_PARAMETERS, RCV_PARAMETERS — read to apply receiving, inspection, and matching defaults that govern shipment validity.
• MTL_SYSTEM_ITEMS, IC_ITEM_MST, IC_ITEM_CPG — read to resolve item attributes, item number, and any item-organization or commodity-related constraints on the shipment.

Usage Notes

PO_COPYDOC_S4 is not an interface called directly by end users. It is invoked internally by the Purchasing copy document framework, generally triggered from the Copy Document or AutoCreate flows and from concurrent processing that duplicates requisitions or purchase orders into new buyer-owned documents. Because the procedure operates on non-public table structures and expects a fully populated set of context parameters, custom code should not call it directly; integrators instead invoke the supported public copy APIs, which in turn delegate to packages such as PO_COPYDOC_S4. The package is referenced by one other package in the documented dependency set, confirming its role as a subordinate worker rather than a top-level API. Its results are driven by the same system parameter configuration visible in the Purchasing setup screens, so validation behaviour varies with the operating unit's receiving and matching options.