Search Results cum_start_date




Overview
Explore in AI Chat

Overview

APPS.RLM_SCHEDULE_LINE_CUM_V is a reporting and integration view in Oracle E-Business Suite Release 12.1.1 and 12.2.2 that exposes cumulative (CUM) schedule line information maintained by Oracle's Enterprise Territory and Channel Revenue Management / supplier scheduling data model (RLM schema). The view consolidates cumulative quantities, cumulative start dates, and the associated customer/item cumulative key context into a single denormalized result set, which is why it is frequently targeted by custom reports, extracts, and outbound interfaces that need to reconcile scheduled releases against cumulative balances.

The view preserves the ORG_ID (operating unit) column, making it multi-org aware, and it derives the cumulative window by matching a CUM-type schedule line (item_detail_type = '4' with item_detail_subtype = 'CUM') against a corresponding detail line (item_detail_type = '3') on the same header and schedule item number. The view also filters to the maximum cumulative quantity found for the matching item and CUM key, effectively returning the active/highest cumulative position rather than intermediate snapshots.

Underlying Base Objects

The view is defined over four aliased instances of three documented base objects, all exposed in the APPS schema as synonyms:

  • RLM_SCHEDULE_LINES_ALL — used three times (aliases a, d and, within the correlated subquery, a1 and d1). Alias a supplies the detail line attributed quantities; alias d supplies the CUM line whose start date equals the cumulative key start date.
  • RLM_CUST_ITEM_CUM_KEYS — alias b (and b1 in the subquery). Holds the cumulative key definition, including CUM_KEY_ID, cum_start_date and the fallback dimensions matched against the scheduled lines.
  • RLM_SCHEDULE_HEADERS_ALL — alias c (and c1). Supplies the header context and the sched_generation_date used to validate that the schedule generation is on or after the CUM start date.

Joins are enforced on ORG_ID across all four line/header instances and on customer_item_id, ship_from_org_id, ship_to_address_id, bill_to_address_id, intrmd_ship_to_id, cust_po_number, and industry_attribute1. NVL-based joins allow a CUM key with a null dimension to match any scheduled line value.

Key Columns

Although not projected, CUST_PO_NUMBER from RLM_SCHEDULE_LINES_ALL participates directly in the join predicate: nvl(a.cust_po_number,0) = nvl(b.purchase_order_number, nvl(a.cust_po_number,0)). Users searching on "cust_po_number" will therefore find this view governs CUM matching by customer PO, even though the column itself is not exposed in the SELECT list.

Common Use Cases and Queries

Typical uses include reconciling cumulative quantities per customer PO before processing a release, feeding external planning systems, and diagnosing mismatches where a CUM key does not tie to a detail line.

Sample query returning cumulative positions for a customer item:

SELECT cum_key_id, cum_start_date, schedule_reference_num,
       item_detail_quantity, uom_code, org_id
  FROM apps.rlm_schedule_line_cum_v
 WHERE customer_item_id = :p_customer_item_id
   AND org_id = :p_org_id;

To trace lines by customer PO indirectly, join back to RLM_SCHEDULE_LINES_ALL on CUM_KEY_ID-related keys, since cust_po_number is not projected by the view. Because the view applies a MAX-quantity correlated subquery, it returns a single dominant cumulative record per item/CUM key combination, making it well suited to dashboards and interface extracts that require one authoritative cumulative balance rather than the full history.