Search Results pjm_po_commitments_stub_v

Overview

PJM_PO_COMMITMENTS_STUB_V is a stub view owned by the APPS schema in Oracle E-Business Suite, delivered as part of the PJM – Project Manufacturing product family. Its documented description is "Project-related unreceived purchase order distributions view for non-project manufacturing customers." The view is registered with a status of VALID in both Oracle EBS 12.1.1 and 12.2.2, and it forms part of the standard ETRM (E-Business Suite Technical Reference Manual) object inventory for the PJM module.

The defining characteristic of this object is that it is a stub: the view text resolves to a static, empty result set. Every column projection is expressed as either a placeholder string (RPAD of asterisks) or a typed NULL (TO_NUMBER(NULL), TO_DATE(NULL)), and the query terminates with the predicate WHERE 1 = 2. The view therefore never returns rows. Its role is structural rather than analytical — it provides a stable column contract that surrounds the project manufacturing commitments reporting surface, allowing callers, reports, or integration layers to reference a consistent interface without altering the commitments data model.

Underlying Base Objects

The ETRM metadata records a single referenced base object: PA_IMPLEMENTATIONS_ALL, accessed through a SYNONYM. This table is the Projects (PA) implementation registry; it stores one row per installation of Oracle Projects in the instance, including organization and implementation parameters. Because the view is filtered by WHERE 1 = 2, the reference to PA_IMPLEMENTATIONS_ALL is effectively a syntactic anchor for the row source and a license/installation dependency rather than a data source. No temporal join, indexed access, or row-level relationship to PA_IMPLEMENTATIONS_ALL is exercised at runtime, since the predicate eliminates all rows before any selection occurs.

The view exposes the same column shape that project-related purchase order commitment reporting expects, but without binding it to the transactional commitment tables (such as PO distributions or receiving distributions) in instances where project manufacturing is not deployed. This conditional design allows the executable to compile a uniform projection against the commitments interface regardless of customer configuration.

Key Columns

The column list mirrors the standard unreceived PO commitments column set. Notable columns include:

• PO_NUMBER, PO_REVISION, RELEASE_NUMBER, RELEASE_REVISION — purchase order and release identity fields, typed as character placeholders in the stub.
• APPROVED_FLAG, EVER_APPROVED_FLAG — approval status indicators for the document.
• DOCUMENT_TYPE — classifies the document (for example, standard PO or blanket release); in the stub this is an 80-character placeholder.
• CREATION_DATE, APPROVED_DATE, PRINTED_DATE — lifecycle timestamps, each projected as TO_DATE(NULL).
• REQUESTOR_PERSON_ID / REQUESTOR_NAME, BUYER_PERSON_ID / BUYER_NAME — person identifiers and display names for the requesting and buying parties.
• VENDOR_ID, VENDOR_NAME — supplier identification fields.
• PO_LINE, ITEM_DESCRIPTION, UNIT, UNIT_PRICE — line-level detail describing the committed item and its pricing.
• DENOM_CURRENCY_CODE, ACCT_CURRENCY_CODE, ACCT_RATE_DATE, ACCT_RATE_TYPE — currency and exchange-rate conversion attributes used when commitments are reported in accounting currency.
• Trailing numeric and currency columns (including the ACCT_EX family) — quantity and amount measures associated with commitment reporting, exposed as TO_NUMBER(NULL).

Because all values are placeholders or NULLs, the columns exist solely to satisfy schema expectations; they carry no data in this view.

Common Use Cases and Queries

The primary use case is interface stability. Some PJM reports and commitments extraction programs reference PJM_PO_COMMITMENTS_STUB_V through a UNION ALL or conditional wrapper so that a single SQL statement can return project-related unreceived PO distributions in project manufacturing installations while returning an empty set elsewhere. Consumers should query the corresponding live commitments view when project manufacturing is enabled and treat this stub as a no-op placeholder.

A typical sanity or dependency query confirms that the object is installed and empty:

• SELECT COUNT(*) FROM APPS.PJM_PO_COMMITMENTS_STUB_V; — expected result is 0 in all supported releases.
• SELECT po_number, vendor_name, unit_price FROM APPS.PJM_PO_COMMITMENTS_STUB_V WHERE po_number IS NOT NULL; — returns no rows by design.
• SELECT text FROM dba_views WHERE owner = 'APPS' AND view_name = 'PJM_PO_COMMITMENTS_STUB_V'; — retrieves the stored projection to verify the WHERE 1 = 2 predicate.

Practitioners investigating the term "quantity_overbilled" should note that this view exposes no such column; overbilling comparison logic belongs to AP/PO matching and receiving-related objects, not to this stub. When customizing or debugging PJM commitments reporting, treat PJM_PO_COMMITMENTS_STUB_V strictly as a schema-compatible empty shell and direct data retrieval to the active commitments view for project manufacturing customers.