Search Results rlm_validatedemand_sv




Overview
Explore in AI Chat

Overview

RLM_CUM_SV is a public PL/SQL package in the APPS schema that belongs to the Oracle E-Business Suite Return Material Authorization (RMA) and Logistics Management (RLM) product family. Its principal business responsibility is the management of customer cumulative quantities — the total quantities of a given item that a specific customer, ship-to location, or customer item reference has ordered over a defined period. Cumulative tracking is fundamental to high-technology and contract-manufacturing supply chains, where pricing, rebates, and contractual commitments are frequently tied to cumulative volume thresholds. The package validates, stores, and retrieves cumulative keys and cumulative adjustments so that downstream pricing, order validation, and reporting processes operate against a single, consistent view of cumulative demand. It is classified generically as an OTHER API rather than as a formal PL/SQL or business API, indicating that it is intended chiefly as an internal service layer consumed by other RLM components rather than as a supported external integration point.

Key Procedures and Functions

The documented interface exposes twenty-four procedures and functions. The core of the package centres on cumulative key maintenance and retrieval. RESETCUMCLIENT reinitialises client-level cumulative tracking, typically when a contract period, program year, or customer agreement rolls over. GETINVENTORYITEMID resolves the inventory item identifier corresponding to a customer item reference, bridging external customer part numbers to internal inventory definitions. GETLATESTCUM returns the most current cumulative quantity for a customer, ship-to, or customer item combination, and is the principal read operation used by validation logic. UPDATEOLDKEY manages the transition of previously stored cumulative keys when the underlying customer, site, or item definition changes, preserving historical continuity. GETSHIPPLINES identifies the order and shipment lines that contribute to a cumulative quantity, supporting recalculation and audit of cumulative balances. The remaining documented routines provide supporting services such as key construction, adjustment processing, and attribute resolution (NAME). Parameter signatures are not published in the metadata and should be confirmed against the package specification in the target instance before use.

Tables Accessed

The package reads and writes a focused set of operational and configuration tables through APPS synonyms. Order data is sourced from OE_ORDER_HEADERS_ALL, OE_ORDER_LINES, and OE_ORDER_LINES_ALL. Customer and location context comes from HZ_CUST_ACCOUNTS, HZ_CUST_ACCT_SITES, and HZ_CUST_SITE_USES. Customer item cross-references are resolved through MTL_CUSTOMER_ITEM_XREFS. Cumulative state is persisted in RLM_CUST_ITEM_CUM_KEYS, its _ALL and _S variants, and RLM_CUST_ITEM_CUM_ADJ, while RLM_CUST_SHIPTO_TERMS, RLM_SCHEDULE_HEADERS, and the ECE_TP_GROUP and ECE_TP_HEADERS tables supply trading-partner and scheduling context. These accesses support both the calculation of cumulative totals and the storage of the keys that uniquely identify each cumulative bucket.

Usage Notes

RLM_CUM_SV is not normally invoked directly by end users. It is consumed by higher-level RLM service packages, notably RLM_MANAGE_DEMAND_SV, RLM_RD_SV, RLM_TPA_SV, RLM_CUM_SV itself, RLM_RLMNETCH_XMLP_PKG (a concurrent program backing report), and the object referenced in the user's search — RLM_VALIDATEDEMAND_SV — as well as WSH_DOCUMENT_PVT. The dependency on RLM_VALIDATEDEMAND_SV demonstrates that demand validation calls this package to confirm cumulative eligibility before an order line is accepted. Because the package exposes an OTHER-classified API, extensions should invoke it through the documented wrapper packages rather than calling it directly. Always verify the package specification in the specific instance, as signature changes between 12.1.1 and 12.2.2 patches are possible.