Results for “processed_flag”

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

Overview

AP_CHECKRUN_CONFIRMATIONS_ALL is a Payables (AP) module table owned by the AP schema in Oracle EBS 12.1.1 and 12.2.2. Per the ETRM repository, its documented purpose is to serve as a temporary table for payment batch confirmations. During payment processing, Oracle Payables assigns check (payment document) numbers across the individual payments within a payment batch. The confirmation step is the point at which the actual check number range consumed by a batch is reconciled against the range originally allocated. AP_CHECKRUN_CONFIRMATIONS_ALL is the staging structure that records the beginning and ending numbers of the document range confirmed for each payment run identified by CHECKRUN_NAME.

Because its rows exist only for the duration of the confirmation workflow and are cleared or overwritten on subsequent confirmations, the table should be treated as transient working data rather than a permanent transaction ledger. Landed in a warehouse or data vault, its heuristic classification is satellite-leaning, as mined from its foreign key structure: the table hangs off a parent key (CHECKRUN_NAME referencing AP_INV_SELECTION_CRITERIA_ALL) and stores descriptive, state-describing attributes rather than composing a hub or resolving a many-to-many link. Practically, that suggests modeling it as a satellite keyed to the payment batch selection criteria hub, with load-date and record-source metadata appended during ingestion.

The table is an _ALL table and therefore carries ORG_ID, so it participates in Multi-Org Access Control partitioning by operating unit, consistent with other AP tables in the ETRM schema.

Key Information Stored

The documented ETRM schema for 12.2.2 lists 11 columns. Of these, the following are the most significant:

• CHECKRUN_NAME — The payment batch / check run identifier. This is both the leading column of the primary key and the sole documented foreign key, referencing AP_INV_SELECTION_CRITERIA_ALL.
• START_CHECK_NUMBER — The first document number allocated or confirmed for the run; the second component of the composite primary key.
• END_CHECK_NUMBER — The last document number confirmed for the run, expressing the upper bound of the consumed range.
• RANGE_LOOKUP_CODE — A lookup-coded indicator describing the nature of the number range (for example, a within-range or spillover condition), driven by an Oracle lookup type.
• PROCESSED_FLAG — Status flag indicating whether the confirmation row has been consumed or completed by the confirmation process.
• ORG_ID — Operating unit identifier, enforcing Multi-Org security partitioning.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — The standard Oracle EBS who-column audit set, providing the creating user/date and the most recent modification user, date, and login session.

The surrogate/primary key is AP_CHECKRUN_CONFIRMATIONS_PK, defined as the composite (CHECKRUN_NAME, START_CHECK_NUMBER). There is no separate single-column surrogate; the business key and the primary key are effectively the same composite, which is typical of transient staging tables where no independent sequence is maintained.

Common Use Cases and Queries

The principal use case is diagnosing and reconciling payment document numbering during and after a payment batch confirmation. A typical diagnostic query lists the confirmed ranges for a given run:

• SELECT checkrun_name, start_check_number, end_check_number, range_lookup_code, processed_flag, org_id FROM ap.ap_checkrun_confirmations_all WHERE checkrun_name = :run_name;
• Detecting allocated-but-unconfirmed ranges by filtering on PROCESSED_FLAG.
• Cross-joining to AP_INV_SELECTION_CRITERIA_ALL on CHECKRUN_NAME to retrieve batch selection parameters (payment date, pay-through date, bank account) alongside the confirmed document range.
• Warehouse reconciliation reports that compare the confirmed range against payment records in AP_CHECKS_ALL for the same run, flagging gaps or duplicates in document numbers.

Because the table is temporary, queries against production should be scoped by CHECKRUN_NAME and ORG_ID, and historical trending requires that rows be persisted to a custom staging table or ETL target before the confirmation process clears them.

Related Objects

• AP_INV_SELECTION_CRITERIA_ALL — Parent table; joined via CHECKRUN_NAME, holding the selection parameters that define each payment batch.
• AP_CHECKS_ALL — Stores the actual payment documents; joined on check number and run name to validate confirmed ranges.
• AP_PAYMENT_SCHEDULES_ALL — Source of invoices scheduled for payment within the batch.
• AP_BATCHES_ALL — Header-level payment batch metadata referenced by CHECKRUN_NAME relationships.
• IBY_PAY_SERVICE_REQUESTS / IBY_PAYMENTS_ALL — Payment instruction records that consume document numbers produced by the confirmation step.
• FND_LOOKUP_VALUES — Supplies the values displayed for RANGE_LOOKUP_CODE.
• AP_PAYMENT_PROCESSING API (apex) — The concurrent program machinery that populates and clears this table during check run confirmation.