Results for “xle_le_ou_ledger_v”

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

Overview

XLE_LE_OU_LEDGER_V is a read-only view owned by the APPS schema in Oracle E-Business Suite, defined under the XLE – Legal Entity Configurator product. Its name reflects its three principal dimensions: Legal Entity (LE), Operating Unit (OU), and Ledger. The view consolidates the configuration relationship between a primary ledger's assigned legal entity and the operating units and ledger configurations that are mapped to it, producing a single denormalized result set that spans ledger definitions, ledger relationships, legal entity profiles, registrations, addresses, and HR organization classification data.

In Oracle EBS 12.1.1 and 12.2.2, the Legal Entity Configurator is the foundation of the multi-organization and subledger accounting architecture. The XLE_LE_OU_LEDGER_V view serves as a reporting and integration convenience layer, allowing developers, report authors, and interfaces to obtain legal entity context alongside ledger and operating unit identifiers without writing the multi-table join themselves. The ETRM metadata records the object as VALID with owner APPS, indicating it is a supported, deployed database object in the reference environment.

Underlying Base Objects

The view is defined over eight documented base objects, all accessed through APPS synonyms: GL_LEDGERS, GL_LEDGER_CONFIGURATIONS, GL_LEDGER_CONFIG_DETAILS, GL_LEDGER_RELATIONSHIPS, HR_LOCATIONS_ALL, HR_ORGANIZATION_INFORMATION, XLE_ENTITY_PROFILES, and XLE_REGISTRATIONS. The definitive join path in the view text begins with GL_LEDGER_RELATIONSHIPS, filtered to APPLICATION_ID = 101, which isolates the ledger relationship records relevant to the General Ledger application.

From GL_LEDGER_RELATIONSHIPS the view resolves target ledgers (including secondary and ALC categories) through GL_LEDGERS, and derives a primary ledger through a second reference to GL_LEDGERS aliased PRIMARYLG. The primary ledger's configuration is obtained from GL_LEDGER_CONFIGURATIONS and GL_LEDGER_CONFIG_DETAILS, where OBJECT_TYPE_CODE is filtered to 'LEGAL_ENTITY'. This yields the legal entity identifier, which is joined to XLE_ENTITY_PROFILES for the entity name and profile attributes. Registration detail comes from XLE_REGISTRATIONS, which is tied to XLE_ENTITY_PROFILES via SOURCE_TABLE and IDENTIFYING_FLAG = 'Y', and then to HR_LOCATIONS_ALL for the registered address. Finally, HR_ORGANIZATION_INFORMATION is referenced twice (aliased O2 and O3) to attach the operating unit organization to the ledger.

Key Columns

• OPERATING_UNIT_ID – The organization identifier of the operating unit, sourced from O2.ORGANIZATION_ID in HR_ORGANIZATION_INFORMATION.
• LEDGER_ID, LEDGER_NAME, LEDGER_SHORT_NAME – Identity and descriptive attributes of the ledger from GL_LEDGERS.
• LEGAL_ENTITY_ID, LEGAL_ENTITY_NAME, LEGAL_ENTITY_IDENTIFIER – The legal entity associated with the ledger configuration, from XLE_ENTITY_PROFILES.
• ACTIVITY_CODE, SUB_ACTIVITY_CODE, TYPE_OF_COMPANY – Classifications of the legal entity used for statutory and reporting purposes.
• LE_EFFECTIVE_FROM, LE_EFFECTIVE_TO – Validity dates of the legal entity record.
• REGISTRATION_NUMBER – The identifying registration number from XLE_REGISTRATIONS.
• ADDRESS_LINE_1/2/3, REGION_1/2/3, TOWN_OR_CITY, POSTAL_CODE, COUNTRY – Registered address attributes from HR_LOCATIONS_ALL.

Common Use Cases and Queries

Typical uses include identifying which operating units belong to a given legal entity and ledger, validating configuration during implementations, and driving downstream reporting or integration extracts where legal entity context is required. A representative query follows:

SELECT operating_unit_id,
       ledger_id,
       ledger_name,
       legal_entity_id,
       legal_entity_name,
       registration_number
FROM  apps.xle_le_ou_ledger_v
WHERE  ledger_id = :p_ledger_id;

Because the view already filters on APPLICATION_ID = 101 and enforces the primary/secondary/ALC relationship rules, it can be used directly by report builders and conversion scripts without replicating the configuration logic. Practical caution applies: the underlying joins are configuration-driven, so results depend on properly maintained ledger relationships and legal entity assignments. The view is read-only and should not be used as the target of DML.