Search Results adjustment_reference




Overview
Explore in AI Chat

Overview

APPS.RLM_CUST_ITEM_CUM_ADJ_V is a database view owned by the APPS schema within Oracle E-Business Suite Release 12.1.1 and 12.2.2. It is registered under the Oracle Application Object Library design data repository as RLM.RLM_CUST_ITEM_CUM_ADJ_V and is classified as a supplementary view, a construct Oracle uses primarily to simplify forms coding by presenting a flattened, denormalised projection of one or more base tables. The view is delivered in VALID status and carries the standard Oracle warning that customers should not query or alter data through it directly, because its definition may change materially in subsequent minor or major releases. In the ETRM (Enterprise Territory and Resource Management) module, the view exposes cumulative customer item adjustment records, allowing forms, concurrent programs, and reporting layers to present adjustment transactions alongside unit-of-measure and audit context without navigating the full underlying schema. Because the column ADJUSTMENT_REFERENCE (VARCHAR2(240)) is exposed, users searching for adjustment references typically arrive at this object when tracing how a specific adjustment transaction was recorded against a cumulative customer item key.

Underlying Base Objects

The documented dependency metadata shows that RLM_CUST_ITEM_CUM_ADJ_V is defined over two referenced base objects, both accessed via synonyms: RLM_CUST_ITEM_CUM_ADJ_ALL and RLM_CUST_ITEM_CUM_KEYS. The first holds the adjustment transaction records themselves, including transaction quantity, date and time, adjustment reference, adjustment reason, and the customer unit of measure. The second holds the cumulative key definitions that identify the customer-item combination to which each adjustment pertains. The join between the two is established through the CUM_KEY_ID column, which appears in the view and links each adjustment row to its parent cumulative key. From a data model perspective, the view is a read-only projection; DML against it is not supported and the ALL-suffixed base table name indicates it is the multi-organisation variant, with ORG_ID carried through the view for operating unit filtering.

Key Columns

The view exposes a compact functional column set alongside the mandatory WHO and program audit columns. CUM_ADJ_ID is the primary identifier of the adjustment record, while CUM_KEY_ID is the foreign key back to the cumulative key table. TRANSACTION_DATE_TIME and TRANSACTION_QTY capture when the adjustment occurred and the quantity affected. ADJUSTMENT_REFERENCE holds a free-text reference of up to 240 characters used to cite the source document or reason code, and ADJUSTMENT_REASON holds a shorter 30-character reason classification. CUST_UOM_CODE identifies the customer unit of measure in which the transaction quantity is expressed. The fifteen ATTRIBUTE columns and ATTRIBUTE_CATEGORY provide the standard Oracle flexfield extension, and ORG_ID carries the operating unit identifier for multi-org security. Standard audit columns include LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN, and the request/program tracking columns REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, and PROGRAM_UPDATE_DATE.

Common Use Cases and Queries

Typical usage includes reconciling cumulative customer item adjustments, tracing a specific adjustment reference supplied by a user or interface, and reporting adjustment activity by operating unit or date range. A representative query filtered on the adjustment reference is shown below.

  • Reference lookup: SELECT cum_adj_id, cum_key_id, transaction_date_time, transaction_qty, adjustment_reference FROM apps.rlm_cust_item_cum_adj_v WHERE adjustment_reference = :p_ref;
  • Adjustments within a date window and operating unit: SELECT cum_adj_id, transaction_qty, cust_uom_code, adjustment_reason FROM apps.rlm_cust_item_cum_adj_v WHERE org_id = :p_org AND transaction_date_time BETWEEN :p_from AND :p_to;
  • Adjustments for a given cumulative key: SELECT cum_adj_id, adjustment_reference, adjustment_reason FROM apps.rlm_cust_item_cum_adj_v WHERE cum_key_id = :p_key;
  • Audit of program-populated rows: SELECT cum_adj_id, request_id, program_id, program_update_date FROM apps.rlm_cust_item_cum_adj_v WHERE program_update_date IS NOT NULL;

Because the view is supplementary and unsupported for direct data manipulation, any reporting or integration logic should treat the columns as read-only and be prepared for structural change across patches and upgrades.