Results for “automatch_id”

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

Overview

AR_CASH_AUTOMATCH_DTLS is a Receivables (AR) module table within the Oracle E-Business Suite 12.1.1 and 12.2.2 environments. Per the ETRM documentation, it stores string transformation details of an Automatch Rule and is flagged as a BETA feature. Automatch Rules drive the automatic matching of receipts to open transactions, and the detail table augments each rule with instructions on how the receipt string values (such as bank reference numbers or remittance identifiers) should be padded, positioned, or otherwise transformed before a match is attempted.

The table is owned by the AR schema and is validated as VALID in the data dictionary. It is a standalone child table whose membership is defined entirely by its parent rule rather than by an independent business identity. Under a heuristic Data Vault classification, AR_CASH_AUTOMATCH_DTLS is best modeled as a satellite, since it holds descriptive transformation attributes that depend on the parent AR_CASH_AUTOMATCHES record and change over time. The documented relationship confirms a foreign key to AR_CASH_AUTOMATCHES through AUTOMATCH_ID.

Key Information Stored

The documented physical schema for ETRM 12.2.2 lists 12 columns. The most significant columns include:

• AUTOMATCH_DTL_ID — Surrogate primary key, defined by the constraint AR_CASH_AUTOMATCH_DTLS_PK1. It uniquely identifies each transformation detail line.
• AUTOMATCH_ID — The foreign key to AR_CASH_AUTOMATCHES. It ties the transformation line to its parent Automatch Rule and is the primary business grouping key.
• PADDING_SEQUENCE — The order in which padding operations are applied when more than one transformation applies to a string.
• STRING_TYPE_CODE — The category of string being transformed, distinguishing the fields to which the rule logic applies.
• STRING_LOCATION_CODE — Identifies the position from which the string is processed, such as leading or trailing characters.
• PADDING_VALUE_CODE — The value used to pad the string, such as a zero or blank character.
• NUMBER_OF_POSITIONS — The number of characters to which the string is padded or transformed.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — WHO columns providing standard audit tracking for row creation and modification.

Although AUTOMATCH_DTL_ID is the surrogate key, AUTOMATCH_ID combined with PADDING_SEQUENCE and the string attributes forms the practical business identity of a transformation line. Only the primary key constraint is documented; no additional unique index is listed in the metadata.

Common Use Cases and Queries

Typical uses center on configuring and auditing automatic cash matching behavior. A common query retrieves all transformation lines for a given rule:

• SELECT automatch_dtl_id, automatch_id, padding_sequence, string_type_code, string_location_code, padding_value_code, number_of_positions FROM ar_cash_automatch_dtls WHERE automatch_id = :rule_id ORDER BY padding_sequence;
• Reporting transformations joined to their parent rule: SELECT m.automatch_name, d.string_type_code, d.number_of_positions FROM ar_cash_automatch_dtls d, ar_cash_automatchAUTOMATCHES m WHERE d.automatch_id = m.automatch_id;
• Auditing recently changed transformation logic using LAST_UPDATE_DATE and LAST_UPDATED_BY.

Related Objects

The most significant related object is the parent rule table, joined through AUTOMATCH_ID:

• AR_CASH_AUTOMATCHES — Parent Automatch Rule master; referenced by AUTOMATCH_ID.
• AR_CASH_AUTOMATCH_DTLS itself via AR_CASH_AUTOMATCH_DTLS_PK1 is the sole documented key relationship.
• AR_RECEIVABLES_TRX_ALL and AR_CASH_RECEIPTS_ALL — Transactions and receipts processed through the rule logic at matching time.
• AR_RECEIPT_METHODS — Defines receipt method context where automatch rules are assigned.
• AR_CASH_AUTOMATCH_RULES and standard AR reconciliation APIs, such as AR_RECEIPT_API_PUB, which invoke automatic matching driven by these rules.

Because the object is BETA, implementations should verify availability and behavior in the specific patch level prior to relying on it for production matching configuration.