Results for “chv_cum_period_items”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

CHV_CUM_PERIOD_ITEMS is a table owned by the PO schema in Oracle E-Business Suite, associated with the CHV (Supplier Scheduling) product family. The ETRM metadata classifies this object with a status of VALID at the dictionary level, but the functional description is explicitly recorded as Obsolete. This dual designation is significant: the physical segment remains present and queryable in both 12.1.1 and 12.2.2 environments, yet Oracle has retired the business process that originally populated and consumed it. The table holds 31 columns and is documented in the ETRM 12.2.2 physical schema, meaning DBAs performing impact analysis or upgrade remediation will still encounter it during dependency sweeps.

Historically, CHV supported supplier scheduling and cumulative (CUM) management — the mechanism by which authorized cumulative quantities are communicated to suppliers against blanket agreements and scheduling agreements. CHV_CUM_PERIOD_ITEMS appears to have stored item-level detail within a cumulative period, giving schedulers the ability to resolve cumulative receipts and authorizations down to the item, vendor, and vendor site level. The heuristic Data Vault classification derived from the foreign-key structure is standalone. Because the table carries no documented foreign keys pointing outward (the only relationship recorded is an inbound reference from CHV_PURGE_CUM_LIST), it is best modeled as a standalone satellite-like structure rather than a true hub or link.

Key Information Stored

The surrogate primary key is CUM_PERIOD_ITEM_ID, enforced by the unique index CHV_CUM_PERIOD_ITEMS_U1. No other unique business-key candidate is documented, so the surrogate key is the sole guaranteed identifier. The most business-significant columns are:

• CUM_PERIOD_ID — the foreign key linking each row back to the owning cumulative period definition. This is the primary relational anchor of the table.
• ORGANIZATION_ID — operating unit or inventory organization context, enabling multi-org filtering in reporting.
• VENDOR_ID and VENDOR_SITE_ID — the supplier and specific supplier site associated with the cumulative item line.
• ITEM_ID — the inventory item to which the cumulative period quantity relates.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE15 — the standard EBS DFF (Descriptive Flexfield) block, providing extensible descriptive storage.
• CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — the standard Who columns for audit and change tracking.
• REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — concurrent program context, identifying the batch job that last touched the row.

Note that the metadata does not document explicit quantity or amount columns; consumption of cumulative figures was likely handled through related structures now superseded by the current scheduling architecture.

Common Use Cases and Queries

Because the object is obsolete, primary use cases are historical reporting, data archival, and pre-upgrade impact assessment rather than live transactional processing. A typical archival or reconciliation query joins the table to its parent cumulative list to recover supplier and period context:

• Cumulative item detail by period: SELECT cpi.cum_period_item_id, cpi.cum_period_id, cpi.vendor_id, cpi.vendor_site_id, cpi.item_id FROM po.chv_cum_period_items cpi WHERE cpi.organization_id = :org_id AND cpi.cum_period_id = :period_id;
• Purge cycle inspection: join to CHV_PURGE_CUM_LIST on cpi.cum_period_id = pcl.cum_period_id to determine which items were flagged for cleanup.
• Supplier-level aggregation: group by vendor_id and vendor_site_id to reconstruct cumulative authorizations for a supplier across a date range.
• Program audit: filter on request_id or program_id to trace which concurrent process last modified obsolete rows prior to migration.

Report developers should treat query results as a frozen historical snapshot, since no current EBS process writes to the table.

Related Objects

The documented foreign-key relationship identifies one direct dependency, and the surrounding CHV scheduling tables provide the practical context for joining or migrating data:

• CHV_PURGE_CUM_LIST — referenced via CHV_CUM_PERIOD_ITEMS.CUM_PERIOD_ID → CHV_PURGE_CUM_LIST. This is the only documented FK and the primary relational anchor.
• PO_VENDORS / PO_VENDOR_SITES_ALL — resolved through VENDOR_ID and VENDOR_SITE_ID for supplier detail.
• MTL_SYSTEM_ITEMS_B — resolved through ITEM_ID for item descriptions and UOMs.
• HR_ALL_ORGANIZATION_UNITS / organization views — resolved through ORGANIZATION_ID for operating unit context.
• Other CHV cumulative and scheduling objects (e.g., cumulative period and schedule headers) that share the CUM_PERIOD_ID lineage and were migrated alongside this obsolete structure.

The absence of outbound foreign keys confirms the standalone classification: downstream objects reference this table rather than the reverse, so removal or archival requires checking dependent purge logic before any schema change.