Search Results cust_uom_code

Overview

RLM_CUST_ITEM_CUM_ADJ_V is a PL/SQL view owned by the APPS schema in Oracle E-Business Suite Release Management (RLM). It exposes cumulative adjustment activity associated with customer item cumulative keys, joining the transaction-level adjustment table to the customer item cumulative key definition table. In EBS 12.1.1 and 12.2.2 the object is delivered in VALID status and is available for reporting, integration, and diagnostic queries without requiring a dedicated API. Because the view joins a transaction table to a key/definition table, it provides a denormalized read path that resolves the customer unit of measure code (CUST_UOM_CODE) at the same time as the cumulative adjustment quantities and references. Typical consumers include customer-item cumulative reconciliation reports, discrepancy investigation, and downstream extracts that must present adjustments in the customer's own UOM rather than an internal unit of measure.

Underlying Base Objects

The view text defines two sources joined on CUM_KEY_ID:

• RLM_CUST_ITEM_CUM_ADJ (aliased ADJ) — the alias for cumulative adjustment records. In the documented metadata this object is exposed through the synonym RLM_CUST_ITEM_CUM_ADJ_ALL. It supplies the adjustment header data: quantity, transaction timestamp, reference, reason, WHO columns, and the DFF attribute segments.
• RLM_CUST_ITEM_CUM_KEYS (aliased CKEYS) — supplied through a synonym of the same name. It supplies the cumulative key definition, including CUST_UOM_CODE, and is the join partner that identifies which customer item cumulative the adjustment belongs to.

The join predicate is ADJ.CUM_KEY_ID = CKEYS.CUM_KEY_ID. Because the adjustment table is joined to the key table on a mandatory key column, each row in the view represents one adjustment expressed under its owning cumulative key. Note that the underlying adjustment object is referenced with the _ALL synonym, which in EBS conventionally indicates a multi-org or partitioned table; any operating unit or org security context applied at the base object level is inherited by the view.

Key Columns

• ROW_ID — the ROWID of the adjustment row, useful as a unique row identifier for updates or de-duplication in extracts.
• CUM_ADJ_ID — primary key of the cumulative adjustment record.
• CUM_KEY_ID — foreign key to the cumulative key definition; the join column between the two base objects.
• TRANSACTION_DATE_TIME / TRANSACTION_QTY — the effective timestamp and signed adjustment quantity applied to the customer item cumulative.
• ADJUSTMENT_REFERENCE / ADJUSTMENT_REASON — descriptive audit fields identifying the source document or business reason for the manual adjustment.
• CUST_UOM_CODE — the customer unit of measure in which the cumulative and its adjustment quantity are expressed; this is the column most frequently searched by users investigating cumulative discrepancies.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1–15 — descriptive flexfield context and segments, available for client-specific reporting.
• WHO and concurrency columns (CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN) and REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — standard audit and concurrent program tracking fields.

Common Use Cases and Queries

Principal uses include reconciling customer-item cumulative balances after a manual adjustment, reporting adjustment history by customer UOM, and feeding external systems that track consignment or supplier-managed inventory quantities. A common starting query filters one cumulative key:

SELECT cum_adj_id, transaction_date_time, transaction_qty, cust_uom_code, adjustment_reference, adjustment_reason FROM apps.rlm_cust_item_cum_adj_v WHERE cum_key_id = :p_cum_key_id ORDER BY transaction_date_time;

To summarize adjustment activity by unit of measure over a period:

SELECT cust_uom_code, SUM(transaction_qty) total_adj_qty, COUNT(*) adj_count FROM apps.rlm_cust_item_cum_adj_v WHERE transaction_date_time BETWEEN :p_from AND :p_to GROUP BY cust_uom_code;

Because the view is a simple two-table join with no aggregation, it is safe to filter, sort, and join further to keys or item masters. For org-secured environments, apply the appropriate operating unit or organization predicate, and use the REQUEST_ID column to trace adjustments back to the concurrent program that created them.