Search Results iby_ext_bankacct_validations




Overview
Explore in AI Chat

Overview

The APPS.IBY_EXT_BANKACCT_VALIDATIONS package body is a PL/SQL component within the Oracle Payments (IBY) module of Oracle E-Business Suite. Its principal business function is to centralize the validation logic applied to external bank accounts — that is, bank accounts belonging to suppliers, customers, employees, or other trading partners that are maintained outside the internal treasury model. In Oracle EBS 12.1.1 and 12.2.2, external bank account records are held in the IBY_EXT_BANK_ACCOUNTS table and exposed through the IBY_EXT_BANK_ACCOUNTS_V view, and any process that creates or updates these records must confirm that the account data is structurally and semantically valid before it is persisted and used for payment processing.

The package acts as an internal validation layer called by the public external bank account API IBY_EXT_BANKACCT_PUB. It coordinates validation services drawn from Oracle Receivables (CE_BANK_AND_ACCOUNT_VALIDATION, CE_VALIDATE_BANKINFO), Oracle Trading Community Architecture (HZ_BANK_PUB, HZ_PARTY_V2PUB), and the common payments infrastructure (IBY_FNDCPT_COMMON_PUB, IBY_SECURITY_PKG), while using FND_API, FND_MESSAGE, and FND_MSG_PUB to raise and propagate user-facing errors in a consistent API style.

Key Procedures and Functions

The documented metadata for release 12.2.2 identifies two callable units within this package:

  • IBY_VALIDATE_ACCOUNT — The primary validation routine. It accepts external bank account attributes and applies the full body of validation rules: check digit and account number format checks, bank and branch identifier verification, account currency validation, and party/organization consistency checks. When a rule fails, the routine reports the failure through the FND message stack so that the calling API can roll back the transaction and return a structured error to the user or integration.

The package additionally references itself (IBY_EXT_BANKACCT_VALIDATIONS) as a dependency, indicating that the validation logic is modularized across sibling procedures or functions inside the same body that are invoked internally by the public validation entry point.

Tables Accessed

The package reads data from the following documented tables, all accessed through APPS synonyms:

  • IBY_EXT_BANK_ACCOUNTS — The base table of external bank account records. The validation routines inspect existing rows to determine whether an account already exists and to compare submitted values against stored values during updates.
  • HZ_PARTIES — Confirms that the party owning the bank account exists and is in a valid state within the Trading Community model.
  • HZ_ORGANIZATION_PROFILES — Retrieves organization-level attributes for the owning party, which are required when validating account holders that are organizations rather than persons.
  • FND_CURRENCIES — Verifies that the currency assigned to the bank account is enabled and valid, and supplies currency-related attributes used in account validation.

Usage Notes

This package body is not intended to be called directly by end users. It is invoked indirectly whenever an external bank account is created or modified through supported EBS paths, including the supplier and customer bank account setup forms, the Payments Manager external account pages, and automated inbound interfaces such as those used by supplier or customer data conversion. Integration developers building custom interfaces against IBY_EXT_BANKACCT_PUB receive this validation behavior automatically because the public API delegates to this package.

Direct invocation from custom code is discouraged. Because the package depends on HZ_BANK_PUB, CE_VALIDATE_BANKINFO, and IBY_FNDCPT_COMMON_PUB, any custom caller must ensure the appropriate TCA and Receivables setup — bank and branch records, party records, and currency definitions — is complete before validation can succeed. Error conditions are surfaced through the FND message stack rather than raised exceptions alone, so calling code should always inspect FND_MSG_PUB after a failed validation call. Metadata indicates the package is referenced by two other database objects, consistent with its role as a shared internal validation service rather than a standalone API.