Results for “rcv_vrc_txs_v”

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

Overview

RCV_VRC_TXS_V is a reporting view owned by the APPS schema in Oracle E-Business Suite, catalogued under the Purchasing (PO) product family. Its ETRM description reads "10SC ONLY - Retrofitted," indicating that the object originated as a customer-specific or regional retrofit rather than a core shipped view, and that it has been folded into the standard 12.1.1 and 12.2.2 installations as a valid, compilation-clean database object. The view consolidates receiving transaction data from RCV_TRANSACTIONS and its associated shipment, purchasing, and human-resources reference tables into a single denormalized projection.

Functionally, the view presents receipt, delivery, and return transactions enriched with sourcing context: the originating purchase order, release, and distribution; the supplier or internal source organization; the item and revision; the ship-to and deliver-to locations and persons; and the source document quantity and unit of measure. This makes it suitable for receiving activity reporting, reconciliation of received quantities against ordered quantities, and downstream integration extracts where a flattened transaction record is required without joining eight or more base objects at runtime. Because the view text resolves descriptive columns through HR and PO lookup views, it also shields report authors from the underlying normalization of location, person, and vendor data.

Underlying Base Objects

The documented base objects span several application schemas exposed through APPS synonyms and views. The primary driving table is RCV_TRANSACTIONS (synonym), aliased RT in the view text, which supplies the transaction identity and core attributes. RCV_SHIPMENT_HEADERS and RCV_SHIPMENT_LINES (synonyms), aliased RSH and RSL respectively, provide the receipt header context, item, revision, description, vendor item number, and the from-organization for internal transfers. RCV_ROUTING_HEADERS (view) supplies routing context for in-transit shipments.

Purchasing-side joins include PO_HEADERS_TRX_V, PO_LINES_TRX_V, PO_LINE_LOCATIONS_TRX_V, PO_DISTRIBUTIONS_TRX_V, PO_RELEASES_ALL, PO_VENDORS, and PO_VENDOR_SITES, which together resolve the PO document hierarchy, distribution, supplier name, and supplier site. Requirement and job context is drawn from PO_REQ_HEADERS_TRX_V, PO_REQ_LINES_TRX_V, and PO_JOB_ASSOCIATIONS. Human-resources references include HR_LOCATIONS_ALL_TL, HR_ALL_ORGANIZATION_UNITS_TL, PER_PEOPLE_F, and PER_JOBS, with HR_GENERAL, HR_PERSON_NAME, and HR_SECURITY packages or views used to resolve names and apply security. Order Management objects OE_ORDER_HEADERS_ALL, OE_ORDER_LINES_ALL, OE_TRANSACTION_TYPES_ALL, and OE_TRANSACTION_TYPES_TL support return (RMA) sourcing. Currency and territory context is provided by FND_CURRENCIES_VL, GL_DAILY_CONVERSION_TYPES, and FND_TERRITORIES_TL, while HZ_PARTIES, HZ_CUST_ACCOUNTS, FND_GLOBAL, and PO_CLM_INTG_GRP complete the dependency set.

Key Columns

• TRANSACTION_ID, PARENT_TRANSACTION_ID, SHIPMENT_HEADER_ID, SHIPMENT_LINE_ID, INTERFACE_TRANSACTION_ID — transaction and shipment identity, supporting hierarchy traversal between parent and child receipts.
• TRANSACTION_TYPE, TRANSACTION_DATE, ORGANIZATION_ID — the nature, timing, and receiving organization of the transaction.
• TRANSACT_QTY / TRANSACT_UOM and PRIMARY_UOM — quantity and unit of measure as transacted versus the item's primary UOM.
• ITEM_ID, ITEM_REV, ITEM_DESC, VENDOR_ITEM_NUM — item identification and vendor-facing description sourced from RCV_SHIPMENT_LINES.
• DESTINATION_TYPE_CODE — destination classification: INVENTORY, WIP, or EXPENSE.
• PO_HEADER_ID, PO_LINE_ID, PO_LINE_LOCATION_ID, PO_DISTRIBUTION_ID, PO_RELEASE_ID — the purchasing document hierarchy associated with the receipt.
• SHIP_TO_LOCATION / SHIP_TO_LOCATION_DESC and DELIVER_TO_LOCATION / DELIVER_TO_LOCATION_DESC — resolved location code and description.
• RECEIVER, DELIVER_TO_PERSON — full names resolved through HR person-name logic, with the employee identifier derived as NVL(RSL.EMPLOYEE_ID, RT.EMPLOYEE_ID).
• SOURCE_DOC_CODE, SOURCE_DOC_UOM, SOURCE_DOC_QTY — the originating document, with quantity decoded from ordered quantity for RMA and PO line quantity otherwise.
• SOURCE_TYPE — receipt source classification: INTERNAL ORDER, INVENTORY, or VENDOR.
• SUPPLIER_ID, SUPPLIER, VENDOR_NAME, SUPPLIER_SITE_ID, SUPPLIER_SITE — supplier identity decoded conditionally by source document, returning NULL for RMA rows.
• FROM_ORGANIZATION_ID, WIP_ENTITY_ID, WIP_LINE_ID, SUBINVENTORY, LOCATOR_ID — internal transfer and inventory placement attributes.

Common Use Cases and Queries

The view is typically consumed for receiving activity extracts, three-way match preparation, and exceptions reporting. A standard pattern filters transactions for a date range and organization while projecting supplier, PO, and item detail:

• Receipt register by period: SELECT transaction_date, transaction_type, source_type, supplier, item_desc, transact_qty, transact_uom FROM rcv_vrc_txs_v WHERE organization_id = :org_id AND transaction_date BETWEEN :from_date AND :to_date ORDER BY transaction_date.
• Supplier receipt reconciliation: join or aggregate on supplier_id, po_line_location_id, and source_doc_qty to compare received quantities against ordered quantities for a given PO.
• By source document: filter on source_doc_code (PO, RMA) to isolate purchasing versus return receipts, since supplier columns are conditionally NULL for RMA rows.
• Destination analysis: group by destination_type_code to report receipts delivered to inventory, WIP, and expense destinations separately.

Because the view embeds HR security and name-resolution logic through PER_PEOPLE_F, HR_PERSON_NAME, and HR_SECURITY, queries executed by restricted users may return fewer receiver and deliver-to rows than queries run by privileged accounts. Report authors should also note the "10SC ONLY - Retrofitted" provenance: while the object is VALID in 12.1.1 and 12.2.2, its presence should be verified before being treated as a supported integration interface, and any custom dependency should be reviewed during upgrades.