Search Results hr_sg_bank_acct_validation

Overview

The APPS.HR_SG_BANK_ACCT_VALIDATION package is a Singapore-specific localization utility within Oracle E-Business Suite Human Resources (Oracle HRMS). Its stated purpose, drawn from the package header comment, is to "declare a function to validate SG bank accounts for certain banks." In the context of Oracle EBS 12.1.1 and 12.2.2, this package supports country-specific payroll and third-party payment processing requirements by providing a programmatic account validation routine that can be called before bank account information is accepted, stored, or transmitted. Because Singapore banking institutions enforce varied account numbering rules, centralized validation prevents invalid account data from entering the HRMS person or assignment bank details and reduces the risk of failed electronic fund transfers or rejected payment files.

The package is owned by APPS, is classified under the ETRM as OTHER, and is declared with AUTHID CURRENT_USER, meaning its SQL executes with the privileges of the invoking user rather than the package owner. The source header indicates version 115.1, dated 11-June-2002, authored by John Karouzakis, and notes that version 115.1 made the package GSCC compliant. The original version 115.0 was created on 30-May-2002. This long-standing lineage confirms the object's stability across the 12.1.1 and 12.2.2 releases.

Key Procedures and Functions

The ETRM metadata documents exactly one callable element within this package:

• VALIDATE_ACCOUNT — A function that validates a Singapore bank account against the rules applicable to a specified bank. Based on the package header, it accepts two input values: an account number and a bank name, and returns a VARCHAR2 result. The return value conventionally communicates validation success or an error indicator, allowing the calling program to decide whether to accept, reject, or flag the account. The function encapsulates the bank-specific edit logic so that consuming code does not need to embed individual institution rules.

No other procedures or functions are documented for this package. Developers should treat VALIDATE_ACCOUNT as the sole supported entry point and avoid assuming additional overloads or helper routines exist in the public specification.

Tables Accessed

The ETRM metadata lists no tables referenced via APPS synonyms for this package, and it records zero other packages referencing it. The specification header likewise exposes only the function declaration and no table dependencies. This indicates that the package is a self-contained validation utility whose logic is driven by the parameters passed in rather than by database lookups, or that any underlying data access occurs through private constructs or synonyms not captured in the documented metadata. From an integration standpoint, the absence of documented table access means VALIDATE_ACCOUNT can be invoked with minimal concern for locking, read consistency, or side effects on HRMS payroll tables. It should be regarded as a read-only validation service rather than a data maintenance routine.

Usage Notes

HR_SG_BANK_ACCT_VALIDATION.VALIDATE_ACCOUNT is typically invoked from localization-aware bank account entry flows. In Oracle HRMS, personal and assignment payment methods capture employee bank details, and Singapore legislation and banking practice impose format constraints on those details. The function may be called from Oracle Forms personalizations, from the person/assignment bank details form logic for the SG legislation, or from custom PL/SQL that validates account data before insert or submission. It may also be referenced by payroll or third-party payment processing routines that assemble electronic funds transfer files for Singapore banks.

Because the package is AUTHID CURRENT_USER, callers must possess the necessary privileges on any objects the function touches; grants must be managed accordingly when invoking it from schemas other than APPS. Custom code should call the function directly rather than duplicating validation logic, ensuring that bank rule changes are applied consistently. Given that no documented packages reference it, adopters are responsible for wiring the call into their own validation points. The object's version history suggests it has required no functional change since 2002, so behavior should be consistent between EBS 12.1.1 and 12.2.2 environments.