Search Results deliverable_hold_control




Overview

APPS.PO_INVOICE_HOLD_CHECK is a server-side PL/SQL package body that supports Oracle Purchasing and Oracle Payables integration by evaluating supplier invoice holds against the terms encoded on a standard purchase order. Its central responsibility is to determine whether an invoice line for a given purchase order should be subjected to a "pay when paid" hold. Pay when paid is a contractual arrangement in which the buyer is obligated to remit payment only after the buyer has itself been paid by its own customer; in Oracle EBS this condition is captured on the purchase order header and enforced at invoice validation time.

The package is documented in the ETRM metadata under owner APPS with an API classification of OTHER, and it is part of the broader batch of purchasing packages that begin with the PO_ prefix and use the FND_API conventions for return status, message count, and message data. The header comment block, last modified at version 120.0.12010000.4 in January 2009, confirms it is a standard seeded EBS object rather than a third-party customization, and that it remained essentially stable across the 12.1.1 to 12.2.2 release path.

Key Procedures and Functions

  • PAY_WHEN_PAID — The primary public procedure and the object most closely associated with the search term. It accepts API version, purchase order header identifier, and invoice identifier as inputs, and returns via out parameters a status, message count, message data, and an in-out flag indicating whether pay-when-paid applies. The documented behavior is that it returns 'Y' when the pay-when-paid attribute on the purchase order is set to Yes, and 'N' otherwise. Crucially, if the purchase order document type is anything other than Standard, the procedure short-circuits and returns 'N' without applying a hold, since the pay-when-paid term is only meaningful for standard purchase orders.
  • DELIVERABLE_OVERDUE_CHECK — Evaluates whether a deliverable associated with the purchasing document has passed its due date, supplying the temporal condition used by downstream hold logic.
  • DELIVERABLE_HOLD_CONTROL — Applies the hold decision once the overdue condition has been established, governing whether the invoice is prevented from progressing to payment.

Tables Accessed

  • PO_HEADERS_ALL — The base purchase order header table, read to obtain the document type and the pay-when-paid indicator for the supplied p_po_header_id.
  • PO_HEADERS_DRAFT_ALL — The draft version of the header table, consulted so that in-progress or unapproved changes to the order terms are reflected in the hold decision.
  • PO_DOC_STYLE_HEADERS — Supplies document style and type configuration, supporting the determination of whether the order qualifies as a Standard purchase order.

Usage Notes

PO_INVOICE_HOLD_CHECK is not an end-user-run program. It is invoked programmatically, most commonly during invoice validation in Oracle Payables and from the Purchasing invoice hold and release workflows. Because the documented procedures return FND_API standard status values, callers are expected to check x_return_status for G_RET_STS_SUCCESS, G_RET_STS_ERROR, or G_RET_STS_UNEXP_ERROR and to inspect the message stack when an error is signalled. The metadata records a single dependent package that references this one, indicating a narrow and well-bounded call surface. Extensions and custom validation routines that must respect pay-when-paid terms should call PAY_WHEN_PAID using API version 1.0 and pass the purchase order header identifier together with the invoice identifier. Developers should treat the package as seeded code and avoid direct modification, wrapping any additional logic in a custom package instead. In both 12.1.1 and 12.2.2 the object retains the same owner, name, and procedure set, so any diagnostics or documentation prepared for one release carry forward to the other.