Search Results ce_usr_validate_branch




Overview
Explore in AI Chat

Overview

CE_CUSTOM_BANK_VALIDATIONS is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite, classified as a customization-tier API (API classification: OTHER) designed to support the Cash Management (CE) bank setup infrastructure. Its central purpose is to provide country-specific validation logic for bank, bank branch, and bank account data entered through the Bank Setup user interfaces. Because regulatory and formatting requirements for banking identifiers vary significantly by country, Oracle provides this package as an extension point that allows implementers to embed custom validation rules without modifying seeded Oracle code.

The package is declared with AUTHID CURRENT_USER, meaning its procedures execute with the privileges of the invoking user rather than the defining user. This choice is consistent with a customization package intended to be invoked from multiple contexts (forms, concurrent processes, and other PL/SQL packages) while still respecting the calling session's security profile. The package header carries a modest version history, with the most recent documented revision dated December 2009 (file header cecbnkvs.pls 120.2), indicating that the interface has remained stable across the 12.1.1 and 12.2.2 releases.

Key Procedures and Functions

The package exposes three documented public procedures, each aligned to a distinct level of the banking hierarchy:

  • CE_USR_VALIDATE_BANK — Invoked when a bank record is validated from the Bank Setup UI. It accepts bank-level attributes such as country name (two-digit ISO code), bank number, bank name, alternate bank name, tax payer ID, and bank ID, and returns both an overall return status and a formatted bank number to be stored. The outbound formatted value allows the procedure to normalize the bank number according to country-specific conventions before persistence.
  • CE_USR_VALIDATE_BRANCH — Invoked when a bank branch is validated from the Bank Branch Setup UI. It receives branch-level attributes alongside the parent bank context, including country name, bank number, branch number, bank name, branch name, alternate branch name, branch type, bank ID, and branch ID, and returns a validation status.
  • CE_USR_VALIDATE_ACCOUNT — The procedure associated with the search term "ce_usr_validate_account." It performs the equivalent validation role at the bank account level, complementing the bank and branch procedures so that the full bank-to-account hierarchy can be validated consistently through the same customization hook.

Each procedure follows the standard FND_API convention of returning fnd_api.g_ret_sts_success or fnd_api.g_ret_sts_error, enabling callers to handle outcomes uniformly.

Tables Accessed

According to the documented metadata, the package references the HZ_ORGANIZATION_PROFILES table via an APPS synonym. This table stores organization-level party information within the Oracle Trading Community Architecture (TCA) model. Because banks and bank branches in Cash Management are represented as parties and party sites, validation routines frequently need to consult organization profile data—such as legal names, tax identifiers, or profile attributes—to confirm that a proposed bank or branch entry is consistent with the underlying party record. The formatted bank number returned by CE_USR_VALIDATE_BANK may likewise be checked against or derived with reference to this profile data before being passed back to the calling UI.

Usage Notes

CE_CUSTOM_BANK_VALIDATIONS is not a general-purpose utility package; it is a deliberate customization seam. Oracle's seeded Bank Setup and Bank Branch Setup forms and associated business logic invoke these procedures during record validation, and the default Oracle-supplied body typically performs minimal or pass-through processing. Customers and implementation partners are expected to replace or extend the body with country-specific rules, for example validating bank routing formats, enforcing tax payer ID patterns, or normalizing account and bank numbers.

The package is referenced by one other package, indicating it participates in a small dependency chain within the Cash Management flow rather than standing alone. When customizing, developers should preserve the documented signatures exactly, since altering IN or OUT parameters will break the internal callers. Because the package runs under AUTHID CURRENT_USER, any custom logic must account for the privileges of the runtime session, and grants on any additional tables or packages referenced by the custom body must be extended to all users who may trigger bank validation. Testing should cover the full hierarchy—bank, branch, and account—to ensure consistent behavior across the setup UIs.