Search Results days_adjustment




Overview

The XTR.XTR_RECONCILIATION_PROCESS table is a Treasury module (XTR) reference object that stores reconciliation method definitions. It governs how bank statement lines, cash transactions, and treasury flows are matched, verified, and posted during the reconciliation cycle. Each row defines a verification method combined with a reconciled pass code and an ordered sequence, allowing Oracle Treasury to apply multiple reconciliation passes in a defined priority. The table is classified as VALID in the XTR schema and is documented with seven physical columns in the ETRM 12.2.2 schema, applicable to both 12.1.1 and 12.2.2 environments.

From a Data Vault modeling perspective, the mined FK structure classifies this object as standalone. This is a heuristic suggestion rather than an enforced rule: the table is not documented as a dependent child of another entity through a foreign key, and it can reasonably be modeled as a reference or lookup hub where SEQUENCE_ORDER, VERIFICATION_METHOD, and RECONCILED_PASS_CODE form the business key. Implementations that build a raw vault around Treasury reconciliation data should treat this as a small, low-volatility reference set rather than a transactional satellite.

Key Information Stored

The primary key is defined by the constraint XTR_RECONCILIATION_PROCESS_PK, which spans three columns: SEQUENCE_ORDER, VERIFICATION_METHOD, and RECONCILED_PASS_CODE. This composite business key is the most significant structural fact about the table, since it determines both uniqueness and the order in which reconciliation logic executes.

  • SEQUENCE_ORDER — numeric ordering that determines the pass in which a given reconciliation rule is evaluated. It is part of the primary key and drives deterministic processing across multiple passes.
  • VERIFICATION_METHOD — the matching algorithm or validation technique applied during the pass. Part of the primary key.
  • RECONCILED_PASS_CODE — the code assigned to a transaction once reconciliation succeeds under this method. Part of the primary key.
  • PROCESS_TYPE — classifies the reconciliation process variant to which the definition applies.
  • DAYS_ADJUSTMENT — a day offset applied during matching, commonly used for value-date or clearing-date tolerance windows.
  • ALLOW_HOLIDAYS_YN — flag indicating whether calendar holidays are permitted within the adjustment window.
  • GENERATE_REPORT_YN — flag controlling whether a reconciliation report is produced for this definition.

No separate surrogate key column is documented; the composite primary key serves as both the natural and the physical unique identifier.

Common Use Cases and Queries

Typical usage centers on inspecting or auditing the configured reconciliation passes, verifying uniqueness of business keys, and joining definitions to reconciliation results. A representative query retrieves the ordered rule set:

  • SELECT sequence_order, verification_method, reconciled_pass_code, process_type, days_adjustment, allow_holidays_yn, generate_report_yn FROM xtr.xtr_reconciliation_process ORDER BY sequence_order;
  • Filtering by process type: WHERE process_type = :p_process_type to isolate rules for a specific reconciliation scenario.
  • Reporting which definitions produce output: WHERE generate_report_yn = 'Y'.
  • Duplicate detection across the composite key to confirm configuration integrity before enabling a reconciliation run.

Reporting use cases include reconciliation setup audits, gap analysis of adjustment windows, and documentation of which verification methods are active by sequence. Because the table is small and reference-oriented, it is frequently cached or extracted into BI layers alongside treasury transaction facts.

Related Objects

The mined relationship data classifies this table as standalone, meaning no outbound foreign keys are documented. Its linkage to the wider Treasury model is therefore conceptual rather than enforced, and the following objects are the most significant points of interaction:

When integrating or reporting on Treasury reconciliation, join these objects on the pass code and sequence order rather than expecting a declarative FK, since the metadata documents none.