Search Results cust_shipto_terms_pk

Overview

The RLM_CUST_SHIPTO_TERMS_ALL table is an Oracle E-Business Suite Release Management (RLM) transactional configuration table that stores customer address attributes which are dependent upon the ship-from/ship-to relationship. Introduced as part of the R-12 architecture, this table consolidates attributes that were previously scattered across legacy structures; the documentation explicitly notes that some Phase 1 attributes were carried forward from VEH_RA_ADDRESSES, a table being eliminated in Phase 2. The table resides in the RLM schema with a documented status of VALID and contains 119 columns in the 12.2.2 physical schema.

Its principal role is to define the operational and planning terms that govern how a specific ship-from organization services a specific customer ship-to address. These terms include cumulative (CUM) management rules, planning and sequencing horizon windows, shipping calendars, demand tolerances, and release processing parameters. Because such terms vary by the combination of customer, address, ship-from organization, and operating unit, the table functions as a high-cardinality configuration repository rather than a transaction log.

From a modeling perspective, the heuristic Data Vault classification mined from the foreign-key structure is standalone. In Data Vault terms, it is best treated as a standalone satellite-like structure anchored to its own surrogate key rather than as a classic hub or link, since no parent relationships were documented in the ETRM metadata. This classification is offered as a modeling suggestion only.

Key Information Stored

The table is anchored by a surrogate primary key, CUST_SHIPTO_TERMS_ID, enforced through the constraint CUST_SHIPTO_TERMS_PK. A separate unique index, RLM_CUST_SHIPTO_TERMS_U1, defines the business-key candidate over the combination of CUSTOMER_ID, ADDRESS_ID, SHIP_FROM_ORG_ID, and ORG_ID. This four-column key establishes the natural identity of a shipto-terms record.

Among the most operationally significant columns:

• CUSTOMER_ID and ADDRESS_ID — identify the customer and the specific ship-to address to which the terms apply.
• SHIP_FROM_ORG_ID and ORG_ID — identify the supplying organization and the operating unit, completing the ship-from/ship-to relationship.
• CUM_CONTROL_CODE, CUM_CURRENT_RECORD_YEAR, CUM_PREVIOUS_RECORD_YEAR, CUM_CURRENT_START_DATE, CUM_PREVIOUS_START_DATE, CUM_ORG_LEVEL_CODE, CUM_SHIPMENT_RULE_CODE, and CUM_YESTERD_TIME_CUTOFF — govern cumulative quantity tracking and reset behavior.
• SHIP_METHOD, INTRANSIT_TIME, TIME_UOM_CODE, SHIP_DELIVERY_RULE_NAME, and INTRANSIT_CALC_BASIS — control shipment routing and in-transit calculations.
• PLN_FIRM_DAY_FROM/TO, PLN_FORECAST_DAY_FROM/TO, PLN_FROZEN_DAY_FROM/TO and the corresponding SHP_ and SEQ_ horizons — define planning, shipping, and sequencing time fences.
• DEMAND_TOLERANCE_ABOVE and DEMAND_TOLERANCE_BELOW — set acceptable demand variation thresholds.
• RELEASE_RULE, RELEASE_TIME_FRAME, and RELEASE_TIME_FRAME_UOM — drive blanket release processing.
• PRICE_LIST_ID, AGREEMENT_ID, FUTURE_AGREEMENT_ID, BLANKET_NUMBER, and SUPPLIER_CONTACT_ID — link commercial context to the relationship.
• INACTIVE_DATE — provides effective-dating control for the terms record.
• Standard WHO columns (CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY) and the DFF segments ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE15, plus TP_ATTRIBUTE_CATEGORY and TP_ATTRIBUTE1–TP_ATTRIBUTE15, support auditing and extensibility.

Common Use Cases and Queries

Typical usage centers on retrieving the governing terms for a given customer/address/ship-from combination, reporting on active versus inactive configurations, and validating that planning horizons and CUM rules are consistently defined across a customer base.

A common retrieval pattern resolves the business key:

• SELECT * FROM rlm.rlm_cust_shipto_terms_all WHERE customer_id = :p_customer AND address_id = :p_address AND ship_from_org_id = :p_org AND org_id = :p_org_id;

Reporting queries frequently filter on INACTIVE_DATE IS NULL to isolate currently effective records, or aggregate counts of configured ship-to terms per operating unit. Planning diagnostics join the horizon columns (PLN_*, SHP_*, SEQ_*) to compare time fences across addresses. Release-processing reports examine RELEASE_RULE and RELEASE_TIME_FRAME to verify blanket agreement behavior. Because the unique index covers the four business-key columns, index-driven access is efficient for these lookup patterns.

Related Objects

While ETRM documentation classifies this table as standalone with no mined foreign-key relationships, functional dependencies exist within the RLM and order-management domains:

• HZ_CUST_ACCOUNTS and HZ_CUST_SITE_USES_ALL — supply the customer and ship-to identifiers referenced by CUSTOMER_ID and ADDRESS_ID.
• HR_OPERATING_UNITS and ORG_ORGANIZATION_DEFINITIONS — resolve ORG_ID and SHIP_FROM_ORG_ID.
• VEH_RA_ADDRESSES — the legacy Phase 1 source from which some attributes were carried forward.
• QP_PRICE_LISTS — referenced via PRICE_LIST_ID for pricing context.
• OE_AGREEMENTS (or the RLM blanket/agreement structures) — associated through AGREEMENT_ID, FUTURE_AGREEMENT_ID, and BLANKET_NUMBER.
• PO_SUPPLIER_CONTACTS or equivalent contact repositories — referenced by SUPPLIER_CONTACT_ID and CUSTOMER_CONTACT_ID.

These associations should be validated against the deployed 12.1.1 or 12.2.2 instance, as the metadata documents the table as relationally standalone.