The TM_TRANS_ pattern, and the view that tames it

No fixed schema here: every match type builds its own tables from your attributes. The Match Type view is how Oracle made that queryable anyway, and it is the only door worth using.

Note: Transaction Matching, the half of ARCS, Oracle's reconciliation module, that pairs transactions between systems by rule, stores its transactions in tables built from your own attributes. This page is the pattern those tables and their views follow.

All ARCS table references hang off Tables & views; the full export route is on TM export.

RuleQuery the view, not the tables; learn column names from the view's own SQL; and export before anything is purged.

Neverhard-code TM_TRANS_ column names from one environment into another. The attributes define them, and the attributes differ.

◆ The pattern, tables per data source, a view per match type, and the column-name method.

Object	The pattern
TM_TRANS_<DATA_SOURCE_ID>	One table per data source, created when the match type is approved, per the reference. Columns come from your attributes, so no two installations look alike, and neither do two match types.
TM_<MATCH_TYPE_ID>	One view per approved match type, holding all transactions across all its data sources, per the view doc. It joins to other tables, and report queries built on it are portable. This is the export surface.
The column-name method	Oracle's own instruction: read the Match Type view's SQL to learn the column names for each data source. Do it once per match type, keep the mapping beside the export query, and re-check after attribute changes.

Operating rule from the export page: query the views, union match types in the warehouse where differing shapes are safe, and export before any purge or archive, because the dynamic tables are exactly the data the app forgets on purpose.

THE USE CASE, SIMPLIFIED

The problem: Every matching export is bespoke, and an attribute change breaks it without a sound.

What we build: Exports run through the Match Type views, with mappings versioned and unions in the warehouse.

What you get: The exports survive change, and the change gets caught the night it happens.

Every TM export in your shop bespoke?

One export per Match Type view, the column mappings versioned beside the queries, and the unions live in the warehouse where they belong.

Talk to us

Terms on this page

DATA_SOURCE_ID: The suffix that names each dynamic table.
Match Type view: TM_ plus the match type ID. All sources, one query.
the method: Read the view's SQL for column names. Oracle's own instruction.
portable: View-based report queries survive environment moves.