Search Results rlm_cust_item_cum_keys




Overview
Explore in AI Chat

Overview

RLM_CUST_ITEM_CUM_ADJ_ALL is a transactional table in the Oracle E-Business Suite Release Management (RLM) module. It stores adjustments to the cumulative (CUM) quantities maintained for RLM customer destination items. CUM quantities represent the running total of shipped quantities that drive repetitive manufacturing and scheduling logic in an RLM-managed supply chain. This table captures manual CUM adjustments entered through a Release Management form, preserving a distinct audit trail separate from system-generated cumulative movements.

The table is owned by the RLM schema and is documented as VALID under both Oracle EBS 12.1.1 and 12.2.2. It holds 48 columns in the documented physical schema. The metadata identifies a child relationship to RLM_CUST_ITEM_CUM_KEYS_ALL via the CUM_KEY_ID foreign key, meaning each adjustment is anchored to a specific customer item CUM key record. The heuristic Data Vault classification mined from the FK structure is "standalone," meaning the table sits as a self-contained adjustment ledger rather than functioning as a pure hub, link, or satellite. In modeling terms, it is best understood as a transactional event table (or an effectivity/transaction satellite) attached to the customer item CUM key hub, where CUM_KEY_ID acts as the business anchor and CUM_ADJ_ID acts as the surrogate identifier for each adjustment event.

Key Information Stored

The table's most significant columns fall into identifier, adjustment payload, contextual, and audit categories.

Common Use Cases and Queries

Typical use cases center on CUM reconciliation, audit reporting, and discrepancy investigation between system-calculated and manually-adjusted cumulative quantities.

  • Listing all manual adjustments for a given customer item CUM key within a date range.
  • Summing adjustments per CUM key to reconcile the net manual impact on cumulative quantity.
  • Auditing who performed adjustments and under what reason for compliance.
  • Reporting by operating unit for multi-org visibility.

Sample query:

SELECT a.cum_adj_id, a.cum_key_id, a.transaction_qty, a.transaction_date_time, a.adjustment_reason, a.org_id FROM rlm.rlm_cust_item_cum_adj_all a WHERE a.cum_key_id = :cum_key_id AND a.transaction_date_time BETWEEN :start_dt AND :end_dt ORDER BY a.transaction_date_time;

A reconciliation aggregate:

SELECT cum_key_id, SUM(transaction_qty) net_adjustment FROM rlm.rlm_cust_item_cum_adj_all GROUP BY cum_key_id;

Related Objects

  • RLM_CUST_ITEM_CUM_KEYS_ALL — Parent table; joined on RLM_CUST_ITEM_CUM_ADJ_ALL.CUM_KEY_ID = RLM_CUST_ITEM_CUM_KEYS_ALL.CUM_KEY_ID. This is the documented FK relationship.
  • RLM_CUST_ITEM_CUM_KEYS — Referenced as the child-relationship parent in the metadata description; the CUM key definition driving adjustments.
  • RLM customer item / destination item tables — Provide item and destination context linked through the CUM key.
  • Release Management adjustment form — The UI entry point that creates records in this table.
  • Concurrent program request metadata — Via REQUEST_ID and PROGRAM_ID for process lineage.
  • RLM CUM transaction tables — System-generated CUM movements compared against these manual adjustments during reconciliation.