Search Results iby_completed_pmts_group_s




Overview
Explore in AI Chat

Overview

IBY_VALIDATIONSETS_CALLS_PUB is a public PL/SQL package body in the APPS schema that implements the validation-set invocation framework within Oracle Payments (IBY). Its central role is to execute payment validation sets and their associated validation rules against payment transactions, payees, documents payable, and pay instructions before those transactions are released to a payment system. The package functions as the runtime engine that bridges the metadata stored in IBY_VALIDATIONSETS_PUB and the validation values and assignments maintained in the setup tables. It evaluates configured validation logic—ranging from bank account verification to country-specific electronic funds transfer (EFT) formatting rules—and records any violations as transaction errors.

The package derives much of its behavior from a set of internal routines named after specific banks, countries, and payment formats. Names such as CITI_AT_EFT_DOM_PAYEE, CITI_BE_EFT_DOM_PMT, CITI_CH_EFT_DOM_DOC, and CITI_DE_EFT_DOM_PAYEE indicate that the body encapsulates country-specific and financial-institution-specific validation logic, particularly for European domestic EFT payments. These routines evaluate whether a payee, payment, instruction, or document conforms to the expected format and data requirements for that institution or country.

Key Procedures and Functions

The documented package exposes 127 procedures and functions, the majority of which are internal validation routines invoked during payment processing rather than directly by end users. Representative entries include CITI_AT_EFT_DOM_PAYEE, CITI_AT_EFT_DOM_DOC, CITI_BE_EFT_DOM_PAYEE, P_CITI_BE_EFT_DOM_PMT, CITI_CH_EFT_DOM_PAYEE, CITI_CH_EFT_DOM_DOC, P_CITI_CH_EFT_DOM_PMT, CITI_DE_EFT_DOM_PAYEE, CITI_DE_EFT_DOM_DOC, and DE_EFT_DOM_INTERNAL_BANK. The naming convention follows a pattern of institution or country, payment method, scope (domestic), and target object (payee, document, payment, internal bank, or instruction).

The AT_EFT_INT_* series (AT_EFT_INT_INTERNAL_BANK, AT_EFT_INT_PAYER, AT_EFT_INT_PAYEE) and the BE_EFT_INT_* series (BE_EFT_INT_PAYEE, BE_EFT_INT_DOC, P_BE_EFT_INT_PMT, I_BE_EFT_INT_INSTR) address intermediate or internal payment structures. Routines prefixed with P_ or I_ typically serve as wrapper procedures that assemble or persist the results of the underlying checks. This structure allows the package to support a broad matrix of country and bank combinations without duplicating core evaluation logic.

Tables Accessed

The package reads and writes several IBY and shared application tables. IBY_VALIDATION_SETS_VL, IBY_VALIDATION_PARAMS_VL, IBY_VALIDATION_VALUES, and IBY_VAL_ASSIGNMENTS supply the validation configuration, parameters, permissible values, and rule assignments that drive execution. Payment data is drawn from IBY_PAYMENTS_ALL, IBY_DOCS_PAYABLE_ALL, IBY_PAY_INSTRUCTIONS_ALL, and IBY_EXTERNAL_PAYEES_ALL. Bank verification uses CE_BANK_ACCOUNTS and CE_BANK_BRANCHES_V, while payee contact details come from HZ_CONTACT_POINTS.

Validation failures are persisted to IBY_TRANSACTION_ERRORS, IBY_TRANSACTION_ERRORS_S (the sequence), and IBY_TRXN_ERROR_TOKENS. Message text is resolved through FND_NEW_MESSAGES and FND_MESSAGE, logging via FND_LOG, and environment context via FND_GLOBAL. The package also depends on IBY_COMPLETED_PMTS_GROUP_S, IBY_BUILD_UTILS_PKG, IBY_VALIDATIONSETS_PUB, and AP_PMT_VALIDATIONS_PKG, and it references DUAL and PLITBLM. Notably, IBY_COMPLETED_PMTS_GROUP_S is the sequence associated with the completed payment groups table referenced in the user’s search.

Usage Notes

This package is invoked programmatically during payment instruction building and validation, typically triggered when a payment process request or payment instruction is validated before formatting. It is called by Oracle Payments internal processes and may be referenced from concurrent programs or custom extensions that must enforce the same validation rules. Because it tracks errors by transaction token, callers should ensure that the relevant transaction records exist and that the calling context establishes FND_GLOBAL application and session identifiers. The package is not referenced by any database object other than through this dependency chain, confirming that it is an internal execution component rather than a standalone API.