Search Results iban_validation_pkg




Overview

IBAN_VALIDATION_PKG is an Oracle E-Business Suite PL/SQL package body owned by the APPS schema that provides International Bank Account Number (IBAN) validation logic within the HR/payroll data model. IBANs are standardized alphanumeric account identifiers used for cross-border payments under the ISO 13616 standard, consisting of a two-character country code, two check digits, and a country-specific Basic Bank Account Number (BBAN) of up to thirty characters. The package supplies the business rule enforcement required to confirm that a supplier, employee, or third-party bank account recorded in Oracle EBS conforms to the IBAN structure before it is transmitted to a payment system or stored against a party record.

The package is classified as OTHER in the ETRM metadata, indicating it is a supporting utility package rather than a public integration API. Its header comment references the source file peribanval.pkb, confirming that the object resides in the Oracle Human Resources (PER) product family. The package declares a user-defined exception, hr_application_error, initialized to error number -20001 through a PRAGMA EXCEPTION_INIT directive. This is the same error-number range commonly used by Oracle HRMS PL/SQL packages to raise application errors through the standard HR_API error-handling mechanism, and it is the term that led to the original search.

Key Procedures and Functions

  • GET_ACC_LENGTH — Returns the expected IBAN account length for a supplied lookup code. The function queries HR_LOOKUPS for the lookup type IBAN_ACC_LOOKUP and returns the DESCRIPTION value associated with the matching lookup code. A local cursor is opened only when the lookup code parameter is not null, and the function returns NULL when no matching lookup row exists. This allows the account-length rule for each IBAN country to be maintained as reference data rather than hard-coded logic.
  • VALIDATE_IBAN_ACC — Validates an IBAN account number and returns a NUMBER result. The function enforces a maximum account length of 34 characters (returning 1 on failure), confirms that the country prefix in the supplied account resolves to a valid length using IBAN_ACC_LOOKUP, and derives the transformation of the account into a numeric string used for the ISO 7064 Modulus 97-10 check-digit calculation. The internal working variables include the validation digit, the transformed account buffer, modulus 97 remainders, and a regenerated check value. A return value of 1 indicates a validation failure, while success permits the account to be accepted.

Tables Accessed

According to the documented metadata, the package employs one base table through an APPS synonym: HR_LOOKUPS. The table is read, not written. HR_LOOKUPS is the Oracle HRMS generic lookup repository, and this package relies on lookup type IBAN_ACC_LOOKUP, where each lookup code is an IBAN country identifier and each description holds the expected total IBAN length for that country. Maintaining the length table rather than embedding it in code permits country-specific rules to be configured or extended without modifying the package.

Usage Notes

The package has no documented arguments in the ETRM record beyond those shown in the excerpt, and it is referenced by twelve other packages, indicating it is invoked indirectly by higher-level HR and payments routines rather than being called by end users. Typical invocation points include supplier and employee bank account entry forms, which validate IBAN values before saving to the bank account tables, and payroll or payment concurrent programs that pre-validate account data prior to payment file generation. Custom code should call VALIDATE_IBAN_ACC to obtain the numeric validation result and treat any value of 1 as a hard validation failure, and may call GET_ACC_LENGTH to retrieve the configured length for a given IBAN country lookup code. Because the package uses the -20001 hr_application_error convention, callers that already handle Oracle HRMS API errors can capture IBAN validation exceptions through the same error stack. As with all APPS-owned PL/SQL, direct modification is not supported and custom calls must respect the package's documented signatures.