Results for “apbv_bank_branches”

4 results




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

Overview

APBV_BANK_BRANCHES is a Payables (AP) business view that exposes bank branch master data maintained in Oracle E-Business Suite. It presents the branch-level attributes of the internal and external banks defined for a Payables installation — branch names, alternate names in the local language, address information, contact details, and payment-specific identifiers such as the EFT user number, SWIFT code and EDI ID number. Because it is a read-only, denormalized projection of the branch entity, it is intended for query, reporting and outbound integration rather than for transactional maintenance, which continues to be performed through the Bank and Branch setup forms or the corresponding public APIs.

The view is flagged in the ETRM documentation as "Not implemented in this database" and carries no separately documented owner or referenced base objects. In practice this means the definition exists in the EBS data model and is shipped with the product, but it is not necessarily created or granted in every environment. Customers and integrators who require it typically compile it from the published view text or obtain it from the vendor-supplied patch for the appropriate release.

Underlying Base Objects

The documented view text defines APBV_BANK_BRANCHES as a single-table projection over AP_BANK_BRANCHES, aliased BB, with the query terminated by WITH READ ONLY. No joins, unions or inline views are used, so the row grain of the view is identical to that of AP_BANK_BRANCHES: one row per bank branch record. Column names are largely preserved, with a few labels in the SELECT list differing cosmetically from the underlying column names (for example BANK_BRANCH_NAME versus the documented column BANK_BRANCH_NAME, and BANK_NUM versus BANK_BRANCH_NUMBER). AP_BANK_BRANCHES itself is the branch segment of the Oracle Payments/AP banking model and is related to AP_BANK_BRANCHES' parent bank record through the bank identifier. Consumers should be aware that the read-only clause prevents DML through the view and that no row-level security predicates are added by the view definition, so any data access restrictions must be enforced by the calling application or by grants on the underlying tables.

Key Columns

Common Use Cases and Queries

Typical uses include validation of branch setup before enabling EFT or EDI payment methods, extraction of branch address and contact data for vendor or employee payment notifications, and reconciliation of EDI identifiers across banks for trading-partner onboarding. A minimal query returning EDI identifiers with branch context is:

  • SELECT bank_branch_id, bank_name, bank_branch_name, bank_branch_number, edi_id_number FROM apbv_bank_branches WHERE edi_id_number IS NOT NULL;
  • SELECT bank_name, bank_branch_name, eft_swift_code, city, state, country FROM apbv_bank_branches WHERE country = 'US' ORDER BY bank_name, bank_branch_name;
  • SELECT b.bank_branch_name, b.edi_id_number FROM apbv_bank_branches b WHERE b.end_effective_date IS NULL OR b.end_effective_date >= SYSDATE;

Because the view is read-only and unsecured at the database layer, reports and interfaces built on it should filter by effective dates and validate institution type to avoid selecting obsolete or non-bank branches. Where the view is absent from the environment, the equivalent query can be issued directly against AP_BANK_BRANCHES.