PO-01: Purchase Order Diagnostic

Oracle EBS Purchase Order failures span the entire PO lifecycle — from the moment a buyer creates a standard PO in PO_HEADERS_ALL through approval, receiving, and final closure. The most operationally disruptive PO issues are those that block the downstream AP invoice matching process: a PO line that has been fully received but still shows OPEN status, a PO that was approved but whose authorization status reverted to IN PROCESS due to a workflow error, or a PO distribution with a disabled GL account that blocks both the encumbrance entry and the eventual AP distribution match.

PO approval status inconsistencies are the primary source of downstream AP holds. When a PO is approved in Oracle, PO_HEADERS_ALL.AUTHORIZATION_STATUS is set to APPROVED and the workflow item in WF_ITEMS is closed. If the workflow engine stalls after marking the PO approved but before closing the workflow item cleanly, the PO may show APPROVED in the buyer screen but have an orphaned workflow item that prevents re-approval, amendment, or cancellation. AP invoices matched to this PO will hold at validation because the PO approval status cannot be re-confirmed by the matching engine.

PO closure conditions are the second major complexity area. Oracle EBS automatically closes PO lines when the billed quantity reaches the ordered quantity (bill-close tolerance) or when the received quantity reaches the ordered quantity (receive-close tolerance). When these tolerances are configured incorrectly — or when a PO line was manually forced closed before all invoices were matched — AP invoices attempting to match against the closed line receive a PO_CLOSED hold that cannot be released without reopening the line. PO-01 checks closure status and tolerance configuration against the actual received and billed quantities.

PO-01 runs a complete purchase order diagnostic — header authorization status and workflow state, line status by type (STANDARD, BLANKET, CONTRACT), distribution account validity across all distribution lines, shipment receipt status vs ordered quantity, invoice matching status and any active AP holds, encumbrance balance vs PO commitment, and closure tolerance configuration against actual received and billed quantities.

Header & Authorization

PO_HEADERS_ALL authorization status, PO type, operating unit, and workflow item state. Distinguishes between APPROVED, IN PROCESS, REQUIRES REAPPROVAL, and INCOMPLETE statuses.

Line & Shipment Status

PO_LINES_ALL and PO_LINE_LOCATIONS_ALL status by line type — STANDARD, BLANKET, CONTRACT. Closure status vs received and billed quantities. Tolerance configuration analysis.

Distribution Integrity

PO_DISTRIBUTIONS_ALL CCID validity for all distribution lines. Encumbrance account active status. Distribution amount vs line amount reconciliation.

AP Matching Status

AP invoices matched to the PO — hold types and hold reasons. Matched quantity vs billed quantity vs received quantity. PO_CLOSED, QUANTITY ORDERED, and PRICE hold identification.

Encumbrance Balance

GL_BC_PACKETS encumbrance balance vs PO commitment amount. Identifies encumbrance relief status as invoices are matched and paid. Flags variances between the PO amount and the encumbrance balance.

════════════════════════════════════════════════════════════
  ORACLE EBS R12 — PURCHASE ORDER DIAGNOSTIC
════════════════════════════════════════════════════════════
  PO Number          : PO-2026-004481
  Supplier           : Acme Technology Solutions
  Operating Unit     : US Primary OU
  Case Number        : PO-481022
  Report Date        : 20-FEB-2026 10:15:33
════════════════════════════════════════════════════════════

[ SECTION 1 — HEADER STATUS ]               STATUS: ✓ APPROVED
────────────────────────────────────────────────────────────
  Authorization      : APPROVED ✓
  PO Status          : OPEN ✓
  Workflow Item      : PO_APPROVAL — COMPLETE ✓

[ SECTION 2 — LINE STATUS ]                 STATUS: ✗ ISSUE
────────────────────────────────────────────────────────────
  Line 1 — Laptops   : Qty 50 ordered, 50 received, 48 billed
  Line 1 Status      : CLOSED — closed before final 2 invoices matched ✗
  Line 2 — Monitors  : Qty 30 ordered, 30 received, 30 billed — CLOSED ✓
  ✗ FAIL: Line 1 closed — 2 unmatched AP invoices will receive PO_CLOSED hold

[ SECTION 3 — DISTRIBUTIONS ]               STATUS: ✓ PASS
────────────────────────────────────────────────────────────
  All 3 distribution CCIDs active ✓

[ SECTION 4 — AP MATCHING STATUS ]          STATUS: ✗ FAIL
────────────────────────────────────────────────────────────
  Invoices on Hold   : 2 invoices — PO_CLOSED hold ✗
  Invoice 1          : INV-2026-00881 — $12,400 — PO_CLOSED hold
  Invoice 2          : INV-2026-00882 — $12,400 — PO_CLOSED hold

[ SECTION 5 — ENCUMBRANCE ]                 STATUS: ✓ PASS
────────────────────────────────────────────────────────────
  Encumbrance balance matches PO commitment ✓

════════════════════════════════════════════════════════════
  DIAGNOSTIC SUMMARY
════════════════════════════════════════════════════════════
  1 blocking condition: PO Line 1 closed prematurely
  FIX: Reopen PO Line 1 — 2 AP invoices will release from PO_CLOSED hold
════════════════════════════════════════════════════════════
  Backup Created  : CONS_BACKUP.PO_LINE_LOCATIONS_ALL_481022 ✓
  Registry ID     : 6041
════════════════════════════════════════════════════════════

KB-PO-481022-001 · Script: PO-01

PO-2026-004481 Line 1 Closed Prematurely — 2 AP Invoices on PO_CLOSED Hold

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

Symptom

PO-2026-004481 Line 1 (50 Laptops) closed before the final 2 AP invoices (INV-2026-00881, INV-2026-00882, $24,800 total) were matched. Both invoices placed on PO_CLOSED hold at AP validation.

Root Cause

PO Line 1 was manually closed by the buyer on 18-FEB-2026 after confirming physical receipt of all 50 units. The buyer was not aware that 2 of the 50 invoice lines had not yet been received into AP from the supplier portal. The receive-close tolerance was set to 100% — manual close overrode the tolerance logic.

Tables Affected

PO_LINE_LOCATIONS_ALL — CLOSED_CODE = CLOSED (PO-2026-004481 Line 1, Shipment 1)
AP_HOLDS_ALL — HOLD_LOOKUP_CODE = PO_CLOSED (INV-2026-00881, INV-2026-00882)

Fix Applied

PO_LINE_LOCATIONS_ALL.CLOSED_CODE set to OPEN with full backup. PO-01 reconfirmed 48 of 50 units billed — line correctly shows OPEN. Both AP invoices released from PO_CLOSED hold on revalidation.

Prevention

Buyers should not manually close PO lines until AP confirms all invoices have been matched. PO-01 pre-close check should be added to the procurement period-close checklist.

PO Line Closed — AP Invoices on Hold

PO line manually closed before all AP invoices were matched. Outstanding invoices receive PO_CLOSED hold at validation. PO-01 confirms remaining unmatched quantity and reopens the line with full backup.

Workflow

Authorization Status Stalled

PO stuck in IN PROCESS or REQUIRES REAPPROVAL. Workflow item exists but has not progressed. PO-01 identifies the stall point and the resubmission path vs Oracle Support escalation.

Account

Distribution CCID Disabled

PO distribution references a disabled GL account — blocks both the encumbrance entry at approval and the AP distribution match at invoice validation. PO-01 remaps to the active replacement CCID.

Quantity

Over-Receipt or Quantity Mismatch

Received quantity exceeds ordered quantity, or received quantity does not match the supplier's invoice quantity. PO-01 identifies the receipt line and the RTV or correction path.

Table	Module	Purpose
PO_HEADERS_ALL	PO	PO header — authorization status, type, supplier
PO_LINES_ALL	PO	PO lines — item, quantity, unit price
PO_LINE_LOCATIONS_ALL	PO	Shipments — closed code, received/billed qty, tolerances
PO_DISTRIBUTIONS_ALL	PO	Distributions — CCID, encumbrance amount
RCV_SHIPMENT_LINES	PO	Receipt lines — received quantity
AP_HOLDS_ALL	AP	Invoice holds — PO_CLOSED, QUANTITY ORDERED, PRICE
GL_BC_PACKETS	GL	Encumbrance balance packets
WF_ITEMS	WF	PO approval workflow item state
AP_INVOICES_ALL	AP	Invoices matched to PO — validation status
GL_CODE_COMBINATIONS	GL	Distribution CCID active status

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
PO line closed prematurely — AP invoices on PO_CLOSED hold	Direct Fix	PO-01 sets CLOSED_CODE back to OPEN in PO_LINE_LOCATIONS_ALL with full backup. Pre-flight confirms the billed quantity is still below the ordered quantity before reopening.
Authorization status IN PROCESS — workflow stalled	Functional First	Resubmit PO for approval via Purchasing > Purchase Orders > Approve. PO-01 identifies the workflow item state and confirms whether the stall is recoverable through resubmission.
Orphaned workflow item — APPROVED but WF not closed	Oracle Support	Orphaned WF_ITEMS for PO approval are not directly modifiable. PO-01 documents the item key and activity status for the Oracle Support SR.
Distribution CCID disabled — encumbrance and AP hold	Direct Fix	PO-01 remaps CODE_COMBINATION_ID in PO_DISTRIBUTIONS_ALL to the active replacement CCID with full backup. Both the encumbrance entry and the AP distribution must reference the corrected CCID.
PO quantity over-received — receipt exceeds ordered qty	Functional First	Correct via Return to Vendor transaction in Oracle Receiving. PO-01 identifies the receipt line, over-received quantity, and the RTV navigation path.
PO on payment hold — supplier hold active	Functional First	Release the supplier payment hold via Suppliers > Edit > Payment Details. PO-01 identifies the hold type and the AP invoices blocked by the supplier-level hold.
Encumbrance balance mismatch — GL_BC_PACKETS not reconciled	Direct Fix	PO-01 calculates the encumbrance variance and generates the correcting GL_BC_PACKETS entry with full backup and explicit Controller authorization before execution.
PO in REQUIRES REAPPROVAL after amendment	Functional First	Resubmit for approval via the standard PO approval process. PO-01 identifies which amendment triggered the reapproval requirement and the current approver in the workflow queue.

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.

PO_HEADERS_ALL

PO_LINES_ALL

PO_LINE_LOCATIONS_ALL

PO_DISTRIBUTIONS_ALL

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-01 — Pre-Flight & Backup Verification

════════════════════════════════════════════════════════════
  PRE-FLIGHT SAFETY CHECK
════════════════════════════════════════════════════════════
  PO Number          : PO-2026-004481
  Line 1 Billed Qty  : 48 of 50 — 2 invoices unmatched
  CLOSED_CODE        : CLOSED — safe to reopen (qty < ordered)
  CONS_BACKUP Schema : Accessible ✓
  Session Lock Check : No locks on PO_LINE_LOCATIONS_ALL ✓
────────────────────────────────────────────────────────────
  ALL PRE-FLIGHT CHECKS PASSED
════════════════════════════════════════════════════════════
  Creating : CONS_BACKUP.PO_LINE_LOCATIONS_ALL_481022
  Rows     : 1 row backed up ✓
  Registry : FIX_BACKUP_REGISTRY — ID 6041 created ✓
────────────────────────────────────────────────────────────
  BACKUP COMPLETE
════════════════════════════════════════════════════════════
  Enter case number to confirm : 481022
  Confirmed. Setting CLOSED_CODE = OPEN...
════════════════════════════════════════════════════════════

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-481022-001

PO-2026-004481 Line 1 Closed Prematurely — 2 AP Invoices on PO_CLOSED Hold

EBS R12.2.10 · Purchasing

● RESOLVED

Symptom

PO-2026-004481 Line 1 (50 Laptops) closed before the final 2 AP invoices (INV-2026-00881, INV-2026-00882, $24,800 total) were matched. Both invoices placed on PO_CLOSED hold at AP validation.

Root Cause

Tables

PO_LINE_LOCATIONS_ALL — CLOSED_CODE = CLOSED (PO-2026-004481 Line 1, Shipment 1)
AP_HOLDS_ALL — HOLD_LOOKUP_CODE = PO_CLOSED (INV-2026-00881, INV-2026-00882)

Fix Applied

PO_LINE_LOCATIONS_ALL.CLOSED_CODE set to OPEN with full backup. PO-01 reconfirmed 48 of 50 units billed — line correctly shows OPEN. Both AP invoices released from PO_CLOSED hold on revalidation.

Prevention

Buyers should not manually close PO lines until AP confirms all invoices have been matched. PO-01 pre-close check should be added to the procurement period-close checklist.

R12 Guide (PDF)	Title & Chapter	Detail
120poug.pdf	Oracle Purchasing User's Guide — Chapter 4: Purchase Orders	Ch. 4: Entering POs, distributions, tolerances, and shipment lines
120poug.pdf	Oracle Purchasing User's Guide — Ch. 2: Approval, Security, and Control	Ch. 2: Document status checks, submission checks, and control applicability matrix
120apug.pdf	Oracle Payables User's Guide — Ch. 3: Matching to Purchase Orders	pp. 3-30 to 3-68: Two-way and three-way PO matching and matching hold resolution

Purchase Order Diagnostic

Why This Fails — and What It Costs

What This Script Diagnoses

What the Report Looks Like

The Four-Layer Architecture in PO-01

Backup & Rollback for PO-01

Tables Backed Up — PO-01

Pre-Flight Safety Guards

FIX_BACKUP_REGISTRY Entry

Auto-Generated Knowledge Base Article

What This Script Finds

PO Line Closed — AP Invoices on Hold

Authorization Status Stalled

Distribution CCID Disabled

Over-Receipt or Quantity Mismatch

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-01

Backup & Rollback for PO-01

Tables Backed Up — PO-01

Pre-Flight Safety Guards

FIX_BACKUP_REGISTRY Entry

Auto-Generated Knowledge Base Article

What This Script Finds

PO Line Closed — AP Invoices on Hold

Authorization Status Stalled

Distribution CCID Disabled

Over-Receipt or Quantity Mismatch

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

PO Approval Workflow Diagnostic

Receiving Diagnostic

PO Period Close Readiness

PO Matching Tolerance Analysis

Ready to Resolve This in Your Environment?