Search Results cz_atp_requests




Overview
Explore in AI Chat

Overview

CZ_ATP_REQUESTS is an interface table owned by the CZ schema within the Oracle E-Business Suite Configurator module. Its documented description is "ATP interface table," indicating that it serves as a staging and communication structure through which the Configurator passes availability-to-promise (ATP) request data to Oracle's ATP and scheduling engines. When a configurable item is selected in the Configurator, the application must determine whether the requested quantity can be promised for a given need-by or ship-to date. CZ_ATP_REQUESTS holds those request records, keyed to a Configurator session and the specific configuration item being evaluated, so the ATP process can process, resolve, and return availability results.

From a Data Vault modeling perspective, the mined foreign-key structure suggests a satellite-leaning classification. The table's single foreign-key dependency on CZ_PS_NODES, combined with its dependency on a Configurator session and a configuration item, means it functions as a descriptive, session-scoped record rather than an independent hub of business entities. Modelers treating this as a satellite should anchor it to the relevant Configurator session and node hubs.

Key Information Stored

The table is documented with 17 columns. The most significant are:

  • ATP_REQUEST_ID — the surrogate primary key defined by CZ_ATP_REQUESTS_PK. It uniquely identifies each ATP request record.
  • CONFIGURATOR_SESSION_KEY and SEQ_NO — together forming the business-key candidate CZ_ATP_REQUESTS_U1. The session key ties the request to a specific Configurator session, while SEQ_NO orders requests within that session.
  • CONFIGURATOR_SESSION_KEY and CONFIG_ITEM_ID — forming the unique index CZ_ATP_REQUESTS_U2, ensuring one request per configuration item per session.
  • PS_NODE_ID — foreign key to CZ_PS_NODES, linking the request to the Configurator product structure node.
  • ITEM_KEY and ITEM_KEY_TYPE — the inventory item being checked and the identifier scheme used to reference it.
  • QUANTITY and UOM_CODE — the requested amount and unit of measure for the ATP check.
  • INV_ORG_ID — the inventory organization against which availability is evaluated.
  • SHIP_TO_DATE and NEED_BY_DATE — the scheduling dates driving the promise calculation.
  • DAYS_LATE — the computed lateness of the request relative to the requested date.
  • PARENT_CONFIG_ITEM_ID, ATO_CONFIG_ITEM_ID, and COMPONENT_SEQUENCE_ID — hierarchical references identifying the parent configuration item, the assemble-to-order parent, and component sequencing.
  • MSG_DATA — the message payload exchanged with the ATP interface.

Common Use Cases and Queries

Typical uses include auditing ATP requests per Configurator session, reconciling requested dates against computed lateness, and diagnosing failed or unprocessed interface records.

  • Retrieve all ATP requests for a session: SELECT * FROM CZ.CZ_ATP_REQUESTS WHERE CONFIGURATOR_SESSION_KEY = :key ORDER BY SEQ_NO;
  • Identify late requests: SELECT ATP_REQUEST_ID, ITEM_KEY, QUANTITY, DAYS_LATE FROM CZ.CZ_ATP_REQUESTS WHERE DAYS_LATE > 0;
  • Join to the product structure node for hierarchical reporting: SELECT r.ATP_REQUEST_ID, n.* FROM CZ.CZ_ATP_REQUESTS r JOIN CZ.CZ_PS_NODES n ON r.PS_NODE_ID = n.PS_NODE_ID;
  • Summarize requested quantities by inventory organization: SELECT INV_ORG_ID, SUM(QUANTITY) FROM CZ.CZ_ATP_REQUESTS GROUP BY INV_ORG_ID;

Related Objects

The most significant related objects are:

  • CZ_PS_NODES — referenced via CZ_ATP_REQUESTS.PS_NODE_ID, providing the product structure node context for each request.
  • CZ_CONFIG_ITEMS / configuration item structures — related through CONFIG_ITEM_ID, PARENT_CONFIG_ITEM_ID, and ATO_CONFIG_ITEM_ID.
  • CZ_CONFIGURATOR_SESSIONS — the session referenced by CONFIGURATOR_SESSION_KEY.
  • ATP and scheduling interface objects — the downstream ATP engine consuming MSG_DATA payloads.
  • INV_ORG / inventory organization reference tables — related via INV_ORG_ID for availability checks.
  • CZ_ATP_REQUESTS_PK, U1, and U2 indexes — enforcing key and business-key uniqueness.