Search Results ra_customer_merge_headers_u1

Overview

RA_CUSTOMER_MERGE_HEADERS is the master control table in the Oracle Receivables (AR) schema that governs the customer account merge process. A row is inserted into this table whenever a user submits an account merge request, storing the concurrent request identifier, request status, merge reason code, and high-level information about both affected accounts. The table resides in the APPS_TS_TX_DATA tablespace with a PCTFREE of 10 and is owned by the AR schema. It carries the FND Design Data designation AR.RA_CUSTOMER_MERGE_HEADERS and holds a VALID status in the ETRM 12.2.2 catalog with 46 documented columns.

Under the heuristic Data Vault classification mined from foreign-key structure, this object is best modeled as a link table. It connects two customer party records — the surviving account and the duplicate account — within a single merge transaction, capturing the relationship rather than functioning as a standalone business hub or descriptive satellite.

Key Information Stored

The surrogate primary key is CUSTOMER_MERGE_HEADER_ID (NUMBER(15)), which is also exposed through the unique index RA_CUSTOMER_MERGE_HEADERS_U1 — the only documented business-key candidate. The most operationally significant columns include:

• CUSTOMER_ID and DUPLICATE_ID — foreign keys pointing to HZ_CUST_ACCOUNTS and RA_CUSTOMERS respectively, identifying the surviving and duplicate accounts.
• CUSTOMER_NAME, CUSTOMER_NUMBER, CUSTOMER_REF, CUSTOMER_FIRST_NAME, CUSTOMER_LAST_NAME, CUSTOMER_TYPE — denormalized descriptors for the surviving party.
• DUPLICATE_NAME, DUPLICATE_NUMBER, DUPLICATE_REF, DUPLICATE_FIRST_NAME, DUPLICATE_LAST_NAME, DUPLICATE_TYPE — mirrored descriptors for the account being merged away.
• DELETE_DUPLICATE_FLAG and PROCESS_FLAG — control columns governing whether the source account is removed and the merge's processing state.
• MERGE_REASON_CODE and MERGE_FAIL_MSG — the business justification recorded at submission and the diagnostic text written when the merge errors out.
• REQUEST_ID, PROGRAM_ID, PROGRAM_APPLICATION_ID, PROGRAM_UPDATE_DATE — concurrent program who-columns linking the header to the FND_CONCURRENT_REQUESTS submission.
• PRIORITY and ORG_ID — sequencing for multi-account merges and the operating unit context.
• Standard WHO columns (CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN) and the DFF ATTRIBUTE_CATEGORY/ATTRIBUTE1–15 flexfield columns.

Common Use Cases and Queries

The table is queried most often to audit merge activity, diagnose failed merges, and reconcile customer account consolidation history. A typical diagnostic query retrieves headers for a given concurrent request:

SELECT h.customer_merge_header_id,
       h.customer_name, h.duplicate_name,
       h.process_flag, h.merge_fail_msg
FROM   ar.ra_customer_merge_headers h
WHERE  h.request_id = :request_id
ORDER  BY h.priority;

For failed-merge reporting, filter on records where MERGE_FAIL_MSG is not null and correlate against FND_CONCURRENT_REQUESTS via REQUEST_ID. For duplicate-account analytics, join CUSTOMER_ID and DUPLICATE_ID to HZ_CUST_ACCOUNTS to profile merge frequency by customer. Because the header carries denormalized name and number fields, reports can be produced without touching the party tables, which is useful for historical snapshots where account attributes may have since changed.

Related Objects

• RA_CUSTOMER_MERGES — the child detail table referencing CUSTOMER_MERGE_HEADER_ID; holds the line-level actions performed by each merge.
• HZ_CUST_ACCOUNTS — target of the CUSTOMER_ID foreign key; the party account that survives.
• RA_CUSTOMERS — target of the DUPLICATE_ID foreign key; the legacy Receivables customer slated for removal.
• FND_CONCURRENT_REQUESTS — joined on REQUEST_ID for submission status and timing.
• FND_CONCURRENT_PROGRAM — joined on PROGRAM_ID and PROGRAM_APPLICATION_ID.
• FND_USER — joined on CREATED_BY and LAST_UPDATED_BY for user auditing.
• FND_APPLICATION — referenced via PROGRAM_APPLICATION_ID for program context.

Together these relationships make RA_CUSTOMER_MERGE_HEADERS the authoritative audit anchor for every customer consolidation transaction processed through Receivables.