Search Results code_level




Overview

AP_RECON_ERROR_CHK_GROUP_LINES is an Oracle Payables (AP) reconciliation table that stores the individual error line records generated by the AutoClear reconciliation process. AutoClear is the Oracle EBS mechanism that automatically clears matched payment, invoice, and cash management transactions for bank statement reconciliation. When the matching engine encounters conditions that prevent a clean reconciliation, it records those conditions as errors, and this table persists the granular, item-level detail behind each recorded error.

The table is owned by the AP schema and holds eight documented columns in ETRM 12.2.2. Its structure describes a parent-child relationship anchored on a reconciliation record specification. Based on the foreign key structure and the composite primary key composition, the table exhibits a satellite-leaning classification in Data Vault modeling terms — it captures descriptive, dependent attributes that qualify a parent reconciliation record rather than acting as an independent hub or a pure association link. In practice, this means the table should be modeled as a subordinate descriptor of the AutoClear error record, keyed to its parent specification.

Key Information Stored

The AP_RECON_ERROR_CHK_GROUP_LI_PK primary key is composite, comprising three columns: RECON_RECORD_SPEC_ID, CODE_LEVEL, and CODE. This composition is significant because it dictates the grain of each row — a single error line is uniquely identified by the parent specification plus a hierarchical code level plus the specific code value.

  • RECON_RECORD_SPEC_ID — The foreign key linking each line to its parent error check group record in AP_RECON_RECORD_SPECS. This is the primary business-key anchor and the column most often used in joins.
  • CODE_LEVEL — Defines the hierarchical tier at which the associated error code applies. This column, matched by the user search term "code_level," distinguishes grouped or nested error classifications produced during AutoClear processing.
  • CODE — The specific error or reason code assigned to the line. Together with CODE_LEVEL it forms the business-key suffix within a given specification.
  • Audit columns — LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATION_DATE, and CREATED_BY provide standard Who-column tracking of row creation and modification.

Because RECON_RECORD_SPEC_ID, CODE_LEVEL, and CODE together form the primary key, there is no separate surrogate system-generated identifier; the composite key itself serves as the unique business-key candidate.

Common Use Cases and Queries

The most common use case is investigating why a given AutoClear reconciliation produced errors. A typical query joins this table to its parent specification to retrieve the full error context:

  • Diagnosing AutoClear failures — SELECT l.recon_record_spec_id, l.code_level, l.code FROM ap.ap_recon_error_chk_group_lines l WHERE l.recon_record_spec_id = :spec_id ORDER BY l.code_level, l.code;
  • Aggregating error frequency by code — grouping on CODE_LEVEL and CODE to identify the most prevalent reconciliation breakdowns.
  • Auditing record provenance — using CREATION_DATE and LAST_UPDATE_DATE to isolate error lines generated within a reconciliation run window.
  • Reconciliation reporting — joining to AP_RECON_RECORD_SPECS to present grouped errors alongside their parent specification details.

Related Objects

The primary documented relationship is to the parent table AP_RECON_RECORD_SPECS, joined on RECON_RECORD_SPEC_ID. This foreign key establishes that each line depends on an existing reconciliation record specification. Related objects of practical significance include the AP AutoClear and Payables reconciliation components (such as the reconciliation specification and error group tables), and the bank statement reconciliation infrastructure that invokes AutoClear. Analysts should treat AP_RECON_RECORD_SPECS as the mandatory parent in every meaningful query against this table.