Search Results pay_jp_banks




Overview
Explore in AI Chat

Overview

PAY_JP_BANKS is a Payroll (PAY) module table owned by the HR schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It stores master reference information for Japanese financial institutions (banks) used within Japanese payroll and banking processes. The table acts as the bank-level parent in a two-tier hierarchy: banks are defined in PAY_JP_BANKS, and their individual branches are defined in the child table PAY_JP_BANK_BRANCHES. This structure supports Japanese payroll disbursements, employee bank account maintenance, and regulatory bank-master reporting.

Under the heuristic Data Vault classification mined from the documented foreign key structure, PAY_JP_BANKS is hub-leaning. In Data Vault modeling terms, it behaves as a hub: its primary key (BANK_CODE) is the stable business key that anchors the bank entity, while descriptive attributes such as BANK_NAME and BANK_NAME_KANA would typically be modeled as satellite attributes. The absence of incoming foreign keys other than from the branch table reinforces this hub interpretation.

Key Information Stored

The documented physical schema for 12.2.2 contains 11 columns. The most significant are:

  • BANK_CODE — The primary key and sole documented unique index (PAY_JP_BANKS_PK). It is the business-key candidate that uniquely identifies each Japanese bank and is the column referenced by the branch table.
  • BANK_NAME — The display name of the bank. Documented as a unique index candidate (PAY_JP_BANKS_U1).
  • BANK_NAME_KANA — The phonetic (kana) rendering of the bank name. Also documented as a unique index candidate (PAY_JP_BANKS_U2), reflecting common Japanese searching and sorting on phonetic spelling.
  • ENABLED_FLAG — Controls whether the bank record is active and selectable in payroll processing.
  • START_DATE_ACTIVE and END_DATE_ACTIVE — Date-effective bounds that govern when the bank definition is valid for use.
  • CREATION_DATE, CREATED_BY — Standard audit columns recording record creation.
  • LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — Standard audit columns recording the most recent modification and the login session responsible.

Notably, BANK_CODE serves as both the surrogate/primary key and the business key; unlike many EBS tables, there is no separate numeric BANK_ID surrogate documented here.

Common Use Cases and Queries

Typical scenarios include validating bank codes during employee bank-account entry, generating bank master listings for payroll reporting, and joining to branch data to resolve full bank/branch references.

A basic lookup of active banks:

  • SELECT bank_code, bank_name, bank_name_kana FROM pay_jp_banks WHERE enabled_flag = 'Y' AND SYSDATE BETWEEN NVL(start_date_active, SYSDATE) AND NVL(end_date_active, SYSDATE + 1);

Resolving banks with their branches:

  • SELECT b.bank_code, b.bank_name, br.branch_name FROM pay_jp_banks b JOIN pay_jp_bank_branches br ON br.bank_code = b.bank_code;

Phonetic search is common in Japanese reporting, so queries filtering on BANK_NAME_KANA support kana-based lookups and sorting.

Related Objects

The following objects are most significant in relation to PAY_JP_BANKS:

  • PAY_JP_BANK_BRANCHES — The primary dependent table. It references PAY_JP_BANKS through the foreign key column PAY_JP_BANK_BRANCHES.BANK_CODE → PAY_JP_BANKS. Any bank must exist here before its branches can be defined.
  • The PAY_JP_BANKS_PK primary key index and the unique indexes PAY_JP_BANKS_U1 (BANK_NAME) and PAY_JP_BANKS_U2 (BANK_NAME_KANA) — enforce uniqueness at the database level.
  • Japanese payroll bank-processing and disbursement logic in the PAY module, which consumes bank and branch master data to validate employee bank details.

The FK relationship confirms a hub-to-child dependency, where PAY_JP_BANKS is the parent reference and PAY_JP_BANK_BRANCHES carries the qualifying branch detail.