Search Results okx_inv_prepays_v

Overview

The OKX_INV_PREPAYS_V view is a reporting and integration object owned by the APPS schema within the OKX – Contracts Integration product. In Oracle EBS 12.1.1 and 12.2.2, OKX provides the contracts integration layer that connects Oracle Procurement Contracts with downstream financial and supplier-facing processes. This particular view is documented as presenting "Supplier invoice prepayments," exposing a curated subset of prepayment application data held in the Payables transaction tables.

The view is not a transactional entity; it is a read-only projection designed to satisfy the column contracts expected by contract-related integration programs, concurrent requests, and downstream interfaces. Its principal role is to surface prepayment application amounts alongside the reporting date and operating unit, so that contracts and supplier management functions can consume that information without querying the base Payables tables directly. The view is marked VALID and is listed with the object type VIEW under the OKX product/module, indicating it is actively maintained at the documented 12.2.2 metadata level.

Underlying Base Objects

The view is defined over a single documented base object: AP_INVOICE_PREPAYS_ALL, referenced through the APPS synonym. AP_INVOICE_PREPAYS_ALL is the Payables table that stores prepayment application records—each row links a prepayment invoice to an applied amount and records the date the prepayment was reported. It is an _ALL table, meaning it is partitioned by ORG_ID (operating unit), and the view preserves that ORG_ID column without filtering, so a query against OKX_INV_PREPAYS_V returns prepayment rows across all operating units the querying user is privileged to see.

Because the view selects directly from AP_INVOICE_PREPAYS_ALL with no joins, aggregations, or additional predicates in the documented view text, it is effectively a renamed and re-shaped projection. No DISTINCT, GROUP BY, or WHERE clause is present, so there is no deduplication or business-rule filtering applied. The view text also performs no NVL or type conversion on the source columns other than the concatenation used to build DESCRIPTION.

Key Columns

The documented view text selects and aliases the following columns, several of which are renamed to satisfy generic integration column contracts:

• ID1 – maps to IP.PREPAY_ID, the unique prepayment application identifier.
• ID2 – maps to IP.INVOICE_ID, the invoice identifier used in the EBS integration framework.
• PREPAYMENT_AMOUNT_APPLIED – the amount of the prepayment that has been applied.
• DATE_REPORTED – the date the prepayment application was reported.
• ORG_ID – the operating unit identifier from the _ALL table.
• NAME – aliased from IP.INVOICE_ID, providing a display name for the record.
• DESCRIPTION – a concatenated string of PREPAYMENT_AMOUNT_APPLIED, the literal text " REPORTED ON ", and DATE_REPORTED.
• START_DATE_ACTIVE / END_DATE_ACTIVE – SYSDATE and NULL respectively, supplying date-effective columns for the integration framework.
• STATUS – the literal 'A' (active) for every row.

Common Use Cases and Queries

The view is typically queried in supplier prepayment reconciliation, contract-to-invoice analysis, and integration extracts where a uniform column layout (ID1, ID2, NAME, STATUS) is required. A representative query joining to Payables invoice headers is shown below.

• Reconciling applied prepayments by operating unit for a reporting period.
• Feeding contract integration extracts that expect ID1/ID2/STATUS semantics.
• Auditing supplier prepayment activity against DATE_REPORTED.

SELECT p.ORG_ID,
       p.ID2            AS invoice_id,
       p.PREPAYMENT_AMOUNT_APPLIED,
       p.DATE_REPORTED
FROM   APPS.OKX_INV_PREPAYS_V p
WHERE  p.ORG_ID = :p_org_id
AND    p.DATE_REPORTED >= :p_from_date
ORDER BY p.DATE_REPORTED DESC;

Because the view has no WHERE clause, all filtering—by org, date, or supplier—must be supplied by the caller. Queries should always include an ORG_ID predicate when operating within a multi-org environment to avoid unnecessary cross-operating-unit scans.