Results for “hz_bank_pub”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

APPS.HZ_BANK_PUB is a public PL/SQL API package within the Oracle E-Business Suite Trading Community Architecture (TCA) / Receivables party model. It provides the supported programmatic interface for creating and maintaining banking entities in the Oracle EBS data model: banks, bank branches, banking groups, bank group members, clearinghouse assignments, bank sites, and the various contact points (EDI, EFT, web, and phone) associated with those entities. The package is classified as a PUB API, meaning it is intended for external invocation by other Oracle applications, by customer-written extensions, and by TCA infrastructure rather than being an internal helper. It operates against the HZ (Trading Community) schema objects that underpin the model traditionally referred to as the "bank" or "financial institution" party model, wrapping the lower-level TCA party, party site, contact point, and relationship APIs so that banking records are created with consistent structure, validation, and relationship integrity.

Key Procedures and Functions

The ETRM metadata documents 26 procedures and functions. These are consistently organized as create/update pairs across several banking entity families:

• Bank: CREATE_BANK and UPDATE_BANK establish and maintain a bank as a party-level record.
• Bank Branch: CREATE_BANK_BRANCH and UPDATE_BANK_BRANCH manage branches subordinate to a bank.
• Banking Group: CREATE_BANKING_GROUP and UPDATE_BANKING_GROUP define groupings of banking entities.
• Bank Group Member: CREATE_BANK_GROUP_MEMBER and UPDATE_BANK_GROUP_MEMBER associate members with those groups.
• Clearinghouse Assignment: CREATE_CLEARINGHOUSE_ASSIGN and UPDATE_CLEARINGHOUSE_ASSIGN create and change clearinghouse relationships for banking records.
• Bank Site: CREATE_BANK_SITE and UPDATE_BANK_SITE manage physical or logical site records for banking parties.
• Contact Points: dedicated create/update pairs cover EDI_CONTACT_POINT, EFT_CONTACT_POINT, WEB_CONTACT_POINT, and PHONE_CONTACT_POINT, allowing banking records to carry the electronic and telephony routing details required for payments processing.

All procedures follow the TCA PUB convention of returning a standard API status and message through the FND_API layer, driving consistent error handling and rollback behavior for callers. Parameter lists are not reproduced here; callers should consult the package specification in the target release.

Tables Accessed

The package reads and writes through APPS synonyms into the HZ schema. Core party records are held in HZ_PARTIES and its secure view HZ_PARTIES_S, with organization-specific attributes in HZ_ORGANIZATION_PROFILES. Location and party-site data reside in HZ_LOCATIONS and HZ_PARTY_SITES. Contact details are stored in HZ_CONTACT_POINTS, while party usage is governed by HZ_PARTY_USG_ASSIGNMENTS. Banking classification uses HZ_CODE_ASSIGNMENTS. Relationships linking banks, branches, groups, and clearinghouses are kept in HZ_RELATIONSHIPS using types defined in HZ_RELATIONSHIP_TYPES. HZ_BANK_VAL_GT serves as a global temporary staging table for validation, and DUAL supports scalar evaluation. The package also depends on FND_API and on the underlying TCA APIs HZ_PARTY_V2PUB, HZ_PARTY_SITE_V2PUB, HZ_CONTACT_POINT_V2PUB, and HZ_RELATIONSHIP_V2PUB, which perform the detailed inserts and updates.

Usage Notes

HZ_BANK_PUB is typically invoked programmatically rather than from a dedicated Oracle Forms interface. Known dependents include CE_BANK_PUB (Cash Management), IBY_EXT_BANKACCT_VALIDATIONS (Payments), HZ_BANK_PUB_JW (a Java wrapper for the same API), and itself. Custom code that needs to create bank, branch, or clearinghouse records in TCA should call this package rather than inserting directly into HZ tables, because it enforces the relationship and party-site model required by downstream payments and cash management modules. Release considerations apply: verify the package specification for the precise signature set available in EBS 12.1.1 versus 12.2.2, since the documented procedure list represents the 12.2.2 metadata. Since status is VALID and ownership is APPS, invocation should normally be performed with APPS privileges or an equivalent grant, and any custom wrapper should preserve the standard API return-status handling to avoid partial banking records.