Results for “ra_customer_relationships_all”

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

Overview

RA_CUSTOMER_RELATIONSHIPS_ALL is a Receivables (AR) module table that stores information about relationships between customers. Each row links one customer to another and classifies the nature of that association, enabling Receivables to model corporate hierarchies, parent-child account structures, and other business affiliations used in credit, collections, and statement processing. In an Oracle E-Business Suite 12.1.1 or 12.2.2 environment, the table resides in the AR schema and is owned by the Applications product family. The physical schema documented for 12.2.2 comprises 32 columns.

The table is the “_ALL” variant, which in Oracle EBS nomenclature conventionally indicates that rows are partitioned or filtered by operating unit via the ORG_ID column, with a corresponding “_ALL” synonym and a multi-org secured view exposing only the organizations accessible to the current responsibility. The heuristic Data Vault classification mined from the foreign key structure is link. This is appropriate because RA_CUSTOMER_RELATIONSHIPS_ALL resolves many-to-many associations between customer records; CUSTOMER_ID and RELATED_CUSTOMER_ID both reference the RA_CUSTOMERS table, so a hub-and-link model would isolate the two customer references as hubs and this table as the connecting link carrying the relationship semantics.

Key Information Stored

The table is a link entity; its defining attributes are the two customer references and the type of relationship between them.

• CUSTOMER_ID — foreign key to RA_CUSTOMERS identifying the primary customer in the relationship. Part of the composite primary key RA_CUSTOMER_RELATIONSHIPS_PK.
• RELATED_CUSTOMER_ID — foreign key to RA_CUSTOMERS identifying the customer on the other side of the relationship. Also part of the composite primary key.
• RELATIONSHIP_TYPE — the business classification of the association (for example, parent-child or reciprocal linkage), which governs how the relationship is interpreted.
• CUSTOMER_RECIPROCAL_FLAG — indicates whether the relationship is reciprocal, i.e., whether the reverse association applies to the related customer.
• STATUS — the active or inactive state of the relationship record.
• COMMENTS — free-form descriptive text about the relationship.
• ORG_ID — the operating unit that owns the relationship record, driving multi-org security on the “_ALL” table.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE15 — the standard Oracle EBS descriptive flexfield columns used to capture customer-specific or site-specific relationship attributes.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN — the standard WHO columns recording audit and concurrency information.
• REQUEST_ID, PROGRAM_APPLICATION_ID, PROGRAM_ID, PROGRAM_UPDATE_DATE — concurrent program context that last updated the row.

The surrogate identity is the composite primary key RA_CUSTOMER_RELATIONSHIPS_PK, defined on (RELATED_CUSTOMER_ID, CUSTOMER_ID). Any unique index that supplements this key would represent the business key; the recorded PK is the documented unique identifier for the row.

Common Use Cases and Queries

Typical applications include corporate hierarchy reporting, credit exposure roll-up across related accounts, collections strategy assignment, and customer statement grouping. A common query retrieves all related customers for a given customer, joining back to RA_CUSTOMERS for names:

SELECT rcr.customer_id,
       rcr.related_customer_id,
       rc.customer_name AS related_customer_name,
       rcr.relationship_type,
       rcr.status
FROM   ar.ra_customer_relationships_all rcr,
       ar.ra_customers rc
WHERE  rcr.related_customer_id = rc.customer_id
AND    rcr.customer_id = :customer_id
AND    rcr.org_id = :org_id;

Reciprocal relationships can be filtered using CUSTOMER_RECIPROCAL_FLAG to avoid double-counting when traversing a hierarchy. Because the table is multi-org secured, concurrent extracts and BLANKET-type reports should always restrict by ORG_ID or query through the secured view exposed by the responsibility. Reporting tools such as Oracle Discoverer or BI Publisher frequently use this table as the bridge between customer accounts to support parent-level aging and statement consolidation.

Related Objects

• RA_CUSTOMERS — referenced twice, via CUSTOMER_ID and RELATED_CUSTOMER_ID; the principal parent table supplying customer identity data.
• RA_CUSTOMER_RELATIONSHIPS_PK — the composite primary key constraint (RELATED_CUSTOMER_ID, CUSTOMER_ID) enforcing uniqueness.
• RA_CUSTOMER_RELATIONSHIPS (operating unit view / synonym structure) — the multi-org secured counterpart exposing rows for the active organization.
• RA_SITE_USES_ALL / RA_ADDRESSES_ALL — related customer site infrastructure used with customer hierarchy reporting.
• HZ_CUST_ACCOUNTS and the Trading Community Architecture (TCA) model — in 12.1.1 and 12.2.2, customer relationships are increasingly managed through TCA tables such as HZ_RELATIONSHIPS, providing a parallel and more extensible model.
• Customer API (HZ_CUST_ACCOUNT_V2PUB / relationship APIs) — programmatic maintenance of relationship data aligned with TCA.

When integrating or migrating, note that the “_ALL” designation and the presence of ORG_ID require that any interface respect operating unit boundaries. Relationship data influences credit checking, collections, and consolidated reporting, so care should be taken to reconcile RA_CUSTOMER_RELATIONSHIPS_ALL with the corresponding TCA relationship records when organizations adopt the Trading Community Architecture model.