Search Results insert_transaction_errors




Overview
Explore in AI Chat

Overview

IBY_VALIDATIONSETS_PUB is the public validation engine for Oracle Payments (IBY) in Oracle E-Business Suite 12.1.1 and 12.2.2. Its core responsibility is to evaluate the validation sets configured against payment documents, payment instructions, and payment service requests, and to enforce the business rules that determine whether a payment transaction may proceed. The package exposes a record structure, documentRecType, that captures all document-level fields requiring validation, drawn from the IBY_DOCS_PAYABLE_ALL entity and related banking reference views. This structure carries calling application identifiers, document amounts, payment currency, delivery channel, settlement priority, remittance messages, and internal bank and branch attributes used for routing and account checks.

The package header ships as ibyvalls.pls (version 120.18) and holds the published signature used by callers across the Payments subsystem. It is referenced by thirteen other packages, confirming its role as a shared validation service rather than a private implementation detail.

Key Procedures and Functions

The 31 documented procedures and functions naturally group into initialisation, validation, error handling, and field lookup routines.

  • Initialisation routines: INITDOCUMENTDATA, INITCHARVALDATA, INITPAYMENTDATA, and INITINSTRUCTIONDATA populate the working data structures for document-, characteristic-, payment-, and instruction-level validation respectively.
  • Validation drivers: APPLYDOCUMENTVALIDATIONSETS applies the configured validation set rules, while PERFORMONLINEVALIDATIONS performs the same checks interactively for real-time scenarios such as form entry.
  • Error handling: INSERT_TRANSACTION_ERRORS and INSERTINTOERRORTABLE record validation failures. INSERT_TRANSACTION_ERRORS is the routine most frequently sought by developers, as it writes failures into the transaction error framework with associated tokens. FAILRELATEDDOCS, FAILALLDOCSFORPAYEE, FAILALLAWTDOCS, and FAILALLDOCSFORREQUEST cascade failure status to affected documents at varying scopes.
  • Condition and field resolution: EVALUATECONDITION, GETPARAMVALUE, GETDOCUMENTFIELDVALUE, GETPAYMENTFIELDVALUE, and GETINSTRUCTIONFIELDVALUE resolve validation conditions and retrieve the actual values being tested.
  • Request and event handling: GETREQUESTATTRIBUTES retrieves payment service request context, RAISEBIZEVENTS emits business events, and PERFORMDBUPDATES applies the resulting database changes.

Tables Accessed

The package reads and writes IBY_DOCS_PAYABLE_ALL, IBY_DOCUMENT_LINES, IBY_PAYMENTS_ALL, IBY_PAY_INSTRUCTIONS_ALL, and IBY_PAY_SERVICE_REQUESTS as its primary transactional sources. Validation failures are persisted to IBY_TRANSACTION_ERRORS, with supplementary detail held in IBY_TRXN_ERROR_TOKENS. Banking and party data are drawn from CE_BANK_ACCOUNTS, CE_BANK_BRANCHES_V, HZ_PARTIES, HZ_PARTY_SITES, and HZ_LOCATIONS. Payee and payer definitions come from IBY_EXTERNAL_PAYEES_ALL and IBY_INTERNAL_PAYERS_ALL, while IBY_DELIVERY_CHANNELS_B supplies channel configuration. FND_NEW_MESSAGES supports message resolution for error text.

Usage Notes

IBY_VALIDATIONSETS_PUB is normally invoked indirectly. During payment processing, the Payments engine calls APPLYDOCUMENTVALIDATIONSETS to execute the validation sets attached to a payment process profile. In Oracle Payments forms and setup flows, PERFORMONLINEVALIDATIONS provides immediate feedback to users. When validation fails, INSERT_TRANSACTION_ERRORS is called to write the failure and its tokens into IBY_TRANSACTION_ERRORS for downstream review in the transaction error UI and for automated retry or correction workflows.

Because the package is classified as PUBLIC and is referenced by thirteen sibling packages, custom extensions should call the documented entry points rather than duplicating validation logic. Developers building corrective or diagnostic utilities commonly target INSERT_TRANSACTION_ERRORS to raise or clear errors against existing documents, but should ensure the accompanying token rows in IBY_TRXN_ERROR_TOKENS remain consistent. Direct DML against IBY_TRANSACTION_ERRORS is not recommended, since error propagation flags on related documents are maintained by the FAIL* routines and by PERFORMDBUPDATES.