Search Results to_le_id




Overview
Explore in AI Chat

Overview

APPS.FUN_INTER_ACCOUNTS_V is a reporting and integration view in the Oracle E-Business Suite (EBS) Financials schema, owned by the APPS account. It exposes the intercompany accounts configuration used by the Subledger Accounting and intercompany balancing infrastructure. The view presents the mapping between a "from" legal entity, a ledger, and a "to" legal entity, together with the accounting flexfield combination (CCID) that must be used for intercompany transactions of a given type. Because it is a view rather than a base table, it provides a read-only, consolidated presentation of intercompany account setup suitable for queries, concurrent programs, and integration extracts without requiring callers to be aware of the underlying storage split.

The view is especially relevant when searching on the FROM_LE_ID column, since that column identifies the originating legal entity for which an intercompany account rule applies. This makes the view a natural starting point for determining which intercompany accounts an originating legal entity will use when transacting with another legal entity within the same ledger.

Underlying Base Objects

The documented view text defines FUN_INTER_ACCOUNTS_V as a UNION of two source objects:

Both branches of the UNION project the identical column list: FROM_LE_ID, LEDGER_ID, TO_LE_ID, CCID, TYPE, TRANS_BSV, and TP_BSV. The view therefore flattens the two physical tables into a single logical result set, allowing consumers to retrieve the complete set of intercompany account definitions in one query. The presence of the ADDL table indicates that the intercompany account model supports a primary definition set supplemented by additional definitions, and the view deliberately merges both so that reporting does not omit the supplementary rows. No filtering predicate is documented on the UNION, so every row from each base table is exposed.

Key Columns

  • FROM_LE_ID — the legal entity identifier for the originating side of the intercompany relationship. This is the column most commonly used to drive queries against this view.
  • LEDGER_ID — the ledger identifier within which the intercompany relationship and its account mapping are defined.
  • TO_LE_ID — the legal entity identifier for the receiving or counterparty side of the intercompany relationship.
  • CCID — the code combination identifier pointing to the intercompany accounting flexfield combination applied to the transaction.
  • TYPE — classifies the intercompany account definition, distinguishing among the categories of intercompany rules maintained by the application.
  • TRANS_BSV — the balancing segment value associated with the transaction side of the relationship.
  • TP_BSV — the balancing segment value associated with the trading partner side of the relationship.

Together, FROM_LE_ID, LEDGER_ID, and TO_LE_ID form the natural business key for locating an intercompany account rule, while CCID supplies the actual account to be posted.

Common Use Cases and Queries

Typical uses include auditing intercompany account setup, extracting configuration for migration or reconciliation, and diagnosing intercompany balancing errors. A query keyed on the originating legal entity is the most frequent access pattern:

  • Retrieve all intercompany rules originating from a legal entity: SELECT ledger_id, to_le_id, ccid, type FROM apps.fun_inter_accounts_v WHERE from_le_id = :p_from_le_id;
  • Locate the account for a specific pair of legal entities: SELECT ccid FROM apps.fun_inter_accounts_v WHERE from_le_id = :p_from_le_id AND to_le_id = :p_to_le_id AND ledger_id = :p_ledger_id;
  • Join to GL_CODE_COMBINATIONS on CCID to display the concatenated account string for review or reporting.
  • Compare rule coverage across all originating legal entities by grouping on FROM_LE_ID and TYPE.

Because the view merges FUN_INTER_ACCOUNTS and FUN_INTER_ACCOUNTS_ADDL, queries automatically include supplementary definitions; consumers should be aware that duplicate-looking rows across the two base tables are possible and should be de-duplicated where business logic requires a single rule per combination.