PO-03: Receiving Diagnostic | William A. Green

Oracle EBS Purchasing receiving transactions create the three-way match foundation for AP invoice validation — every AP invoice matched to a PO requires a receipt in RCV_TRANSACTIONS that confirms the goods or services were actually received before the invoice is paid. When receiving transactions are entered incorrectly — wrong quantity, wrong unit of measure, wrong PO line — the mismatch between the receipt record and the AP invoice causes a QUANTITY RECEIVED hold that blocks payment until a correcting transaction is entered.

The receiving correction hierarchy in Oracle EBS has three levels of increasing complexity. A Return to Vendor (RTV) transaction reverses a receipt and reduces the received quantity, allowing a correcting receipt to be entered with the correct quantity. A Return to Receiving moves goods from a sub-inventory back to the receiving dock without involving the vendor. A Receiving transaction correction directly adjusts the quantity on an existing RCV_TRANSACTIONS row — this is the most surgical option but requires specific conditions: the goods must still be in the receiving location and no downstream transactions (delivery, inspection, put-away) must have consumed the original quantity.

Unordered receipts are the third category. When goods arrive at the dock without a PO reference — because the PO was created after the goods shipped, or because the receiver could not locate the PO number — Oracle allows an unordered receipt to be entered. Unordered receipts appear in RCV_SHIPMENT_LINES with a TRANSACTION_TYPE of UNORDERED and are matched to a PO by the Receiving team after the fact. If the match is never performed, the AP invoice referencing the PO cannot find the receipt and receives a QUANTITY RECEIVED hold.

PO-03 runs a complete receiving diagnostic — receipt transaction status and quantity for each PO line, unmatched unordered receipt identification, receiving quantity vs PO ordered quantity vs AP billed quantity three-way reconciliation, RTV availability check, inspection status for inspection-required items, and over-receipt tolerance configuration.

Three-Way Reconciliation

PO ordered quantity vs received quantity vs AP billed quantity. Identifies the specific PO line and AP invoice with a quantity mismatch. Calculates the exact variance driving the hold.

Unordered Receipt Detection

RCV_SHIPMENT_LINES records with TRANSACTION_TYPE = UNORDERED that have not been matched to a PO. Identifies the supplier, item description, and candidate PO lines for the match.

Correction Availability

RTV and receiving correction eligibility — confirms whether downstream transactions (delivery, inspection, put-away) have consumed the original receipt quantity, determining which correction method is available.

Inspection Status

Inspection-required items — inspection transaction status in RCV_TRANSACTIONS. PASSED, FAILED, and pending inspection identification. Flags goods that cannot be delivered to inventory until inspection is completed.

════════════════════════════════════════════════════════════
  ORACLE EBS R12 — PO RECEIVING DIAGNOSTIC
════════════════════════════════════════════════════════════
  Receipt Number     : RCV-2026-008841
  PO Number          : PO-2026-004481
  Supplier           : Acme Technology Solutions
  Case Number        : PO-504180
  Report Date        : 21-FEB-2026 09:45:20
════════════════════════════════════════════════════════════

[ SECTION 1 — RECEIPT TRANSACTIONS ]
────────────────────────────────────────────────────────────
  PO Line 1 — Laptops: 50 ordered — 48 received (RCV-2026-008841)
  PO Line 1 Status   : 2 units short — AP invoice for 50 units on QUANTITY RECEIVED hold ✗
  PO Line 2 — Docking: 30 ordered — 30 received ✓

[ SECTION 2 — THREE-WAY RECONCILIATION ]    STATUS: ✗ FAIL
────────────────────────────────────────────────────────────
  PO Ordered         : 50 units
  Received           : 48 units
  AP Invoiced        : 50 units
  Variance           : 2 units — receipt short of invoice quantity ✗

[ SECTION 3 — UNORDERED RECEIPTS ]          STATUS: ✓ PASS
────────────────────────────────────────────────────────────
  No unmatched unordered receipts for this supplier ✓

[ SECTION 4 — RTV AVAILABILITY ]            STATUS: ✓ PASS
────────────────────────────────────────────────────────────
  RTV available for PO Line 1 if needed ✓

[ SECTION 5 — INSPECTION STATUS ]           STATUS: ✓ PASS
────────────────────────────────────────────────────────────
  No inspection required for this item category ✓

════════════════════════════════════════════════════════════
  DIAGNOSTIC SUMMARY
════════════════════════════════════════════════════════════
  QUANTITY RECEIVED hold on AP invoice — 2 units short
  FIX: Enter correcting receipt for 2 units OR adjust invoice to 48 units
════════════════════════════════════════════════════════════

KB-PO-504180-001 · Script: PO-03

Receipt RCV-2026-008841 Short 2 Units — AP Invoice on QUANTITY RECEIVED Hold

Module: Purchasing
Platform: EBS R12.2.10
Status: RESOLVED

Symptom

AP invoice for PO-2026-004481 Line 1 (50 Laptops) on QUANTITY RECEIVED hold. Receipt RCV-2026-008841 shows 48 units received. AP invoice was submitted by supplier for all 50 units. 2-unit shortfall blocks payment.

Root Cause

Physical receipt of 48 units on 18-FEB-2026 — 2 units were on backorder per the supplier's packing slip. The AP invoice was submitted for the full PO quantity of 50 units before the backorder was resolved. The 2-unit backorder receipt has not yet arrived.

Tables Affected

RCV_TRANSACTIONS — QUANTITY = 48 (RCV-2026-008841, PO Line 1 — 2 units short)
AP_HOLDS_ALL — HOLD_LOOKUP_CODE = QUANTITY RECEIVED (AP invoice for 50 units)

Fix Applied

AP invoice quantity corrected to 48 units to match received quantity. QUANTITY RECEIVED hold released. Backorder receipt RCV-2026-008842 entered for 2 units when backorder arrived 24-FEB-2026. Second AP invoice processed for the 2 backorder units.

Prevention

AP should not process supplier invoices that exceed confirmed received quantities. Receiving team to notify AP immediately when partial shipments are received so invoices can be split before submission.

QUANTITY RECEIVED Hold — Short Receipt

AP invoice quantity exceeds receipt quantity — the most common receiving-related AP hold. PO-03 identifies whether the shortfall is a physical receipt gap (goods not yet received) or a data entry error (receipt entered for wrong quantity).

Unmatched

Unordered Receipt Not Matched

Goods received without a PO reference — unordered receipt in RCV_SHIPMENT_LINES not yet matched to a PO line. AP invoice cannot find the receipt until the match is performed.

Over-Receipt

Receipt Exceeds PO Quantity

Received quantity exceeds ordered quantity beyond the over-receipt tolerance. Goods are in inventory but PO cannot be fully invoiced until either an RTV is processed or the PO is amended.

Inspection

Inspection Required — Not Completed

Goods flagged for inspection have been received but not inspected. Cannot be delivered to inventory or matched to AP invoices until inspection result is entered.

Table	Module	Purpose
RCV_TRANSACTIONS	PO	Receiving transactions — quantity, type, PO line reference
RCV_SHIPMENT_LINES	PO	Shipment lines — unordered receipts, status
RCV_SHIPMENT_HEADERS	PO	Shipment headers — receipt date, supplier
PO_LINE_LOCATIONS_ALL	PO	Shipment received/billed qty and tolerance config
AP_HOLDS_ALL	AP	QUANTITY RECEIVED and QUANTITY ORDERED holds
MTL_MATERIAL_TRANSACTIONS	INV	Downstream inventory transactions from receipt
PO_HEADERS_ALL	PO	PO header for supplier and OU context
PO_LINES_ALL	PO	PO line item, UOM, ordered quantity

Decision Framework

How Every Fix Decision Is Made

Before any data is modified in a production Oracle database, AP-01 walks through a four-stage decision process. Every condition identified by the diagnostic maps to exactly one resolution path.

First Option — Always

Can the front end fix this?

Oracle's own forms and concurrent programs are always the first option. If the condition can be corrected through Oracle's standard UI — a form, a concurrent program, a setup screen — that path is taken first. No consultant SQL required, no database risk, and the fix is fully supported by Oracle. The diagnostic identifies these conditions explicitly and states the exact front-end navigation path.

✓ Functional Fix

When Front End Is Not Available

Is a direct data fix safe to apply?

When the front-end path is unavailable or would require an unacceptable volume of manual steps, a direct fix is evaluated against explicit criteria. All of the following must be true before proceeding:

→The fix mirrors exactly what Oracle's own code would have done if the underlying condition were corrected

→All dependent tables have been identified and will be updated in the same transaction

→The fix is fully reversible — a single INSERT from the backup table restores the original state

→The environment patch level has been confirmed against the fix logic version

⚡ Direct Fix

Hard Stops — No Exceptions

Does this require Oracle Support?

Certain table areas are never touched directly, regardless of how well the underlying structure is understood. The diagnostic flags these conditions and generates the Service Request documentation:

✗XLA subledger tables — XLA_EVENTS, XLA_AE_HEADERS — incorrect changes corrupt the subledger audit trail in ways undetectable until period close fails or an auditor requests a reconciliation

✗Workflow engine tables — WF_ITEMS, WF_ITEM_ACTIVITY_STATUSES — ad-hoc DML can corrupt the workflow engine state instance-wide

✗Recurring conditions after a fix — indicates a code defect, not a data error. Documented and submitted as a Service Request with a reproducible test case

⚠ Oracle Support

For All Approved Direct Fixes

Backup → Execute → Verify → Document

A timestamped backup table is created and row-count verified before the first UPDATE fires. Explicit parameter confirmation is required — the script will not self-execute. After execution, a verification query confirms the expected state. A complete change record — rows affected, before and after values, database username, timestamp — is written to the FIX_BACKUP_REGISTRY and becomes the primary artifact in the knowledge base entry for this incident.

📋 Documented

Condition Identified	Resolution Path	Notes
Receipt quantity short of invoice — QUANTITY RECEIVED hold	Functional First	Enter a correcting receipt for the missing quantity via Oracle Receiving. PO-03 identifies the receipt line, the short quantity, and confirms the goods have physically arrived before the correcting receipt is entered.
Over-receipt — received quantity exceeds PO ordered qty	Functional First	Enter a Return to Vendor transaction for the excess quantity via Oracle Receiving. PO-03 identifies the excess units and confirms whether the PO can be amended to cover the over-receipt before initiating the RTV.
Unordered receipt not matched to PO	Functional First	Match the unordered receipt to the correct PO via Purchasing > Receiving > Match Unordered Receipts. PO-03 identifies the unmatched RCV_SHIPMENT_LINES records and the candidate PO lines by supplier and item.
Receipt entered on wrong PO line	Direct Fix	PO-03 corrects the PO_LINE_LOCATION_ID in RCV_TRANSACTIONS with full backup, provided no delivery or inspection transaction has consumed the original receipt. Standard correction form used where available.
Inspection FAILED — goods rejected at inspection	Functional First	Process the inspection result via Oracle Receiving > Inspection. PO-03 identifies the inspection-required items and the inspection transaction status in RCV_TRANSACTIONS.
Receipt in wrong period — accounting date issue	Direct Fix	PO-03 corrects TRANSACTION_DATE in RCV_TRANSACTIONS with full backup after confirming the correct period. Pre-flight verifies no downstream GL posting references the original date.
Receiving transaction not delivered to sub-inventory	Functional First	Complete the Deliver step via Oracle Receiving to move goods from receiving to sub-inventory. PO-03 identifies receipts in RECEIVE status that have not been delivered.
RMA receipt matched to wrong RMA number	Direct Fix	PO-03 corrects the RMA reference in RCV_TRANSACTIONS with full backup. Applicable only when the RMA correction has not yet been processed by AP.

Safeguards

Nothing Executes Without a Safety Net

Before any data fix runs, the script verifies pre-flight conditions and creates a complete verified backup. If any check fails, the script aborts. There is no partial execution path.

Pre-Flight Checks — All Must Pass

✓

POSTED_FLAG = 'N'

Will not modify a posted transaction under any circumstances

✓

ACCOUNTING_EVENT_ID IS NULL

Will not modify rows with an active or pending XLA accounting event

✓

No active database lock

Checks V$LOCK — will not proceed if another session holds a lock on target rows

✓

CONS_BACKUP schema writable

Backup schema must be accessible before any DML is permitted

✓

Explicit confirmation required

Script outputs a confirmation prompt — DML does not execute until consultant enters the case number as the execution parameter

Backup Methodology

Before the first UPDATE fires, the script creates a complete copy of every row to be modified. Tables are named CONS_BACKUP.<TABLE>_<CASE#> and persist permanently after execution.

RCV_TRANSACTIONS

RCV_SHIPMENT_LINES

RCV_SHIPMENT_HEADERS

Row count verified after backup creation. If backup fails for any reason the script aborts without executing any DML. Rollback is a single INSERT from the backup table. No reconstruction required.

PO-03 — Pre-Flight & Backup Verification

════════════════════════════════════════════════════════════
  PRE-FLIGHT SAFETY CHECK
════════════════════════════════════════════════════════════
  Receipt Number     : RCV-2026-008841
  PO Line 1          : 48 received, 50 ordered — 2 short
  Downstream Txns    : No delivery or inspection downstream ✓ Safe to correct
  CONS_BACKUP Schema : Accessible ✓
  Session Lock Check : No locks on RCV_TRANSACTIONS ✓
────────────────────────────────────────────────────────────
  ALL PRE-FLIGHT CHECKS PASSED
════════════════════════════════════════════════════════════
  Creating : CONS_BACKUP.RCV_TRANSACTIONS_504180
  Rows     : 1 row backed up ✓
  Registry : FIX_BACKUP_REGISTRY — ID 6072 created ✓
────────────────────────────────────────────────────────────
  BACKUP COMPLETE
════════════════════════════════════════════════════════════
  Enter case number to confirm : 504180
  Confirmed.
════════════════════════════════════════════════════════════

Knowledge Base

Every Execution Produces a Record

The knowledge base article is generated automatically from the script's execution output. No manual documentation required. It becomes the institutional record — for the team, for auditors, and for every future engagement in the same environment.

Zero Manual Effort

Every field — environment, tables, before/after values, backup reference, root cause, prevention — is generated from actual execution output. Nothing is written by hand.

Patterns Surface Over Time

The first engagement produces findings. The third produces patterns. Recurring conditions that are invisible as individual incidents become obvious as knowledge base trends.

Survives Staff Turnover

The knowledge base is an institutional record of the Oracle environment. A new manager, a new DBA, or an external auditor can read exactly what happened, what was done, and what prevents recurrence.

KB-PO-504180-001

Receipt RCV-2026-008841 Short 2 Units — AP Invoice on QUANTITY RECEIVED Hold

EBS R12.2.10 · Purchasing

● RESOLVED

Symptom

Root Cause

Tables

RCV_TRANSACTIONS — QUANTITY = 48 (RCV-2026-008841, PO Line 1 — 2 units short)
AP_HOLDS_ALL — HOLD_LOOKUP_CODE = QUANTITY RECEIVED (AP invoice for 50 units)

Fix Applied

Prevention

R12 Guide (PDF)	Title & Chapter	Detail
120poug.pdf	Oracle Purchasing User's Guide — Chapter 9: Receiving	Ch. 9: Receiving transactions, accruals, inspections, returns, and receiving options
120poug.pdf	Oracle Purchasing User's Guide — Ch. 1: Defining Receiving Options	pp. 1-41 to 1-45: Receipt routing, tolerance, and accrual method setup
120apug.pdf	Oracle Payables User's Guide — Ch. 3: Matching to Receipts	pp. 3-36 to 3-37: Receipt matching hold resolution when RCV data is incomplete

Receiving Diagnostic

Why This Fails — and What It Costs

What This Script Diagnoses

What the Report Looks Like

The Four-Layer Architecture in PO-03

Backup & Rollback for PO-03

Tables Backed Up — PO-03

Pre-Flight Safety Guards

FIX_BACKUP_REGISTRY Entry

Auto-Generated Knowledge Base Article

What This Script Finds

QUANTITY RECEIVED Hold — Short Receipt

Unordered Receipt Not Matched

Receipt Exceeds PO Quantity

Inspection Required — Not Completed

Tables Examined

How Every Fix Decision Is Made

Nothing Executes Without a Safety Net

Every Execution Produces a Record

Oracle Documentation References

Ready to Resolve This in Your Environment?

Why This Fails — and What It Costs

What This Script Diagnoses

What the Report Looks Like

The Four-Layer Architecture in PO-03

Backup & Rollback for PO-03

Tables Backed Up — PO-03

Pre-Flight Safety Guards

FIX_BACKUP_REGISTRY Entry

Auto-Generated Knowledge Base Article

What This Script Finds

QUANTITY RECEIVED Hold — Short Receipt

Unordered Receipt Not Matched

Receipt Exceeds PO Quantity

Inspection Required — Not Completed

Tables Examined

How Every Fix Decision Is Made

Nothing Executes Without a Safety Net

Every Execution Produces a Record

Oracle Documentation References

Related Diagnostic Scripts

Purchase Order Diagnostic

PO Period Close Readiness

PO Matching Tolerance Analysis

Inventory Transaction Diagnostic

Ready to Resolve This in Your Environment?