Search Results create_retainage_distributions

Overview

AP_RETAINAGE_PKG is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite. It encapsulates the business logic Oracle Payables uses to manage retainage on supplier invoices and their associated distributions. Retainage is the practice of withholding a portion of an invoice amount until contracted work, goods, or services have been completed and accepted. In Oracle Payables, retainage is tracked and released through invoice distributions, and AP_RETAINAGE_PKG provides the programmatic mechanism that creates the distribution rows required to record, adjust, or release retainage amounts against an invoice. The package is classified as OTHER in the ETRM documentation, meaning it is a supporting internal package rather than a published public API. Its status is VALID, confirming it is an active, compiled object in the EBS instance.

The package operates in both Oracle EBS 12.1.1 and 12.2.2. Because the object name and dependency paths are consistent across these releases, the functional behavior described here applies to both, with the usual caveat that 12.2.x environments use the same APPS schema and AP data model.

Key Procedures and Functions

The ETRM documentation lists a single documented program unit: CREATE_RETAINAGE_DISTRIBUTIONS.

• CREATE_RETAINAGE_DISTRIBUTIONS — Generates the retainage-related distribution records for an invoice. Its purpose is to build the AP_INVOICE_DISTRIBUTIONS rows that reflect withheld retainage amounts, aligning them with the invoice header, lines, and payment schedules. The documented metadata does not expose the formal parameter list, so parameter specifics should be confirmed against the deployed package specification (or the AP_RETAINAGE_PKG package source) in the target instance before invoking it. No other procedures or functions are documented in the ETRM extract; additional internal helpers may exist in the package body but are not part of the documented surface.

Tables Accessed

The package reads and writes Payables invoice and distribution data through APPS synonyms. The documented tables include:

• AP_INVOICES / AP_INVOICES_ALL — Invoice header data, used to identify the invoice being processed and to validate its attributes.
• AP_INVOICE_LINES / AP_INVOICE_LINES_ALL — Invoice line detail, including retainage-bearing lines that drive distribution creation.
• AP_INVOICE_DISTRIBUTIONS / AP_INVOICE_DISTRIBUTIONS_ALL / AP_INVOICE_DISTRIBUTIONS_S — The distribution records themselves, which are the primary output written by CREATE_RETAINAGE_DISTRIBUTIONS.
• AP_PAYMENT_SCHEDULES_ALL — Payment schedule and due-date information used to keep retainage distributions consistent with scheduled payments.
• AP_SYSTEM_PARAMETERS / FINANCIALS_SYSTEM_PARAMETERS — Payables and financials options that govern retainage accounting and rounding behavior.
• FND_CURRENCIES / FND_PRODUCT_INSTALLATIONS — Currency precision and installation-level context.
• PLITBLM — The standard EBS PL/SQL table used internally by the package for in-memory processing.

Usage Notes

AP_RETAINAGE_PKG is invoked internally by Oracle Payables rather than being called directly by end users. The documentation shows it is referenced by four other packages: AP_MATCHING_PKG, AP_PO_AMT_MATCH_PKG, AP_RCT_AMT_MATCH_PKG, and AP_RECT_MATCH_PKG. These are the invoice matching and receipt matching engines, which call AP_RETAINAGE_PKG when retainage must be recognized or adjusted during matching against purchase orders and receipts. This confirms the package participates in standard invoice validation and matching workflows.

Custom code should normally avoid calling CREATE_RETAINAGE_DISTRIBUTIONS directly, because the supported entry points for invoice creation and matching are the documented Payables APIs and matching packages. Where extension is required, customizations should follow Oracle's recommended approach of extending or wrapping the calling packages rather than depending on the internal signature of AP_RETAINAGE_PKG. Because only one program unit is documented and parameters are not exposed in the ETRM metadata, developers should always inspect the package specification in their specific EBS instance (12.1.1 or 12.2.2) before any integration effort, and should validate all behavior in a non-production environment.