Search Results record_code

Overview

AP_RECON_SUMMARIES is a Payables module table whose documented purpose is the temporary storage of bank-supplied reconciliation categorized sub-totals. It functions as a staging structure within the bank reconciliation workflow, holding summarized reconciliation figures received from a bank before or during the process of matching those figures against the internal Payables reconciliation data maintained in Oracle EBS. The table is not intended to serve as a permanent transactional store; its role is transient, and the ETRM metadata indicates that it is not implemented in the database of record referenced by the documentation.

The primary key, AP_RECON_SUMMARIES_PK, is a composite key defined over BANK_ACCOUNT_ID and RECORD_CODE. A single foreign key relationship is documented: BANK_ACCOUNT_ID references AP_BANK_ACCOUNTS_ALL. Under the heuristic Data Vault classification mined from the foreign key structure, AP_RECON_SUMMARIES is categorized as satellite-leaning. In modeling terms, this suggests the table behaves as a descriptive satellite attached to the AP_BANK_ACCOUNTS_ALL hub, with RECORD_CODE acting as a distinguishing attribute or sub-key within each bank account. This classification is a modeling suggestion rather than a mandated design, and it reflects the table's function of holding supplementary, bank-supplied detail keyed to a parent bank account entity.

Key Information Stored

The documented column inventory for this table is compact. The columns that appear in the ETRM metadata are the following:

• BANK_ACCOUNT_ID — Identifier of the bank account to which the reconciliation sub-totals pertain. This column participates in the composite primary key AP_RECON_SUMMARIES_PK and is also the foreign key column referencing AP_BANK_ACCOUNTS_ALL.
• RECORD_CODE — A categorical code that distinguishes reconciliation sub-total records within a given bank account. It is the second component of the composite primary key, meaning that the uniqueness of a row is established jointly by BANK_ACCOUNT_ID and RECORD_CODE.

Because the primary key is composite, neither BANK_ACCOUNT_ID nor RECORD_CODE is unique in isolation; together they form the surrogate/business key combination that guarantees row-level uniqueness. BANK_ACCOUNT_ID is a business-key candidate inherited from the parent bank account definition, while RECORD_CODE acts as a categorization discriminator that aligns with the table's documented role of storing bank-supplied reconciliation categorized sub-totals. Additional monetary or summary columns may exist in a fully implemented schema, but they are not represented in the provided metadata and should be verified against the live dictionary within each environment.

Common Use Cases and Queries

Typical usage centers on the bank reconciliation process, where bank-provided sub-totals are staged and compared against internal bank account activity. Reporting queries commonly join the table to AP_BANK_ACCOUNTS_ALL to resolve account names and numbers, and filter by RECORD_CODE to isolate specific reconciliation categories.

A representative pattern is a join that resolves bank account context and groups sub-totals by category:

• SELECT rs.BANK_ACCOUNT_ID, rs.RECORD_CODE, ba.BANK_ACCOUNT_NAME FROM AP_RECON_SUMMARIES rs JOIN AP_BANK_ACCOUNTS_ALL ba ON ba.BANK_ACCOUNT_ID = rs.BANK_ACCOUNT_ID WHERE rs.BANK_ACCOUNT_ID = :p_bank_account_id ORDER BY rs.RECORD_CODE;
• Diagnostic query to detect duplicate key violations prior to load: SELECT BANK_ACCOUNT_ID, RECORD_CODE, COUNT(*) FROM AP_RECON_SUMMARIES GROUP BY BANK_ACCOUNT_ID, RECORD_CODE HAVING COUNT(*) > 1;
• Category-level reconciliation summary: aggregate sub-totals grouped by RECORD_CODE for a selected set of bank accounts, then compare against corresponding Payables reconciliation output.

Because the table is described as temporary storage, monitoring scripts should also verify that stale staging rows are purged after the reconciliation cycle completes.

Related Objects

The principal related object documented through the foreign key relationship is:

• AP_BANK_ACCOUNTS_ALL — Referenced by AP_RECON_SUMMARIES.BANK_ACCOUNT_ID; supplies the bank account master definition and is the natural join partner for any account-context reporting.
• AP_RECON_SUMMARIES_PK — The composite primary key constraint (BANK_ACCOUNT_ID, RECORD_CODE) enforcing row uniqueness and supporting reconciliation deduplication logic.

Beyond these documented relationships, functional dependencies in the bank reconciliation area typically include the Payables bank statement and reconciliation lineage objects; however, no additional foreign keys are asserted in the ETRM metadata, and any further associations should be confirmed against the actual data dictionary of the target environment.