Results for “func_cur_code”

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

Overview

POA_DBI_PLL_MV is a materialized view owned by the APPS schema in Oracle E-Business Suite, registered under the FND (Application Object Library) product. Despite its FND classification, the object is functionally a Procurement (PO) data-extract structure: its column set and the single documented foreign key to PO_COMMODITIES_B place it squarely in the purchasing and sourcing reporting domain rather than in FND itself. The name follows the Oracle EBS convention for DBI (Daily Business Intelligence) procurement materialized views, indicating that it is refreshed from the transactional purchasing tables to support aggregated, query-efficient reporting rather than to store user-entered data.

The ETRM documentation states that the object is not implemented in this database, meaning it exists only when the corresponding Procurement DBI/analytics schema is licensed and installed. Because the structure is physically absent in the reference environment, the documented schema is derived from the object definition rather than from live data. The 20 documented columns describe a line-level extract combining purchase-order buyer, item, category, and commodity attributes.

The provided Data Vault classification is standalone, which should be read as a heuristic modeling suggestion rather than a certified Data Vault designation. In practice, POA_DBI_PLL_MV behaves like a denormalized reporting satellite sourced from the transactional purchasing hub and link structures; the presence of BUSINESS-KEY-type attributes (buyer, item, category, commodity) alongside an aggregate count column supports a satellite-style suggestion rather than a strict hub classification.

Key Information Stored

The most significant documented columns are the identifying and descriptive purchasing attributes:

• LINE_LOCATION_ID — the purchase-order line location reference, a key linkage back to the transactional purchasing schema and the closest thing to a surrogate business anchor in this extract.
• BUYER_ID — the purchasing agent responsible for the order; a primary grouping dimension for buying analysis.
• CATEGORY_ID — the purchasing category assigned to the line.
• PO_ITEM_ID — the purchase-order item reference as it appears on the document.
• ITEM_ID — the inventory master item, used for item-level spend and volume analysis.
• ORDER_TYPE — the type of purchase order (for example standard, blanket, planned).
• COMMODITY_ID — the commodity classification, and the only documented foreign key; it references PO_COMMODITIES_B.
• BASE_UOM and BASE_UOM_CONV_RATE — the base unit of measure and the conversion factor applied to normalize quantities across units.
• MATCHING_BASIS — the receipt-to-invoice matching rule applied to the line.
• EXPECTED_DATE — the expected delivery or receipt date, used for lead-time and on-time analysis.
• DAYS_EARLY_RECEIPT_ALLOWED and DAYS_LATE_RECEIPT_ALLOWED — tolerances governing acceptable receipt timing.
• PRICE_OVERRIDE — indicates whether the line price overrides the standard or agreement price.
• PAYMENT_TYPE and SHIPMENT_TYPE — commercial terms governing payment and shipment behavior.
• RECEIVING_ROUTING_ID — the routing used to direct the receipt.
• FUNC_CUR_CODE — the functional currency code applied to the line.
• CNT — an aggregate count column, consistent with the object's role as a pre-aggregated reporting view.

No surrogate primary key is documented. The unique index I_SNAP$_POA_DBI_PLL_MV, built with SYS_OP_MAP_NONNULL wrappers, identifies the business-key candidates: the combination of BUYER_ID, CATEGORY_ID, PO_ITEM_ID, ORDER_TYPE, ITEM_ID, BASE_UOM_CONV_RATE, EXPECTED_DATE, DAYS_LATE_RECEIPT_ALLOWED, DAYS_EARLY_RECEIPT_ALLOWED, BASE_UOM, PRICE_OVERRIDE, LINE_LOCATION_ID, MATCHING_BASIS, RECEIVING_ROUTING_ID, COMMODITY_ID, PAYMENT_TYPE, SHIPMENT_TYPE, COMPLEX_WORK_FLAG, and FUNC_CUR_CODE. The "SNAP$_" prefix and NULL-normalization wrappers are characteristic of a materialized-view snapshot index, confirming the extract nature of the object.

Common Use Cases and Queries

Because the object is a DBI-style aggregate, its practical uses revolve around procurement spend, buyer performance, and delivery analysis.

• Buyer-level workload reporting — group by BUYER_ID and CNT to measure ordering activity per purchasing agent.
• Category and commodity spend — join CATEGORY_ID and COMMODITY_ID to their respective master tables to roll up spending.
• Delivery performance — compare EXPECTED_DATE against receipt dates, using DAYS_EARLY_RECEIPT_ALLOWED and DAYS_LATE_RECEIPT_ALLOWED to classify lines as on-time, early, or late.
• Item and UOM normalization — apply BASE_UOM_CONV_RATE to standardize quantities to a common BASE_UOM before aggregation.

A representative pattern:

SELECT buyer_id, category_id, COUNT(1) line_count
FROM   apps.poa_dbi_pll_mv
GROUP  BY buyer_id, category_id;

When joining to commodity master data, use the documented foreign key:

SELECT m.buyer_id, c.commodity_name, SUM(m.cnt)
FROM   apps.poa_dbi_pll_mv m
JOIN   apps.po_commodities_b c
       ON c.commodity_id = m.commodity_id
GROUP  BY m.buyer_id, c.commodity_name;

Because the view may not be implemented in a given environment, definitions should always be validated against the deployed schema before dependent reports are built.

Related Objects

The documented relationship data is deliberately narrow, but it anchors the object to the purchasing schema.

• PO_COMMODITIES_B — the only documented foreign key target, joined on COMMODITY_ID.
• PO_HEADERS_ALL / PO_LINES_ALL / PO_LINE_LOCATIONS_ALL — the transactional purchasing tables that LINE_LOCATION_ID derives from.
• PO_ITEM_ATTRIBUTES / MTL_SYSTEM_ITEMS_B — the item sources for PO_ITEM_ID and ITEM_ID.
• PO_CATEGORIES / EGP_CATEGORIES — the reference tables for CATEGORY_ID.
• PO_BUYERS or PER_ALL_PEOPLE_F — the source for BUYER_ID in procurement reporting.
• Other POA_DBI_PLL_* materialized views — sibling extracts within the Procurement DBI schema sharing the same business-key structure.

Any integration or custom report should treat POA_DBI_PLL_MV as a refresh-dependent reporting artifact and not as a substitute for the underlying transactional purchasing tables.