ZX_PARTY_TAX_PROFILE — TAX_IDENTIFICATION_NUM (Party: HZ party for vendor 10892)
Complete vendor master health check — active status, site configuration, bank accounts, payment terms, 1099 setup, holds, and duplicate supplier detection across TCA.
Vendor master data problems in Oracle EBS are among the most pervasive and most difficult to diagnose because the vendor record spans four separate Oracle modules — the AP supplier tables, the TCA party model in HZ, the IBY payment instrument tables, and the ZX tax profile. A symptom that presents as a payment failure may have its root cause in a missing IBY bank account assignment. A symptom that presents as a 1099 reporting discrepancy may have its root cause in an incomplete ZX_PARTY_TAX_PROFILE record. The AP team sees the payment error. The Tax team sees the 1099 gap. Neither team has full visibility across the complete vendor record structure.
The most operationally damaging vendor master condition is a vendor placed on hold without a clear release path. Oracle EBS supports multiple hold types at the vendor level — AP_HOLDS_ALL records a hold on an existing invoice, but a vendor-level hold set in AP_SUPPLIERS.HOLD_FLAG blocks all future invoice entry for that vendor across every operating unit. In environments where the AP team and the Purchasing team use different forms, it is common for a vendor hold to be placed by one team and released by another — with neither team realizing the hold persists because it is stored in a different field than the one they checked.
Duplicate vendor records compound the problem. When the same supplier exists under two or more AP_SUPPLIERS records — often created because the Purchasing team created a new vendor rather than searching for the existing one — invoices accumulate against both records. 1099 reportable amounts are split between them, neither reaching the reporting threshold individually, resulting in missed filings and potential IRS penalties. Vendor merge is the correct resolution, but it requires identifying all transactions referencing both vendor IDs across AP, PO, and potentially FA and PA before the merge is executed.
AP-03 examines the complete vendor record — header status and hold flags, all vendor sites across operating units, bank account existence and active status in IBY, payment terms and pay group configuration, 1099 type and Federal Tax ID completeness, and duplicate detection by name similarity, bank account, and tax ID. It identifies every condition that will block invoice entry, payment processing, or correct tax reporting — and provides the exact resolution path for each one.
AP-03 systematically investigates every major condition that can cause the issue this diagnostic targets. Below is the complete coverage breakdown.
Representative output showing the diagnostic running against a real-world scenario. The script identifies every condition, states the root cause, and generates the fix.
════════════════════════════════════════════════════════════
ORACLE EBS R12 — SUPPLIER HEALTH DIAGNOSTIC
════════════════════════════════════════════════════════════
Vendor ID : 10892
Vendor Name : Pacific Rim Consulting LLC
Operating Unit : US West OU
Case Number : 834291
Report Date : 21-FEB-2026 11:45:03
════════════════════════════════════════════════════════════
[ SECTION 1 — VENDOR HEADER STATUS ] STATUS: ✗ FAIL
────────────────────────────────────────────────────────────
Vendor Active : YES ✓
Vendor Hold Flag : Y ✗ — Vendor on hold
Hold Type : PAYMENT
Hold Set By : JSMITH
Hold Date : 15-JAN-2026
✗ FAIL: Vendor hold blocking all invoice entry and payment
Fix : Suppliers > Entry > Hold: set to N after dispute resolution
[ SECTION 2 — VENDOR SITES ] STATUS: ⚠ WARNING
────────────────────────────────────────────────────────────
Total Sites : 3
US-PRIMARY : ACTIVE — Pay Site ✓
US-REMIT : ACTIVE ✓
US-OLD : INACTIVE — has 2 open invoices ⚠
⚠ WARNING: Inactive site US-OLD referenced by open invoices
[ SECTION 3 — BANK ACCOUNT ] STATUS: ✓ PASS
────────────────────────────────────────────────────────────
Bank Account : Wells Fargo x7821 — ACTIVE ✓
Payment Method : EFT ✓
[ SECTION 4 — 1099 SETUP ] STATUS: ✗ FAIL
────────────────────────────────────────────────────────────
1099 Type : MISC
Federal Tax ID : MISSING ✗
YTD Reportable Amt : $48,200.00
✗ FAIL: Federal Tax ID missing — 1099 reporting will fail at year-end
[ SECTION 5 — DUPLICATE DETECTION ] STATUS: ⚠ WARNING
────────────────────────────────────────────────────────────
⚠ Possible duplicate: Vendor 10445 'Pacific Rim Consulting' — same tax ID
════════════════════════════════════════════════════════════
DIAGNOSTIC SUMMARY
════════════════════════════════════════════════════════════
3 conditions require resolution before vendor is fully operational
1. Release vendor hold (PAYMENT) — contact JSMITH for authorization
2. Add Federal Tax ID to vendor tax profile
3. Review duplicate vendor 10445 for merge
════════════════════════════════════════════════════════════
Every table touched by AP-03 data fixes is backed up before the first UPDATE fires. Backup is verified by row count. One script restores the original state if needed.
Backup happens before any DML. Script aborts if backup creation fails.
This article is produced automatically at the end of every AP-03 execution — written from actual run output. No manual documentation required.
Vendor has an active hold preventing invoice entry or payment. AP-03 identifies the hold type, who placed it, the date, and the release navigation path.
Vendor site has no active bank account assigned — blocking EFT payments. AP-03 identifies missing bank setup and provides the TCA party bank account navigation path.
1099 vendor does not have a Federal Tax ID populated. AP-03 flags the vendor, current reportable amount YTD, and the setup correction path.
Same vendor appears under two or more supplier records. AP-03 identifies matches by name similarity, bank account, or tax ID and flags for supplier merge review.
| Table / View | Schema | Purpose in Diagnostic |
|---|---|---|
| AP_SUPPLIERS | AP | Vendor header — active status, hold, tax ID |
| AP_SUPPLIER_SITES_ALL | AP | Vendor sites — active status, OU, payment terms |
| IBY_EXT_BANK_ACCOUNTS | IBY | Vendor bank accounts |
| HZ_PARTIES | HZ | TCA party records for duplicate detection |
| HZ_PARTY_SITES | HZ | Party site addresses |
| AP_HOLDS_ALL | AP | Vendor-level holds |
| PO_VENDORS | PO | Legacy vendor view |
| IBY_PMT_INSTR_USES_ALL | IBY | Payment instrument assignments |
| ZX_PARTY_TAX_PROFILE | ZX | Tax profile for 1099 setup |
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.
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.
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:
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_EVENTS, XLA_AE_HEADERS — incorrect changes corrupt the subledger audit trail in ways undetectable until period close fails or an auditor requests a reconciliationWF_ITEMS, WF_ITEM_ACTIVITY_STATUSES — ad-hoc DML can corrupt the workflow engine state instance-wideA 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.
| Condition Identified | Resolution Path | Notes |
|---|---|---|
| Vendor hold flag set — blocking all invoice entry | Functional First | Release via Suppliers > Entry > set HOLD_FLAG to N. AP-03 identifies who set the hold, when, and the hold type so authorization can be obtained before release. |
| Inactive vendor site referenced by open invoices | Functional First | Reactivate the site via Suppliers > Sites if still valid, or transfer open invoices to the correct active site via invoice correction. AP-03 identifies all invoices referencing the inactive site. |
| Missing Federal Tax ID on 1099 vendor | Functional First | Enter the Federal Tax ID in Oracle E-Business Tax > Party Tax Profiles for the TCA party linked to the vendor. AP-03 identifies the HZ_PARTY_ID and the navigation path. |
| No active bank account — EFT payments will fail | Functional First | Create or reactivate the bank account in IBY_EXT_BANK_ACCOUNTS via Suppliers > Banking. AP-03 identifies whether the account exists but is inactive, or is missing entirely. |
| Prenote status FAILED — EFT prenote rejected by bank | Direct Fix | AP-03 resets IBY_EXT_BANK_ACCOUNTS.PRENOTE_STATUS to SENT with full backup, allowing a new prenote cycle to initiate on the next payment run. |
| Duplicate vendor detected — same tax ID or bank account | Functional First | Duplicate vendor merge must be initiated via Purchasing > Suppliers > Merge. AP-03 identifies all transactions referencing both vendor IDs to validate merge safety before execution. |
| Pay group invalid or not assigned | Functional First | Assign a valid pay group via Suppliers > Entry > Payment Details. AP-03 identifies the current pay group value and valid options from AP_LOOKUP_CODES. |
| Vendor site OU assignment missing | Functional First | Add the operating unit assignment via Suppliers > Sites > Operating Units. AP-03 identifies which OUs are missing the site assignment based on open POs and invoices. |
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.
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.
INSERT from the backup table. No reconstruction required.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.
| R12 Guide (PDF) | Title & Chapter | Detail |
|---|---|---|
| 120apug.pdf | Oracle Payables User's Guide — Chapter 2: Suppliers | Ch. 2: Supplier setup, supplier holds, payment information, and supplier merge program |
| 120apug.pdf | Oracle Payables User's Guide — Ch. 2: Reviewing and Adjusting Suppliers | pp. 2-33 to 2-46: Identifying duplicate suppliers, supplier merge, and supplier audit report |
| 120funmo.pdf | Oracle Applications Multiple Organizations Implementation Guide | Ch. 2: Operating unit partitioning of supplier data for access control escalations |
AP-03 is one of 65 diagnostic scripts covering every major Oracle EBS and Fusion module. William A. Green Consulting runs the script in your environment, applies guided data fixes, and builds the knowledge base that prevents the same issues from recurring.
See this script run autonomously — Oracle AI Platform →