Search Results ap_duplicate_vendors




Overview
Explore in AI Chat

Overview

AP_DUPLICATE_VENDORS_PKG is a PL/SQL package in the APPS schema that supports the Oracle Payables vendor deduplication and merge process. It provides the low-level data access layer for the AP_DUPLICATE_VENDORS table, which stores the working set of candidate duplicate supplier records identified during the Supplier Merge execution. When a Payables user runs the Supplier Merge program to consolidate duplicate vendor entries, the process must track which vendor and vendor site combinations are being evaluated, how many unpaid and paid invoices are attached to each side of the merge, how many purchase order headers will be reassigned, and the monetary value of the affected transactions. This package encapsulates the inserts, updates, locks, and deletes required to maintain that tracking data. The header comment indicates a last revision of version 120.3 dated 2004, reflecting a stable, long-lived object that has been carried forward unchanged through the 12.1.1 and 12.2.2 releases.

Key Procedures and Functions

The package exposes four documented procedures that form a complete CRUD interface over the AP_DUPLICATE_VENDORS record:

  • INSERT_ROW — Creates a new row in AP_DUPLICATE_VENDORS. It accepts the full column set for the table, including entry identifier, vendor and duplicate vendor identifiers, vendor site and duplicate vendor site identifiers, counts of unpaid and paid invoices, counts of changed purchase order headers, monetary totals for unpaid and paid invoices, the processing flags (process_flag, process, keep_site_flag, paid_invoices_flag), organizational context, and standard WHO audit columns. It returns the new ROWID through an IN OUT NOCOPY parameter. The body uses a cursor keyed on entry_id to detect a pre-existing row for the same entry before insertion, and it builds a calling sequence string for error tracing.
  • LOCK_ROW — Acquires a row-level lock on a specific AP_DUPLICATE_VENDORS record, serializing concurrent access during merge processing.
  • UPDATE_ROW — Modifies an existing AP_DUPLICATE_VENDORS row, used to advance processing flags, refresh invoice or PO counts, and record updated audit information as the merge proceeds.
  • DELETE_ROW — Removes a row from AP_DUPLICATE_VENDORS, typically after the merge has completed or the candidate entry is no longer required.

Tables Accessed

The only table referenced by this package, resolved through an APPS synonym, is AP_DUPLICATE_VENDORS. This is the package's private transactional table and holds one row per duplicate vendor or site pairing under consideration. All fields manipulated by INSERT_ROW and UPDATE_ROW map directly to its columns: the vendor and site identifiers on both the surviving and duplicate side, invoice and purchase order aggregate counters, amount columns used to summarize financial exposure, and the process, keep-site, and paid-invoice flags that drive merge behavior. No other base tables or views are touched by this package; enrichment of vendor data and the actual merge of invoice and PO records are handled by other components in the Supplier Merge flow.

Usage Notes

AP_DUPLICATE_VENDORS_PKG is not a public API and is not intended for direct invocation by external or customer-written code. The ETRM classification lists it as OTHER, and it is referenced by zero other packages in the documented dependency graph, indicating that calls originate from Oracle-supplied internal logic, most commonly the merge processing code invoked by the Supplier Merge concurrent program and its associated forms-based review screens. Because the package is a thin persistence layer over a single table, customizations that need to read or manipulate duplicate vendor candidates should query AP_DUPLICATE_VENDORS directly rather than calling these procedures, and should observe the same WHO audit and ORG_ID conventions used here. Any direct writes should coordinate with the locking behavior exposed by LOCK_ROW to avoid conflicts with a concurrently running merge. Given the age of the header revision, behavior should be considered consistent across 12.1.1 and 12.2.2, though the surrounding Suppler Merge functionality was enhanced in later releases via Oracle's supplier data model changes.