Search Results check_match_exists
Overview
PO_MULTI_MOD_VALIDATIONS is an Oracle E-Business Suite PL/SQL package owned by the APPS schema that supports the multi-modification (mass update) feature of Oracle Purchasing. Its principal business role is to evaluate proposed changes against a set of purchasing documents, header, line, shipment, and supplier attributes, and to return a consolidated validation result that indicates whether a change can be applied, applies with warning, or must be rejected. The package declares an AUTHID CURRENT_USER interface and defines four global result-type constants: FATAL, FAILURE, WARNING, and SUCCESS, together with rank variables (g_result_type_rank_FATAL, g_result_type_rank_SUCCESS) used to order and compare severity.
The object name associated with the user's search, PO_MULTI_MOD_VAL_RESULTS_TYPE, corresponds to the validation-result structure that this package's logic populates and surfaces through the PO_MULTI_MOD_VAL_RESULTS table and related result collections. The package therefore sits at the heart of the multi-modification validation engine: it determines which documents are affected, applies the individual validation rules, records results, and drives the severity ranking that callers use to decide whether to proceed.
Key Procedures and Functions
The documented interface contains 36 procedures and functions. The change-detection functions, HAS_ADDRESS_CHANGED, HAS_CLAUSE_CHANGED, and HAS_VENDOR_CHANGED, inspect a supplied request and change identifiers to determine, respectively, whether address, contract clause, or supplier data was modified. These results inform downstream validations.
The invoice-oriented functions UNPAID_INVOICES_EXISTS, UNVAL_INVOICES_EXISTS, CHECK_MATCH_EXISTS, and GET_INVOICE_ID interrogate AP data to detect unpaid, unvalidated, or matched invoices associated with a purchasing document, since a supplier or document change may be blocked when such invoices exist.
The procedures UNMTCH_INV_FOR_VNDR_EXISTS, PREPD_INV_FOR_VNDR_EXISTS, and PARTPD_INV_FOR_VNDR_EXISTS, added or revised under bug13084712, populate output collections listing unmatched, prepaid, and partially paid invoices for a vendor, providing actionable detail to the user.
VALIDATE_MULTI_MOD and VALIDATE_SET are the driver routines that apply the rule set across the selected documents and aggregate the highest-severity outcome. ATLEAST_ONE_DOC_SELECTED enforces that at least one document is chosen. EXEMPTION_REASON_GIVEN, NEW_VENDOR_CONTACT_PROVIDED, VENDOR_NAME_CHG_VALID, NEW_VENDOR_ON_HOLD, VENDOR_CHG_VALID, NO_OF_COPIES_GE_ZERO, and ACCEPTANCE_DUE_DATE_VALID implement individual attribute-level checks on the proposed change payload.
Tables Accessed
The package reads and writes purchasing tables through APPS synonyms: PO_HEADERS_ALL, PO_HEADERS_ALL_EXT_B, PO_LINES_ALL, and PO_LINE_LOCATIONS_ALL supply document, line, and shipment context; PO_MULTI_MOD_REQUESTS, PO_MULTI_MOD_CHANGES, PO_MULTI_MOD_CLAUSE_CHANGES, and PO_MULTI_MOD_DOCS store the pending multi-modification request and its scope, including clause changes and selected documents. PO_MULTI_MOD_VAL_RESULTS persists the computed validation outcomes and is the table behind the result-type structure. PO_DRAFTS, PO_ENTITY_LOCKS, and PO_DOC_STYLE_HEADERS support draft handling, concurrency locking, and document-style configuration. On the payables side, AP_INVOICES_ALL, AP_INVOICE_LINES_ALL, and AP_PAYMENT_SCHEDULES_ALL provide the invoice, invoice-line, and payment-schedule evidence used by the invoice-existence checks.
Usage Notes
PO_MULTI_MOD_VALIDATIONS is invoked from the Multi-Modification/Mass Update flows in Oracle Purchasing, in which users select multiple purchase orders or agreements and propose coordinated changes. The ordering form submits the request, calls the driver validations, and renders the PO_MULTI_MOD_VAL_RESULTS rows, using the FATAL/WARNING/SUCCESS ranking to highlight blocking errors and advisories. The package is also callable from concurrent programs or custom PL/SQL that reproduces the same mass-update validation, provided callers pass the request identifier and change identifier collections expected by the routines. It is referenced by zero other packages in the documented metadata, so it functions as a self-contained validation library rather than a shared utility. Customizations should honor the AUTHID CURRENT_USER semantics and the global result-type constants when interpreting returned results.