Search Results ce_stmt_int_tmp_pk

Overview

CE_STMT_INT_TMP is a permanent interface table within the Cash Management (CE) module of Oracle E-Business Suite, owned by the CE schema and documented as VALID in both release 12.1.1 and 12.2.2. Its documented purpose is the Bank Statement Loader — the process by which external bank statement files are ingested into EBS for reconciliation against cash transactions. The table functions as a staging area: flat-file or feed content is loaded verbatim into numbered generic columns, then validated and transformed into the permanent bank statement tables. The ETRM metadata classifies the extract as standalone, and the heuristic data-vault assessment suggests modeling this object as a satellite-style staging structure rather than as a true hub or link, since all attributes cluster around a single surrogate record key and no foreign-key dependencies to other hubs are documented.

Key Information Stored

The documented physical schema contains 43 columns. The primary key is CE_STMT_INT_TMP_PK, defined on REC_NO, and a unique index CE_STMT_INT_TMP_U1 also spans REC_NO, making REC_NO both the surrogate primary key and the sole business-key candidate. REC_ID_NO is the second most significant documented column, typically used to group the multiple raw rows that belong to a single logical statement record during parsing and validation.

The bulk of the table consists of positional staging columns COLUMN1 through COLUMN36. These hold the delimited fields of the incoming bank statement file in the exact order defined by the bank statement loader mapping; their semantic meaning is determined at load time by the file layout, not by the column name. The remaining documented columns are the standard EBS audit attributes: CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN. No descriptive columns such as bank account, statement date, or amount are permanently named in the metadata — those values reside positionally inside the COLUMN fields until the loader maps them.

Common Use Cases and Queries

The primary use case is verifying what the Bank Statement Loader actually parsed from a source file. Because the staging rows are transient, queries are most useful while a load is in progress or after a failed run:

• Inspecting a specific statement batch: SELECT REC_NO, REC_ID_NO, COLUMN1, COLUMN2, COLUMN10 FROM CE.CE_STMT_INT_TMP WHERE REC_ID_NO = :p_rec_id ORDER BY REC_NO;
• Row-count reconciliation between the source file and the staged content: SELECT REC_ID_NO, COUNT(*) FROM CE.CE_STMT_INT_TMP GROUP BY REC_ID_NO;
• Audit of who loaded a batch and when: SELECT REC_NO, CREATED_BY, CREATION_DATE, LAST_UPDATE_DATE FROM CE.CE_STMT_INT_TMP ORDER BY CREATION_DATE DESC;
• Root-cause analysis for loader rejections, where positional columns are compared against the bank file layout definition.

Related Objects

The metadata documents no foreign-key relationships, so this object is standalone. Functionally, it sits between the SQL*Loader control file / bank file definition and the permanent Cash Management statement entities. The most significant related objects are the Bank Statement Loader program and its concurrent program definition, which populates CE_STMT_INT_TMP; the bank statement headers and lines tables (CE_STATEMENT_HEADERS and CE_STATEMENT_LINES), which receive the validated output; the statement interface and reconciliation tables that carry accepted records forward; the CE_STATEMENT_RECONCILES table for matched transactions; and the bank account tables (CE_BANK_ACCOUNTS) that supply the target account context. The loader execution is typically driven by the Cash Management responsibility through the "Bank Statement Loader" concurrent request, which reads CE_STMT_INT_TMP and transfers validated rows into the permanent statement schema.