Results for “oke_dts_receiving_v”

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

Overview

OKE_DTS_RECEIVING_V is a read-only view owned by the APPS schema in Oracle E-Business Suite, catalogued under the OKE – Project Contracts product family. It is a reporting and integration object that consolidates receiving activity against contract deliverables into a single denormalized row set. In ETRM terms, the view answers the question: for a given contract deliverable, what purchase order, shipment, and receipt transactions exist, and what is their current status?

The view is especially relevant to users searching on receipt_line_number. That column (exposed as RECEIPT_LINE_NUMBER) is the shipment line number from RCV_SHIPMENT_LINES, which identifies the specific receipt line associated with a deliverable. It allows the receiving record to be tied back to the purchase order shipment and the deliverable in one query.

Because the view joins PO, RCV, and OKE-related deliverable identifiers, it is typically used for deliverable tracking, receiving reconciliation, and supplier performance reporting in project-driven procurement. It is not an interface table; no DML is expected against it.

Underlying Base Objects

The view is defined over six synonym-backed base tables, joined on purchase order, shipment, and distribution keys:

• PO_LINES_ALL — supplies PO_HEADER_ID, PO_LINE_ID, and ordered quantity.
• PO_LINE_LOCATIONS_ALL — supplies LINE_LOCATION_ID, NEED_BY_DATE, and PROMISED_DATE.
• PO_DISTRIBUTIONS_ALL — carries OKE_CONTRACT_HEADER_ID, OKE_CONTRACT_LINE_ID, OKE_CONTRACT_DELIVERABLE_ID, PROJECT_ID, and TASK_ID; the filter requiring OKE_CONTRACT_DELIVERABLE_ID IS NOT NULL is applied here.
• RCV_SHIPMENT_HEADERS — provides SHIPMENT_HEADER_ID, RECEIPT_NUM, and SHIPPED_DATE.
• RCV_SHIPMENT_LINES — provides SHIPMENT_LINE_ID, LINE_NUM (the receipt line number), and shipment line status code.
• RCV_TRANSACTIONS — provides transaction quantity, UOM, transaction type, transaction date, and destination type code.
• FND_LOOKUP_VALUES — joined twice for lookup meanings: SHIPMENT LINE STATUS and RCV TRANSACTION TYPE (view application ID 201).

Key Columns

• RECEIPT_LINE_NUMBER — the shipment line number (SL.LINE_NUM), the surrogate key most commonly searched alongside receipt number.
• RECEIPT_NUMBER — the human-readable receipt document number from RCV_SHIPMENT_HEADERS.
• DELIVERABLE_ID, PROJECT_ID, TASK_ID — identify the contract deliverable and its project/task context.
• PO_HEADER_ID, PO_LINE_ID, PO_LINE_LOCATION_ID — link the receiving record back to purchasing documents.
• SHIPMENT_HEADER_ID, SHIPMENT_LINE_ID — internal keys for the shipment and receipt line.
• QUANTITY, UOM — received transaction quantity and unit of measure.
• TRANSACTION_TYPE, TRANSACTION_DATE, DESTINATION_TYPE_CODE — transaction classification and timing (e.g., DELIVER, RETURN TO VENDOR).
• SHIPMENT_LINE_STATUS — descriptive lookup meaning for the shipment line status code.
• PLANNED_RECEIPT_DATE / ACTUAL_RECEIPT_DATE — need-by/promised dates versus actual shipped date for delivery performance analysis.

Common Use Cases and Queries

Typical scenarios include reconciling contract deliverables to receipts, reporting late or partial deliveries, and auditing receipt transactions per project. A representative query locating records by receipt line number is shown below.

SELECT receipt_number, receipt_line_number, deliverable_id, project_id, quantity, uom, transaction_type, transaction_date, shipment_line_status FROM apps.oke_dts_receiving_v WHERE receipt_line_number = :p_receipt_line_number ORDER BY transaction_date DESC;

To summarize received quantity per deliverable:

SELECT deliverable_id, project_id, SUM(quantity) total_received FROM apps.oke_dts_receiving_v WHERE transaction_type = 'DELIVER' GROUP BY deliverable_id, project_id;

Because the joins are exact (only the status lookup is outer-joined), rows appear only where a receipt transaction exists against an OKE-linked distribution, which keeps deliverable-level receiving reporting precise in both 12.1.1 and 12.2.2.