Search Results fun_customer_maps




Overview
Explore in AI Chat

Overview

FUN_CUSTOMER_MAPS is a table owned by the FUN schema (Financials Common Modules) in Oracle E-Business Suite 12.1.1 and 12.2.2. It stores the mapping between an Intercompany organization and the customer record that should be used when an invoice is generated in Oracle Receivables for that organization. In practice, when Intercompany transactions flow into Receivables, the customer applied to the resulting invoice is not selected ad hoc; it is derived from the configuration held in this table. This makes FUN_CUSTOMER_MAPS a configuration and reference table rather than a high-volume transactional table, and it sits at the intersection of Intercompany setup and Receivables customer master data.

From a Data Vault modeling perspective, the mined relationship structure classifies this table heuristically as standalone. It does not behave as a classic hub, link, or satellite; instead it carries a single foreign key to the customer master, which suggests treating it as a small reference or mapping construct when designing downstream models rather than as a central integration point.

Key Information Stored

The documented physical schema contains 25 columns. The most operationally significant columns are:

  • CUSTOMER_MAP_ID — the surrogate primary key uniquely identifying each mapping row.
  • RELATION_ID — identifies the Intercompany organization (relationship) to which the customer mapping applies. This is the core business-key component.
  • CUST_ACCOUNT_ID — the foreign key to HZ_CUST_ACCOUNTS; the customer account used on the Receivables invoice.
  • SITE_USE_ID — identifies the specific customer site/use associated with the mapping, refining which customer location is applied.
  • ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE15 — the standard EBS descriptive flexfield (DFF) columns, available for client-specific extensions.
  • CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard WHO columns recording audit and concurrency information.

The business key is effectively the combination of RELATION_ID and the customer/site reference, while CUSTOMER_MAP_ID serves as the synthetic identifier. The only documented foreign key is CUST_ACCOUNT_ID → HZ_CUST_ACCOUNTS, reinforcing the customer-master dependency.

Common Use Cases and Queries

The primary use case is auditing and reporting on Intercompany-to-customer assignments. A typical query resolves the mapping to the customer name and site:

  • Listing all mappings: SELECT CUSTOMER_MAP_ID, RELATION_ID, CUST_ACCOUNT_ID, SITE_USE_ID FROM FUN.FUN_CUSTOMER_MAPS;
  • Joining to the customer master: SELECT m.RELATION_ID, c.account_number, c.party_id FROM FUN.FUN_CUSTOMER_MAPS m JOIN HZ_CUST_ACCOUNTS c ON m.CUST_ACCOUNT_ID = c.cust_account_id;
  • Detecting duplicate or missing mappings per Intercompany organization to prevent incorrect Receivables invoicing.

Recommended practice is to read the table directly only for diagnostics; configuration changes should be made through the supported Intercompany setup forms or APIs, and integration should reference the table read-only.

Related Objects

  • HZ_CUST_ACCOUNTS — referenced directly via CUST_ACCOUNT_ID; the primary outbound relationship.
  • HZ_CUST_ACCT_SITES_ALL and HZ_CUST_SITE_USES_ALL — resolve the SITE_USE_ID to a physical customer site.
  • Intercompany organization/relationship tables (for example the FUN intercompany setup) that supply RELATION_ID.
  • Oracle Receivables (AR) invoice and transaction tables, which consume the mapping at invoice creation.
  • Standard EBS audit migration views (such as _ALL variants and audit shadow tables) where applicable to WHO-tracked columns.

Because the table is small and configuration-oriented, it is often queried alongside customer master and Receivables data to validate that Intercompany invoicing resolves to the correct customer.