So let’s look at the relationships LE have to other E-Business suite objects.
1- Accounting Structures
In the General Ledger Set Up a Legal Entity can be mapped to
- A Single Ledger
- One or more Balancing Segment Values (aka Company Code) within a ledger.
There is no explicit mapping of Legal Entity to an OU, the relationship is derived from the ledger assigned to the OU and the Legal Entity mappings to ledgers as detailed above.
So how might you set up your LE in relation to your other set up in financials? There are two implementation models
1:Many
- LE are mapped to the Balancing Segment Value (BSV, aka Company code) within a Ledger, so multiple LE are accounted for in a ledger.
- An OU will have one Ledger assigned so transactions for many LE are processed and accounted in a single OU
- A single LE is mapped to a Ledger
- An OU will have one Ledger assigned
- Therefore an OU only has one LE (that meas it is easy to derive the LE given the OU)
That depends where the LE are registered.
The 1:M model is recommended and preferred in the US, the 1:1:1 model is recommended for most non US regions
The short answer is sort of. Which is not much help to anyone, hopefully you will have a few moments to read on and I can explain myself. This post assumes that you understand the relationship between Legal Entities and Ledgers which I discussed in an earlier post.

When I am in Payables or Receivables the LE is stamped on the transactions and used to identify the Legal Owner for Legal reporting as well as Tax calculation. The invoice exists within an OU and that OU has a ledger which will account the transactions, if that has more than one LE associated with it then a hierarchy of LE derivation is used to default an LE, the last resort being the DLC.
For example in AR the Legal Entity derivation hierarchy for transactions is
- Transaction Type
- Batch Source
Assigning a LE to a transaction type or batch source is optional and only the LE’s mapped to the Ledger associated with the OU are available to assign.
So in R12 we have much better support for many LE accounted in a single OU as we clearly mark the LE on the transactions.
A Ledger may have one LE or many LE attached.
An OU may also have one LE or many LE attached.
A BSV may have one LE or many LE
An LE may have many BSV
An LE should be accounted in a single Primary Ledger (of course there may be a number of secondary Ledgers for the same LE).
FAH VS HFM
1)Consolidate
FAH – consolidates transactions from multiple transaction systems into a single accounting system.
HFM – consolidates accounting entries from multiple accounting systems
2)Apply Rules
FAH – rules are rleated to how to account for a transaction based on it’s attributes
HFM – Rules are around how to consolidate, e.g. % ownership, etc
3)Used for reporting
FAH – Subledger reports
HFM – Financial reports, consolidate income statement etc.
[ 本帖最后由 Frenkie1979 于 2010-5-23 14:18 编辑 ]
In the real world a Legal Entity (LE) can enter into contracts, own cash (bank accounts), employ people, pay taxes, be sued and simlar. In Oracle Financials Release 12, a whole new product; Legal Entity Configurator, was created to manage them. We allow you to define your real world Legal Entities and then map them to the E-Business Suite objects and structures. Transactions are stamped with an owning (first party) Legal Entity and that will be used to drive tax, accounting, intercompany and Legal Reporting.
So let’s look at the relationships LE have to other E-Business suite objects.
1- Accounting Structures
In the General Ledger Set Up a Legal Entity can be mapped to
A Single Ledger
One or more Balancing Segment Values (aka Company Code) within a ledger.
2 - Operating Unit
There is no explicit mapping of Legal Entity to an OU, the relationship is derived from the ledger assigned to the OU and the Legal Entity mappings to ledgers as detailed above.
So how might you set up your LE in relation to your other set up in financials? There are two implementation models
1:Many
LE are mapped to the Balancing Segment Value (BSV, aka Company code) within a Ledger, so multiple LE are accounted for in a ledger.
An OU will have one Ledger assigned so transactions for many LE are processed and accounted in a single OU
1:1:1
A single LE is mapped to a Ledger
An OU will have one Ledger assigned
Therefore an OU only has one LE (that meas it is easy to derive the LE given the OU)
So what model should you use?
That depends where the LE are registered.
The 1:M model is recommended and preferred in the US, the 1:1:1 model is recommended for most non US regions.
由于我是做技术的,就从基表下手吧
在R12中有一个视图
gl_ledger_le_v
内容如下:
select lg.ledger_id
,lg.name ledger_name
,lg.short_name ledger_short_name
,cfgdet.object_id legal_entity_id
,le.name legal_entity_name
,reg.location_id location_id
,hrloctl.location_code location_code
,hrloctl.description location_description
,lg.ledger_category_code
,lg.currency_code
,lg.chart_of_accounts_id
,lg.period_set_name
,lg.accounted_period_type
,lg.sla_accounting_method_code
,lg.sla_accounting_method_type
,lg.bal_seg_value_option_code
,lg.bal_seg_column_name
,lg.bal_seg_value_set_id
,cfg.acctg_environment_code
,cfg.configuration_id
,rs.primary_ledger_id
,rs.relationship_enabled_flag
from gl_ledger_config_details primdet
,gl_ledgers lg
,gl_ledger_relationships rs
,gl_ledger_configurations cfg
,gl_ledger_config_details cfgdet
,xle_entity_profiles le
,xle_registrations reg
,hr_locations_all_tl hrloctl
where rs.application_id = 101
and ((rs.target_ledger_category_code = 'SECONDARY' and rs.relationship_type_code <> 'NONE') or
(rs.target_ledger_category_code = 'PRIMARY' and rs.relationship_type_code = 'NONE') or
(rs.target_ledger_category_code = 'ALC' and rs.relationship_type_code in ('JOURNAL', 'SUBLEDGER')))
and lg.ledger_id = rs.target_ledger_id
and lg.ledger_category_code = rs.target_ledger_category_code
and nvl(lg.complete_flag,
'Y') = 'Y'
and primdet.object_id = rs.primary_ledger_id
and primdet.object_type_code = 'PRIMARY'
and primdet.setup_step_code = 'NONE'
and cfg.configuration_id = primdet.configuration_id
and cfgdet.configuration_id(+) = cfg.configuration_id
and cfgdet.object_type_code(+) = 'LEGAL_ENTITY'
and le.legal_entity_id(+) = cfgdet.object_id
and reg.source_id(+) = cfgdet.object_id
and reg.source_table(+) = 'XLE_ENTITY_PROFILES'
and reg.identifying_flag(+) = 'Y'
and hrloctl.location_id(+) = reg.location_id
and hrloctl.language(+) = userenv('LANG');
这几张表的介绍如下:
gl_ledger_config_details
Primary ledgers and their associated secondary ledgers, legal entities, reporting currencies and setup.
gl_ledgers
Ledger definition
gl_ledger_relationships
Relationships between ledgers
gl_ledger_configurations
Primary ledgers
gl_ledger_config_details
Primary ledgers and their associated secondary ledgers, legal entities, reporting currencies and setup.
xle_entity_profiles
XLE_ENTITY_PROFILES stores the general information, which identifies a Party with the classification of Legal Entity
xle_registrations
XLE_REGISTRATIONS stores the detailed registration information of Legal Entities and Establishments, such as registration number, place of registration, and legal address
hr_locations_all_tl
Translated location codes and descriptions.
将该语句精简一下:
select lg.ledger_id --分类帐
,cfgdet.object_id legal_entity_id --法人
,lg.currency_code
,lg.chart_of_accounts_id
,rs.primary_ledger_id
from gl_ledger_config_details primdet
,gl_ledgers lg
,gl_ledger_relationships rs
,gl_ledger_configurations cfg
,gl_ledger_config_details cfgdet
where rs.application_id = 101
and ((rs.target_ledger_category_code = 'SECONDARY' and rs.relationship_type_code <> 'NONE') or
(rs.target_ledger_category_code = 'PRIMARY' and rs.relationship_type_code = 'NONE') or
(rs.target_ledger_category_code = 'ALC' and rs.relationship_type_code in ('JOURNAL', 'SUBLEDGER')))
and lg.ledger_id = rs.target_ledger_id
and lg.ledger_category_code = rs.target_ledger_category_code
and nvl(lg.complete_flag,
'Y') = 'Y'
and primdet.object_id = rs.primary_ledger_id
and primdet.object_type_code = 'PRIMARY'
and primdet.setup_step_code = 'NONE'
and cfg.configuration_id = primdet.configuration_id
and cfgdet.configuration_id(+) = cfg.configuration_id
and cfgdet.object_type_code(+) = 'LEGAL_ENTITY';
执行结果:
所以不同的LE可以连相同的ledger 是肯定的