Search Results ce_stmt_headers_interface_pk

Overview

CE_STATEMENT_HEADERS_INT_ALL is the open interface (staging) table in the Oracle E-Business Suite Cash Management module (CE) that holds bank statement header information prior to validation and import into the production cash management tables. It serves as the entry point for externally sourced bank statements, including statements delivered via bank feeds, flat-file conversions, or custom loaders. Records are keyed by a composite primary key, CE_STMT_HEADERS_INTERFACE_PK, defined on STATEMENT_NUMBER and BANK_ACCOUNT_NUM.

As documented in the ETRM metadata, this object is classified with a heuristic Data Vault designation of hub-leaning. This suggests a modeling pattern in which the statement header acts as a central business entity (hub), keyed by the combination of statement number and bank account number, with descriptive and transactional attributes attached via related satellites. The interface table itself is not implemented as a permanent table in every database, reflecting its role as a transient staging area rather than a persistent transactional store.

Key Information Stored

The table stores the attributes required to construct a bank statement header during import. The most significant columns include:

• STATEMENT_NUMBER — the bank-assigned statement identifier; part of the composite primary key and a business-key candidate.
• BANK_ACCOUNT_NUM — the bank account number associated with the statement; the second component of the composite primary key.
• CURRENCY_CODE — the statement currency, which carries a foreign key relationship to FND_CURRENCIES.

The composite primary key CE_STMT_HEADERS_INTERFACE_PK (STATEMENT_NUMBER, BANK_ACCOUNT_NUM) is the documented uniqueness constraint and represents the business-key candidate for the header entity. Beyond these columns, the table carries the standard descriptive and control attributes expected of a Cash Management statement interface record, but only the columns reflected in the metadata above are confirmed as structurally significant.

Common Use Cases and Queries

The primary use case is loading external bank statements and reconciling them against the cash management subledger. Typical activities include populating the interface table from a bank feed, validating header and line data, and invoking the statement import concurrent program, which reads from this interface and writes to the permanent statement tables.

A common query pattern joins headers to interface lines to verify that every header has matching lines before import:

• SELECT h.statement_number, h.bank_account_num, h.currency_code FROM ce_statement_headers_int_all h WHERE NOT EXISTS (SELECT 1 FROM ce_statement_lines_interface l WHERE l.statement_number = h.statement_number AND l.bank_account_num = h.bank_account_num);

Error monitoring is another frequent scenario, joining headers to CE_HEADER_INTERFACE_ERRORS to identify statements that failed validation:

• SELECT h.statement_number, h.bank_account_num, e.* FROM ce_statement_headers_int_all h JOIN ce_header_interface_errors e ON e.statement_number = h.statement_number AND e.bank_account_num = h.bank_account_num;

Related Objects

The relationships documented in the ETRM metadata define the dependency network around this interface table:

• FND_CURRENCIES — referenced by CURRENCY_CODE, providing validation of the statement currency.
• CE_HEADER_INTERFACE_ERRORS — references this table via STATEMENT_NUMBER and BANK_ACCOUNT_NUM, capturing validation errors at the header level.
• CE_STATEMENT_LINES_INTERFACE — references this table via STATEMENT_NUMBER and BANK_ACCOUNT_NUM, holding the corresponding statement line detail.

These three objects form the core of the statement interface process: headers define the statement, lines define its transactions, and errors record exceptions. Imported data ultimately flows to the permanent Cash Management statement and reconciliation tables, so any query against CE_STATEMENT_HEADERS_INT_ALL should account for its transient nature and the fact that records are removed or archived after successful import.