Search Results fun_subsidiary_party_mappings

Overview

FUN_SUBSIDIARY_PARTY_MAPPINGS is a table in the FUN (Financials Common Modules) schema of Oracle E-Business Suite, documented as VALID in both release 12.1.1 and 12.2.2. Its stated purpose is narrow and transitional: it exists to support the upgrade of GL (General Ledger) subsidiaries into Intercompany Organizations during the transition to the E-Business Tax and intercompany architecture. Once the organizations and transactions have been upgraded, the table is no longer used. It is therefore best understood as a migration staging and mapping artifact rather than a runtime transactional table.

The table records the association between a legacy GL subsidiary, its associated party, the ledger, and the legal entity. Its role is to bridge the pre-upgrade subsidiary model (GL_IEA_SUBSIDIARIES) to the post-upgrade legal-entity and party model (FV_LEGAL_ENTITIES and the TCA party registry). Its heuristic Data Vault classification, mined from the foreign-key structure, is standalone; the table is modeled as neither a hub, link, nor satellite, which reflects its role as an upgrade-only mapping rather than a persistent subject-oriented entity.

Key Information Stored

The table contains nine documented columns. The most significant are:

• PARTY_ID — The party identifier from the TCA party model that the subsidiary is mapped to during upgrade.
• SUBSIDIARY_ID — The legacy GL subsidiary identifier; foreign key to GL_IEA_SUBSIDIARIES. This is the primary business-key candidate for the mapping.
• LEDGER_ID — The ledger associated with the subsidiary and its mapping, tying the upgrade to a specific accounting ledger.
• LEGAL_ENTITY_ID — The legal entity identifier; foreign key to FV_LEGAL_ENTITIES. This links the subsidiary to the legal-entity construct used post-upgrade.
• CREATED_BY, CREATION_DATE — Standard WHO audit columns recording who created the mapping row and when.
• LAST_UPDATED_BY, LAST_UPDATE_DATE — Standard WHO audit columns recording the most recent modification of the mapping row.
• LAST_UPDATE_LOGIN — Standard audit column capturing the login under which the last update occurred.

No surrogate primary-key column is documented in the physical schema beyond the business columns above; the mapping is keyed by the subsidiary-to-entity association. The two foreign keys (SUBSIDIARY_ID to GL_IEA_SUBSIDIARIES and LEGAL_ENTITY_ID to FV_LEGAL_ENTITIES) are the defining structural constraints.

Common Use Cases and Queries

Because the table is consumed only during upgrade, the dominant use cases are upgrade validation and post-upgrade reconciliation. A typical validation query confirms that every subsidiary in scope has a corresponding mapping row and that the resolved legal entity is the expected one:

• Identify unmapped subsidiaries: query GL_IEA_SUBSIDIARIES left-joined to FUN_SUBSIDIARY_PARTY_MAPPINGS on SUBSIDIARY_ID where PARTY_ID or LEGAL_ENTITY_ID is null.
• Reconcile subsidiaries to legal entities: join FUN_SUBSIDIARY_PARTY_MAPPINGS to FV_LEGAL_ENTITIES on LEGAL_ENTITY_ID to confirm entity naming and operating unit alignment.
• Audit conversion timing: use CREATION_DATE and LAST_UPDATE_DATE to determine when mappings were generated or revised during the upgrade, and CREATED_BY to attribute the run.
• Ledger-level reporting: group mappings by LEDGER_ID to verify that all subsidiaries were converted within the intended ledger scope.

Typical SQL pattern: SELECT m.SUBSIDIARY_ID, m.PARTY_ID, m.LEDGER_ID, m.LEGAL_ENTITY_ID FROM FUN.FUN_SUBSIDIARY_PARTY_MAPPINGS m WHERE m.LEDGER_ID = :ledger_id ORDER BY m.SUBSIDIARY_ID. Because the table is inactive after upgrade, production reporting should not depend on it; it is primarily an audit and troubleshooting source.

Related Objects

• GL_IEA_SUBSIDIARIES — referenced via FUN_SUBSIDIARY_PARTY_MAPPINGS.SUBSIDIARY_ID; the source of the legacy subsidiary records that are upgraded.
• FV_LEGAL_ENTITIES — referenced via FUN_SUBSIDIARY_PARTY_MAPPINGS.LEGAL_ENTITY_ID; the target legal-entity construct for the upgraded subsidiaries.
• TCA party tables (HZ_PARTIES and related) — resolved through PARTY_ID, providing the party identity assigned to each subsidiary.
• FUN_INTERCOMPANY_ORGS and related FUN intercompany organization setup tables — the downstream objects that receive the upgraded organizations after mapping.

Given its upgrade-only lifecycle, the table should be treated as a migration reference object; DBA activity is limited to validation, and no ongoing application processing references it once the upgrade is complete.