R12 Financials Overview and new features at a glance (PART 1)

Why R12:

Release 12 is defined as “The Global Business Release.” Global is not just a geographic perspective, but also a comprehensive perspective; release 12 functionality spans across both industries and business functions.
•Flexible, centralized, global accounting structure
•300+ enhancements to best practice business processes
•Comprehensive governance, risk and compliance platform
•Truly integrated performance management
•Real-time profitability analysis
•Unified financial and operational analytic applications
•Integration with core industry applications
•Self-service report formats and publicationSuperior ownership experience

New architecture and benefits:

The major components of the new architecture include:
•Multi-Org Access Control
•Ledger and Ledger Sets
•Subledger Accounting
•Tax Engine
•Intercompany
•Bank Model

Benefits of the new architecture include:
•Maintain 1 Ledger with 1 OU for each Company (LE)
-Get privacy for each company’s data
-Manage each company’s national and local compliance
•Combine many companies’ ledgers in a set
-Share GL services and workload
-Get combined data
•Use MOAC to enable access to many OUs
-Process in and report across many Companies’ Operating Units


MOAC: Multi-Org Access Control:
MOAC provides role based access to Operating Units, and allows you to perform multiple tasks across operating units without changing responsibilities.


Subledger Accounting:
Subledger accounting provides centralized rules and a common repository, and global control of your accounts. Features include:
•Accounting Rules
-SarBox & 8th Dir.
-User Editable
•Subledger Daybooks (Journals)
•Subledger Balancing
•Reports, inquiries, open items, et cetera
•Multiple Representations
•Common Posting to GL Ledgers
•Real time or Periodic

Benefits of subledger accounting are:
•Faster, Easier Reconciliation
•Corporate Rules = Accounting Standardization
•Local Rules = Improved Local Compliance
•Automate “Apples to Apples” Adjustments
•Improved Audit- ability
•Improved Internal Control

Ledger:

•One Repository of Financial Truth
•Implements the 4 C’s:
–Chart of Accounts
–Currency
–Calendar
–Accounting Convention
•Example:
–The balance on Creditors (COA)
–is 4.2M Eur (Currency)
–on March 31, 2006 (Calendar)
–according to IAS/IFRS definitions (Accounting Convention)


Ledger Sets:
Ledger sets provide global information at a glance. Ledger sets share a chart of accounts and a calendar. The key benefits to many Ledgers in one set are:
•Decision-driving business information always available
•Simpler processing and General Ledger management
•Data and definitions that can be shared and secured


Ledger Architecture:
Typical Ledger Sets:
•All IAS/IFRS or US GAAP ledgers
•26 Subs in 1 country
•35 countries in 1 region


Legal Organization:
Legal Entities (Les) such as Parent companies, own or control subsidiaries. There are no group entities
•LEs pay the taxes and therefore need tax registrations
•Trade between LEs needs intercompany
•LEs own the money and bank accounts
•LEs file the accounts and take care of accounting
•LEs comply with whatever needs compliance: “legal” in LE


Enhanced Legal Support:
•Did not replace GRE/LE - employer
•Added TCA parties for the Authorities
•Added a Legal Entity Configurator
•Introduced the following new terms:
-Jurisdiction: A legislative category and territory, has legal rules
-Legal Authority: Legal body who enforces legislation, collects fees / taxes, etc
-Legal Function: Functions that companies are required to perform (e.g. produce yearly report, pay taxes, etc.)
-Legal Associations: Mapping companies to Ledgers, BSVs, OUs and other system entities


Examples of using Legal Entities:
•Accounting Setup Manager: Assign books, bookkeeping rules and currency management to your registered companies
•EBusiness Tax: Have your registered companies calculate, file, and pay the transaction taxes they owe
•Intercompany: Do business between and across your registered companies with full legal documentation
•Bank Model: Have your registered companies use their money to pay their bills, etc.

Flexfield Concepts

Flexfield in Oracle Apps - Oracle Apps forms and reports are designed to be flexible and to accommodate many kinds of business rules for a wide variety of situations. Along with the innumerable predetermined fields that appear on each screen, most screens can accommodate the entry of additional information through the use of flexfields.

Types of Oracle Apps Flexfields:

1. Key Flexfield:
1.1 Most organizations use ”codes” made up of meaningful segments (intelligent keys) to identify general ledger accounts, part numbers, and other business entities. Each segment of the code can represent a characteristic of the entity. Oracle Applications store these ”codes” in key flexfields.
1.2 Key flexfields are flexible enough to let any organization use the code scheme they want, without programming. One has to decide what each segment means, what values each segment can have, and what the segment values mean. An organization can define rules to specify which segment values can be combined to make a valid complete code (also called a combination). One can also define relationships among the segments.
1.3 Key flexfields are dynamic in the sense that they are used throughout the Applications to uniquely identify information - GL accounts, inventory items etc, that every business needs to keep track of.

2. Descriptive Flexfield:
2.1 Descriptive Flexfields (DFFs) enable to capture additional pieces of information from transactions entered into Oracle Applications. Descriptive flexfields provide customisable ”expansion space” on your forms.
2.2 One can use descriptive flexfields to track additional information, important and unique to your business that would not otherwise be captured by the form.
2.3 Each field or segment in a descriptive flexfield has a prompt, just like ordinary fields, and can have a set of valid values.
2.4 An organization can define dependencies among the segments or customize a descriptive flexfield.

Flexfield Concepts:

1. Segment:
@ A single sub–field within a flexfield.
@ Represented in the database as a single table column.
@ Usually describes a particular characteristic of the entity identified by the flexfield
@ Determines the structure of the Key flexfield (say chart of accounts).
@ Each segment requires a value set to be defined and assigned.
@ One has to be very clear on how many segments are required, their order and validation.

These decisions affect the definition of value sets and their values.

2.Value, Validation (Validate), Value set:
@ Oracle Application Object Library uses values, value sets and validation tables as important components of key flexfields, descriptive flexfields, and Standard Request Submission. The end user enters a segment value into a segment while using an application.
@ Generally, the flexfield validates each segment against a set of valid values (a ”value set”) that are usually predefined. One can share value sets among segments in different flexfields, segments in different structures of the same flexfield, and even segments within the same flexfield structure. Value sets can be shared across key and descriptive flexfields.

Because the conditions one specifies for the value sets determine what values to be used with them, both the values and the value sets should be planned at the same time.

3. Structure:
A flexfield structure is a specific configuration of segments. If you add or remove segments,
or rearrange the order of segments in a flexfield, you get a different structure. You can
define multiple segment structures for the same flexfield (if that flexfield has been built to
support more than one structure).

Organizations in Oracle Apps

I.Organization in Oracle Applications

Definition of Organization:

Organization is an entity to which different types of transactions, that are recorded, are identified. A transaction is recorded for a particular kind of Entity, in other words, Organization.

Need for Organization:

1.Use a single installation of any Oracle Applications product to support any number of organizations, even if those organizations use different sets of books.
2. Define different organization models

3. Support any number of legal entities within a single installation of Oracle Applications.
4. Secure access to data so that users can access only the information that is relevant to them.
5. Sell products from a legal entity that uses one set of books and ship them from another legal entity using a different set of books, and automatically record the appropriate intercompany sales by posting intercompany accounts payable and accounts receivable invoices.
6. Purchase products through one legal entity and receive them in another legal entity.


II. Types of Organizations

The types of Organizations are based on the business needs of an enterprise. These also depend on the purpose for which an Organization is created. An Organization could be Internal or External. Broad grouping of Organization is as follows:

A. Business Unit
B. Headquarters
C. Divisions / Departments / Branch
D. Plant / Operations Unit
E. Product Lines

These are considered for reporting purposes. An External Organization could be Agents or Tax Authorities. By categorizing an Organization as External, employees cannot be assigned.

Classification of Organizations:

The Classification of Organizations decides the data flow of your Enterprise. The following are the classifications to which an Organization can fall into.

1. Set of Books:

If the business need requires having more than one Set of Books, then the installation automatically becomes Multi Organizational. Oracle General Ledger secures transaction information (such as journal entries and balances) by set of books. When you use Oracle General Ledger, you choose a responsibility that specifies a set of books.

2. Business Group:

The Business Group represents the highest level in the Organizational Structure. All the human resources information is stored at this level. The employees are assigned at this level. All the Sets of Books that are attached to a Business Group share the employees within that Business Group.

3. Legal Entity:

This is an Organization which represents the legal Company for which the fiscal and tax reports are prepared. This is presently available in the United States Federal Reporting context.

4. Balancing Entity:

This is the accounting entity for which the financial reports are prepared. This is the mandatory segment in the Accounting Flexfield in Oracle General Ledger. There could be multiple companies that come under the same Legal Entity and each company’s financial statements match tally within itself.

5. Operating Unit:

An Operating Unit is generally your branch office or a sales division or a department. The subledgers like Payables, Receivables, Purchasing and Order Management are configured based on operating unit. The users attached to this subledger would see the data for only the operating that has been attached to the respective responsibility.

6. Inventory Organization:

This is the Organization that tracks the inventory transactions and balances and the activities of an organization that manufactures or distributes or stores products. Manufacturing units, warehouses, distribution offices are normally classified into this category. Oracle Manufacturing Suite modules are based on Inventory Organizations.

7. HR Organization:

This class of Organization represents the work structure of an enterprise. They usually represent the functional management, or reporting groups that exist within a business group.

8. Project Organizations:

These classes of Organizations are used in Oracle Projects to monitor and transact on different kinds on projects, created in Oracle Projects Suite. This document discusses in detail on Project Organizations in the coming sections.

9. Asset Organizations:

This is a new class of Organization introduced in Release 11i. An asset organization is an organization that allows you to perform asset–related activities for a specific Oracle Assets corporate depreciation book. Oracle Assets uses only organizations designated as asset organizations

III. Setup Organizations

The following are the simplified setup steps to be followed to create an organization structure in a new environment:
1) Define Organization Structure.

· This is a pen and paper process of setting up the organizations structure.

· Assign organization classification in the following order:

(1) Legal entities, (2) Operating units, and (3) Inventory organizations.

2) Define Sets of Books. Use Define Set of Books window to enter a set of books. Responsibilities used to assign sets of books:

a) Assets - Setup -> Financials -> General Ledger -> Set of Books

b) General Ledger - Setup -> Set of Books -> Define

c) Inventory - Setup -> Financials -> Books

d) Payables - Setup -> Set of Books -> Define

e) Purchasing Receivables - Setup -> Organizations -> Set of Books

f) Receivables - Set Up -> Financials -> Books

g) Government General Ledger - Setup -> Set of Books -> Define

3) Define Organizations. Use Define Organizations window to define organizations. · Responsibilities used to assign organizations:

i) Inventory - Setup -> Organizations -> Organizations

ii) Purchasing - Setup -> Organizations -> Organizations

iii) Order Entry / Shipping - Set Up -> Organizations -> Organization

iv) Projects - Setup > Human Resources -> Organizations -> Define

v) Receivables - Set Up > System -> Organization

vi) Government Purchasing - Setup -> Organizations -> Organizations

vii) Government Receivables - Set Up -> System -> Organization ·

Define Business Groups. (Optional)

· Define if you have multiple business groups or do not use default business group.

· You must have at least one business group. Oracle Applications supplies default business group, Setup business Group (fresh install).

· If you define business group next step must be to associate business groups with a responsibility and verify the HR: Business Group profile option. (See step 5.)

4) Define Organization Relationships. Use the Define Organization window to define organization relationships by assigning classifications to each organization.

a) Classification of an organization can be any combination in the following order: i) Legal entities, ii) Operating units, and iii) Inventory organizations.

b) Legal entities must have a location specified. (Zoom to Define Locations window.)

5) Define Responsibilities. Use the Define Responsibility window to define responsibilities for each operating unit. Responsibilities used to assign responsibilities:System Administrator - Security -> Responsibility -> Define If you have multiple business groups, you must associate each responsibility with one and only one business group. Use the HR: Business Group system profile option to associate a responsibility with a business group.

6) Set MO:Operating Unit Profile Option for Each Responsibility.

MO:Operating Unit profile option must be set.

· System Administrator - Profile -> System

· Set profile option to appropriate operating unit id (ORG_ID). You must set the default-operating unit setting MO:Operating Unit at the site level.

7) Run Convert to Multiple Organization using Adadmin utility. Process replicates seed data to all operating units that have been defined. This step is irreversible. Adadmin will fail if previous steps have not been completed. Concurrent managers must be down and no one should access the database. If adadmin fails during conversion and you are prompted to proceed as if successful, never select Yes, as the conversion process has already begun, and steps that may be missed during the conversion process will need to be manually created and be difficult, costly and timely to recreate.

8) Define Inventory Organization Security (Optional). Restricts manufacturing users to specific organizations.

9) Change Order Entry Profile Options (Optional). For Release 11: OE:Item Validation Organization profile option is set a responsibility level if operating units have different item validation organizations.
For Release 11i: Attach the submenu ‘ONT_SETUP’ and function ‘Setup OM parameters’ to any main menu (AR / OM). Switch to AR / OM Responsibility and
1. Open OM_Parameters Menu.
2. Give a Name for OPERATING UNIT and
3. For Item Validation Organization, Select Inventory Organization
4. Save your work

10) Update Profile Options Specific to Operating Units.

Set profile options at the responsibility level e.g.:i) AR: Receipt Batch Source ii) AR: Transaction Batch Source iii) OE:Item Validation Organization – Only for Release 11 iv) OE: Set of Books v) GL: Set of Books Sequential Numbering

Responsibilities used to assign profile options:System Administrator - Profile -> System. Refer to individual Oracle Financial Applications Products User's Guides for specific information on profile options that need to be set.

11) Set up Oracle Applications Products. OE, PA, PO, AR and Sales Compensation must be set up for each operating unit it they the product groups are to be used. FA, GL INV and the rest of the Oracle Manufacturing product do not need to be set up for each operating unit.

12) Secure Balancing Segment Values by Legal Entity. (Optional) Use the Define Security Rule window to create rules that secure data entry of balancing segment values for each legal entity.· Security rule elements specify a range of values to be included or excluded. Use the Assign Security Rules window to assign the same rule(s) to all responsibilities associated with the legal entity's operating units. Define additional rules and assign them to all responsibilities associated with relevant operating units.

13) Run the Setup Validation Report to Identify Setup Problems. Data for disabled fields on Enter Customer and Enter Supplier Window must be deleted.

14) Header information is shared across operating units and if you do not choose to delete the data, you must edit the database manually. All responsibilities in one operating unit must share the same profile option values and sequence numbering option.

Create Locations:

Use the Define Location window to define names and addresses for the locations you use within your enterprise. You define each location once only. This saves you time if you have multiple organizations with the same location. You should define locations for your legal entities and inventory organizations. Oracle Applications products use locations for requisitions, receiving, shipping, billing, and employee assignments.

Cross Business Groups

With Cross Business Group Access (CBGA) the business group now exists at one level lower and you can access organizations, resources and projects across business groups within a hierarchy

IV.Organizations in Projects Accounting

Projects can be controlled based on the Organization Classifications. The following are the basic classifications:

Project / Task Owning Organization. Project/Task Owning Organizations are organizations that can own projects and/or tasks in the operating unit.

Project Expenditure/Event Organization. Expenditure/Event Organizations are organizations that can own project events (labor and non–labor) and can incur expenditures for projects in the processing operating unit.

Project Invoice Collection Organization. If your business decentralizes its invoice collection within an operating unit, you must enable the Project Invoice Collection Organizations classification for each organization in which you want to process invoices.

Project Manufacturing Organization is one that links your Project between Inventory Organization and Projects. This is a new feature in Release 11i.

Billing Schedule Organizations are organizations that have their own billing schedules. Any organization in the operating unit’s business group can have its own billing schedules.

Resource Organizations are organizations that own resources and/or resource budgets. Any organization in the operating unit’s business group can own non–labor resources. Only HR organizations can have employees assigned to them. Oracle Projects does not have a classification requirement for an organization to own non–labor resources.

Relationships between Organizations

1. Legal Entities Post to a Set of Books

2. Operating Units Are Part of a Legal Entity

3. Inventory Organizations are Part of an Operating Unit

4. Inventory Organization Determines Items Available to Order Management

5. Inventory Organization Determines Items Available to Purchasing

6. Project Organizations are attached to Business Group

7. Employee availability within Operating Units depends on the Business Group to which the OU is attached.

8. A Project Organization has to be classified as HR Organization if employees are planned to be assigned.

9. A Project Manufacturing Organization should have an additional classification of Inventory Organization to be able to handle inventory items.


V. Organization Hierarchy

In Oracle Applications, organization hierarchies show reporting lines and other hierarchical relationships among the organizations in your enterprise. An organization hierarchy illustrates the relationships between your organizations. When you define a hierarchy, you tell Oracle Projects which organizations are subordinate to which other organizations. The topmost organization of an organization hierarchy is generally the business group.


In addition to the primary reporting hierarchy, you can set up in as many other organization hierarchies as you need. You can create as many organization hierarchies as you need for different reporting and processing needs, and you can create multiple versions of an organization hierarchy. Oracle Projects uses the hierarchy version to determine which organizations are used for reporting and processing.

The following organization hierarchy versions are assigned in Oracle Projects:

A Project/Task Owning Organization Hierarchy Version is assigned to each operating unit.
An Expenditure/Event Organization Hierarchy Version is assigned to each operating unit.
A Default Reporting Organization Hierarchy Version is assigned to each operating unit. This hierarchy version can be overridden at reporting time.
A Project Burdening Hierarchy Version is assigned to each business group.

Start Organization

This is the branch of your organization hierarchy that you specify in Oracle Projects as the top of your hierarchy. When you choose a start organization as a reporting parameter, the start organization and all organizations below it are included in the report.

You create organization hierarchies in the Organization Hierarchy window. Always define hierarchies from the top organization down. You must define the top organization in the hierarchy, and at least one organization subordinate to it. The organization hierarchy you define here appears in a list of values in the Implementation Options window.


To create an Organization Hierarchy,

1. Enter a unique name for the hierarchy, and check Primary if it is your main reporting hierarchy.
2. Enter the version number and start date for the hierarchy. You can copy an existing hierarchy.
3. Query the top organization name in the Organization block.
4. In the Subordinates block, select the immediate subordinates for the top organization.
5. To add organizations below one of these immediate subordinates, check the Down check box for the organization. The Organization block now displays the organization you selected. You can add subordinates to this organization. To return to the previous level, check the Up check box.

To change the hierarchy

1. Query the name of the hierarchy.
2. In the Version field, use the Down Arrow to move through existing versions of the hierarchy until you reach a version number for which no other data appears. Enter the start date for the new version.
Note: Overlapping versions of a hierarchy cannot exist. Whenever you enter a new version of a hierarchy, the system automatically gives an end date to the existing version. Oracle HRMS retains the records of obsolete hierarchies, so you do not lose any historical information.
3. Query the top organization name in the Organization block.
4. In the Subordinates block, select the immediate subordinates for the top organization.
5. To add organizations below one of these immediate subordinates, select the Down check box for the organization. The Organization block now displays the organization you selected. You can add subordinates to this organization. To return to the previous level, select the Up check box.


Project/Task Owning Organization Hierarchy

You assign a project/task owning organization hierarchy to the operating unit to control which organizations can own projects and tasks. To own projects and/or tasks in the operating unit, an organization must have all of the following characteristics:
1.The organization must belong to the project/task organization hierarchy assigned to the operating unit.
2. The organization must have the project/task owning organization classification enabled.
3. The project type class must be permitted to use the organization to create projects. This permission is determined when you define the organization.
4. The organization must be active as of the system date.

Expenditure/Event Organization Hierarchy
You assign an expenditure/event organization hierarchy to the operating unit to control which organizations have the following capabilities:
1. incur expenditures
2. own project events
3. be assigned to a resource list as a resource

Default Reporting Organization Hierarchy

You specify an organization hierarchy and version to indicate which organization hierarchy of a Business Group you want Oracle Projects to use as the default reporting organization hierarchy.

You specify a start organization to indicate which branch of your organization hierarchy you want Oracle Projects to recognize as the top of your hierarchy for reporting purposes. If you want to use your entire organization hierarchy, your top organization (generally the business group) is the start organization. For example, if you define your organization hierarchy with four divisions under the top organization, you can specify one division as the start organization. Oracle Projects consequently recognizes only that division and its subordinate organizations as its default reporting hierarchy.

Project Burdening Organization Hierarchy

For each Business Group, you specify a Project Burdening Organization Hierarchy and Version. Oracle Projects uses the Organization Hierarchy/Version to determine the default Burden Multiplier when compiling a Burden Schedule.

To specify project burdening hierarchies:

1. Select an Oracle Projects responsibility with access to the Organization window associated with the Business Group for which you are entering Legal Entities and Operating Units.
2. Navigate to the Organizations window (Setup > Human Resources > Organizations > Define).
3. Define an organization or query organizations that you defined as a business group. You must define the hierarchy before you designate it as the project burdening hierarchy.
Depending on your enterprise organization structure and business process, it is possible for the Project Burdening Hierarchy Version to be different from the Project/Task Organization Hierarchy Version, Expenditure/Event Organization Hierarchy Version, or Default Project Reporting Organization Hierarchy Version that you defined for any operating units associated with the business group. The Cost Distribution processes will not burden expenditures for expenditure organizations that are not in the Project Burdening Hierarchy.

If you add a new organization to the Project Burdening Hierarchy Version

If you add a new organization to the Project Burdening Hierarchy Version, you must
1. add new burden multipliers for that organization in the appropriate burden schedules, or
2. use the multipliers inherited from the parent organization as the burden multipliers for the organization

If you want to add burden multipliers to a particular schedule version for the organization, you need to compile the affected schedule version. If you use the parent organization multipliers, you must submit the PRC: Add New Organization Burden Compiled Multipliers process. This process adds multipliers for this organization to all burden schedules versions for which you did not explicitly add multipliers. If you do not run this process, you will encounter a rejection reason of ’Cannot find compiled multiplier’ for transactions charged to this organization.



VI.Profile Options

HR:Business Group
Use this profile option to attach a Business group.

HR: Security Profile
Use this profile option to point your responsibility to a specific business group.

HR: User Type
Use this profile option to classify the type of HR installation your enterprise has

HR: Cross Business Group
Use this profile option to enable Cross Business Group access functionality.

MO: Operating Unit
Use this profile option to control which operating unit a particular responsibility corresponds to only if you have implemented multiple organization support.

Multi-Org 101

Multi-Org Architecture:
1. Before Multi-Org – Need one server for every set of Books implemented
2. With Multi-Org – One server, multiple sets of Books
3. The multiple organization structure simply partitions key tables to allow for an ORD_ID number per row
3.1 Used to provide security and data segregation.
4. Criteria used to partition tables includes:
4.1 The table contains a GL Account Code (code combination ID).
4.2 There is a business reason for the table to be partitioned (for example, the entity should not be shared).
4.3 The table contains transaction data.
4.4 The table is an interface table where data being loaded is partitioned.
4.5 The table includes a foreign key to a partitioned table and is accessed independently (in other words, not just as a child of a partitioned table).

Centralized Processing:
1. Centralized GL, AP, AR, PO, OE, and PA
1.1 Clients can use your balancing segment within your Chart of Accounts to segregate legal entity data
2. Decentralized GL, AP, AR, PO, OE, and PA
2.1 Client must have an Operating Unit for each group

Multi-Org Relationships:
1. Business Group, Legal Entity and Master Inventory Organization are all separate structures
2. Business Group and Legal Entity are linked through Responsibilities using the System Profile Options
3. Legal Entities and Inventory Organizations are linked by Set of Books

Why do you need Multi_org?
1. We only have one Set of Books, Business Group, Legal Entity and Operating Unit. Why Run Multi-Org?
1.1 Future growth and acquisitions
1.2 Change in company directions
1.3 Conversion from single org to multi-org is
1.3.1 Difficult in Release 10
1.3.2 Required in Release 11i and 12i

High Level Multi-Org Setup Steps:
1. Develop the organization structure
2. Define sets of books
3. Define organizations (Business Group, Legal Entity, Operating Unit, Inventory Orgs)
4. Define organization relationships
5. Define responsibilities
6. Update Profile Options Specific to Operating Units
7. Run the Setup Validation Report (recommended)

Multi-Org model as it relates to organizations:
· A ‘Business Group’ is the highest level of the structure and has no accounting impact. The ‘Business Group’ determines which employees will be available to ‘Sets of Books’ and ‘Operating Units’ related to that ‘Business Group’
· ‘Set of Books’ is the highest level which impacts the accounting side of the business
· ‘Set of Books’ is associated with a single ‘Business Group’, multiple ‘Sets of Books’ may be associated with a single ‘Business Group’
· Each ‘Set of Books’ may have a different chart of accounts structure, calendar or functional currency
· Each ‘Legal Entity’ is associated to a single ‘Set of Books’, multiple ‘Legal Entities’ may be associated with the a single ‘Set of Books’
· Each ‘Operating Unit’ is associated with a single ‘Legal Entity’, multiple ‘Operating Units’ may be associated with a single ‘Legal Entity’
· An ‘Inventory Organization’ may be associated with any ‘Operating Unit within the same ‘Set of Books’

New Operating Units - Critical Steps:
1. Oracle provides the seed data replication program as a concurrent program
2. May need to run the Replicate Seed Data process if seeded data does not replicate correctly
3. Remember to set up Responsibilities and System Profile Options (GL: Sets of Books and MO: Operating Unit) for each new OU defined