Search Results massupdate_releases

Overview

APPS.PO_RETROACTIVE_PRICING_PVT is a private server-side PL/SQL package in Oracle Purchasing (Oracle E-Business Suite 12.1.1 and 12.2.2). Its business purpose is to propagate price changes that were made retroactively on a Blanket Agreement (BA) or Global Agreement (GA) down to the dependent documents. When a buyer revises the price on a blanket or global agreement and that revision is retroactive, every release written against the agreement — or, for global agreements, every standard purchase order referencing it — must be repriced so that the documents remain consistent with the parent agreement. The package encapsulates that mass repricing logic. The header comment ($Header: POXRPRIS.pls 120.3) confirms the package is marked "noship," indicating it is an internal implementation package rather than a public API. The API classification recorded in ETRM is PVT (private), and the package is referenced by six other packages in the Purchasing module, reflecting its role as a shared internal service.

Key Procedures and Functions

The ETRM metadata documents 14 procedures and functions; the following are identified by name. MASSUPDATE_RELEASES is the principal entry point. It updates all releases against blanket agreements, or standard purchase orders against global agreements, whose lines have been retroactively changed, and is invoked either from the Approval window or from a concurrent program. NAME is a standard package-level name/identifier function. IS_RETRO_UPDATE returns whether a document is subject to a retroactive update, and RESET_RETRO_UPDATE clears the retroactive-update indicator once processing is complete. RETRO_INVOICE_RELEASE addresses the interaction between retroactive repricing and invoicing on releases. IS_RETRO_PROJECT_ALLOWED determines whether retroactive pricing is permitted for a project-related context, and IS_ADJUSTMENT_ACCOUNT_VALID validates the adjustment account used to capture the accounting difference created by the repricing. Parameters are not enumerated here, but MASSUPDATE_RELEASES accepts an API version and validation level, a supplier site and agreement header identifier, a purchasing category structure with from/to ranges, an item number range, an effective date, and a flag controlling whether price updates are communicated to the supplier.

Tables Accessed

The package reads and writes through APPS synonyms. Purchasing distribution data is the primary target: PO_DISTRIBUTIONS, PO_DISTRIBUTIONS_ALL, PO_DISTRIBUTIONS_ARCHIVE, and PO_DISTRIBUTIONS_ARCHIVE_ALL hold the encumbered and accounting distributions that must be adjusted when a release or standard PO is repriced, with the archive tables preserving the pre-update image. PO_DOCUMENT_TYPES, PO_DOCUMENT_TYPES_ALL_B, and PO_DOC_STYLE_HEADERS are consulted to classify documents and resolve their style and type during processing. MTL_UNITS_OF_MEASURE and MTL_TRANSACTION_FLOW_LINES support unit-of-measure conversion and transaction flow for the affected lines. GL_CODE_COMBINATIONS provides the accounting flexfield validation behind IS_ADJUSTMENT_ACCOUNT_VALID. FINANCIALS_SYSTEM_PARAMETERS and FINANCIALS_SYSTEM_PARAMS_ALL supply ledger and financials options, FND_CURRENCIES provides currency attributes, FND_PRODUCT_INSTALLATIONS confirms installed products, and HR_ALL_ORGANIZATION_UNITS resolves the operating unit context.

Usage Notes

PO_RETROACTIVE_PRICING_PVT is not intended for direct external calls. In standard EBS flows it is reached when a user approves or applies a retroactive price change on a blanket or global agreement from the Purchasing approval window, or when the corresponding concurrent program is submitted to process the change in bulk. Customizations should not call MASSUPDATE_RELEASES directly unless they replicate the full calling sequence, including setting the API version and validation level and handling the x_return_status output, because the package assumes a Purchasing forms or concurrent-program context. Extensions that need to know whether a document has a pending retroactive update should use IS_RETRO_UPDATE as a read-only check rather than manipulating the underlying distribution tables. Because the package is private and unsupported for direct use, upgrades between 12.1.1 and 12.2.2 may alter its internal signature; any custom code referencing it must be revalidated after patching.