Fusion Enterprise Structures Versus EBS 1

Copyright 2013, Oracle and/or its affiliates. All rights reserved.

Oracle Fusion Enterprise Structures Release 9

Agenda

EBS Components vs. Fusion

EBS Chart of Accounts vs. Fusion

EBS GL vs. Fusion

EBS Operating Unit vs. Fusion Business Units

EBS versus Fusion

EBS Components Fusion Components

Product-Specific Setup Centralized Setup Across All Products Using Functional Setup Manager

Responsibility Data Role (automatically generated when BUs and Ledgers are defined)

Legal Entity Configurator Legal Entity Configurator accessed from Functional Setup Manager

Business Group Term Change: Enterprise

Establishment Term Change: Legal Reporting Unit

HCM Legal Entities defined in the HR Organizations page

HCM and Financial Legal Entities can be shared and are defined in the same page

PresenterPresentation NotesIn Fusion, Enterprise is equivalent to R12 EBS Business Group. An enterprise is nothing more than a collection of legal entities in a group. You should only define one and only one enterprise. A company would ONLY define multiple enterprises if you were a true conglomerate, such as GE.

You define the enterprise to capture the name of the deploying enterprise and the location of the headquarters. There is normally a single enterprise organization in a production environment. Multiple enterprises are defined when the system is used to administer multiple customer companies, or when you choose to set up additional enterprises for testing or development.

Establishment (a.k.a Legal Reporting Unit) is used for tax reporting purposes.

EBS versus Fusion

EBS Components Fusion Components

Operating Unit Term Change: Business Unit

No Spreadsheet to upload LEs, BUs, COA Values, COA Hierarchies, Ledgers, Banks and Bank Accounts

Integrated Spreadsheets to upload all via Functional Setup Manager

Agenda



EBS GL vs. Fusion


EBS Chart of Accounts versus Fusion COA EBS GL Fusion GL

Unified chart of accounts that includes segments, qualifiers and value sets

Separation of COA structure and instance

One Balancing Segment and a Secondary Tracking Segment

Three Balancing Segments; no secondary tracking segment

Management segment qualifier No management segment in V1 Dependent value set available No dependent value set in V1 Segment Qualifier Terminology Change: Segment Label

No Date Effective Hierarchy Date Effective Hierarchies

Segment Value Security at Segment level

Segment Value Security at Value Set level Note: Do not share the same value set for Company and Intercompany segments if securing Company values)

PresenterPresentation NotesCOA: In Fusion the chart of accounts model is framed around the concept of a chart of accounts structure, under which one or more chart of accounts structure instances can be created. A chart of accounts structure defines the key attributes for your chart of accounts, such as the number of segments, the segment sequences, the segment names, segment prompts, segment labels (e.g. natural account, primary balancing) and default value set. A chart of accounts structure can be shared across different chart of accounts structure instances.

COA Structure Instance: The chart of accounts used and exposed in user interfaces and processes. In what follows, we will refer to chart of accounts structure instance as merely Chart of Accounts (COA). By default, a COA inherits all the attributes of the COA structure, meaning that all instances of the same structure share a common shape, and have the very same segments and in the same order. However, at the COA instance level, you may override the default value set assignments for your segments, and also assign a unique account hierarchy that determines the parent/child relationships between the value set values. At the COA instance level, organizations can determine if they wish to allow dynamic insertion where new account combinations can be dynamically generated instead of having to be pre-created.

3 Balancing Segments: Primary balancing segment (required) and the second and third are optional.

Hierarchy: In Fusion , account hierarchies are used for balance inquiry, financial reporting or other general ledger processing. For inquiry and reporting purposes, date-effective hierarchies (based on different tree versions) allow analysis of past, present or future data against any account hierarchy. Only a single tree version may be effective at a single point in time for general ledger processing, such as balance transfers and revaluations. However, for financial inquiry and reporting, multiple account hierarchies may be published simultaneously to balances cubes to allow performing date-effective comparisons for your organizational changes, such as company, cost center or account reorganizations.

Segment Value Security: So you know how in EBS, we said it was best practice to share the same value set for both the company and intercompany segments since the values would be exactly the same? In EBS, if you set up segment value security for the company segment, it will not apply the same rules to the interco segment even though they shared the same value set. In fusion, that stops being the case - if you set up segment value security for company segment, it will also be forced against interco segment because they share the same value set as a result ppl have to create a diff value set for interco.

Segment Value Security: In EBS, when you enable Segment Value Security on a segment, it does nothing until you define Security Rules and assign them to an application and responsibility. In Fusion, enabling segment value security restricts usage to all by default and you need to grant access to roles.

Agenda



EBS GL vs. Fusion


EBS GL versus Fusion GL EBS GL Fusion GL

Relational Balances (balances stored in tables)

Multi-dimensional balances (embedded Essbase cube)

Summary Templates required to stored summarized balances

Balances automatically pre-aggregated and stored at every summarization level

No ability to assign parent values (hierarchies) to: Cross-validation rules COA Mapping

Can leverage trees (hierarchies) for: Segment Value Security Rules Cross-validation rules COA Mapping Revaluations

Note: Best to use a different hierarchy for reporting, analysis, and allocations

PresenterPresentation Notes

EBS GL versus Fusion GL EBS GL Fusion GL

Balance level reporting currency automatically created when Translation run

Balance level reporting currency must be defined in advance before Translation can be run

Mass Allocations, Recurring Journals, and AutoAllocations

Hyperion Calculation Manager (graphical tool that can leverage trees for allocations)

Web ADI for spreadsheet integration ADFdi (ADF Desktop Integration) for spreadsheet integration Note: Must be installed as an add-on to Excel

Global Consolidation System (GCS) Hyperion Financial Management (HFM) Note: GL offers a light-weight consolidation solution using balance transfer programs

Budget Wizard, Budget Journals Budgets must be loaded directly to Essbase Cube for Budget vs. Actual Reporting

PresenterPresentation Notes

Consolidation: Fusion General Ledger offers a lightweight consolidation solution using balance transfers. The Transfer Balances to Secondary Ledgers process allows you to transfer your primary ledger balances to your balance-level secondary ledgers. The Transfer Balances Cross Ledger process allows you to copy balances between any pair of ledgers. If your organization requires a complex consolidation solution, we recommend using Hyperion Financial Management (HFM).

Agenda



EBS GL vs. Fusion


Copyright 2014, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 13 11

EBS Enterprise Model

US East BU

Vision Holding Company LE (BSV 10)

US Ledger Canada Ledger UK Ledger

Canada BU UK BU

Business Group

Ledgers

Legal Entities (LE) (BSVs)

Operating Units (OU) All Business Functions Performed by each OU

US West OU

US West LE (01)

Canada LE (21)

UK LE (31)

US East LE (02)

Inventory Orgs (IO)

1:1 Mapping

Canada IO US West IO US East IO UK IO Holding IO

Holding Co. BU

PresenterPresentation NotesIn this example, there is one Business Group that owns and controls all the legal entities.Vision Holding Company LE is a holding company and a legal entity. It uses Balancing Segment Value (BSV) 10 for its own transactions and consolidating its subsidiaries. It operates in the US, Canada, and the UK. It has 4 wholly owned subsidiaries: US West, US East, Canada, and UK. The parent holding company shares the same ledger as its two US legal entities.Note: Logically and conceptually, the Legal Entity is above the Ledger. But for illustrative purposes, the LE is shown BELOW the ledger because the ledger performs the accounting for the legal entities and can perform the accounting for multiple legal entities that share all 4Cs: Chart of Accounts, Calendar, Currency, and aCcounting Method. It has 5 Operating Units that map one to one to each legal entity. Each OU maps 1 to 1 to an Inventory Organization.

Copyright 2014, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 13 12

Fusion Enterprise Structure Model Enterprise

Ledgers

Legal Entities (LE) (BSVs)

Business Units (BU)

Inventory Orgs (IO)

Vision Holding Company LE (BSV 10)

Canada Ledger UK Ledger

Canada BU (Req & Invoicing)

UK BU (Req & Invoicing)

Canada IO

US West LE (01)

Canada LE (21)

UK LE (31)

US West IO US East IO

SSC BU (Purchasing)

UK IO

US Ledger

US East LE (02)

US BU (Req & Invoicing) Accounting Business Function

Purchasing Business Function

Holding IO

Many: 1

PresenterPresentation NotesIn this example, there is one Enterprise (in EBS, it was referred to as the Business Group). You can only have one enterprise per production instance. There should NOT be any reason why you would need more than one enterprise unless your company is truly a conglomerate, such as GE. All an enterprise is a grouping of legal entities. It really doesnt do anything else functionality-wise.The Vision Holding Company is a holding company and a legal entity. It uses Balancing Segment Value (BSV) 10 for its own transactions and consolidating its subsidiaries. It operates in the US, Canada, and the UK. It has 4 wholly owned subsidiaries: US West, US East, Canada, and UK. It shares the same ledger as its two US legal entities.Note: Logically and conceptually, the Legal Entity is above the Ledger. But for illustrative purposes, were showing the LE below the ledger because the ledger performs the accounting for the legal entities and can perform the accounting for multiple legal entities that can share all 4Cs: Chart of Accounts, Calendar, Currency, and aCcounting Method. It has 4 business units: SSC BU in the US performs centralized purchasing for all the legal entities worldwide. The US BU performs requisitioning and invoicing for both the US LEs, US West and US East. Canada and UK each have their own business unit to perform requisitioning and invoicing for them.Here, the enterprise is comprised of 5 registered companies or LEs, one of which owns the others and is the top node. These exist in the legal world and have property rights like persons.3 of the US LEs comply with their mandate to keep books and records by sharing the American ledger, and each foreign one has its own. The ledgers share a chart of accounts, and therefore can be combined into one Ledger set for mass processing in GL, and a single cube for instant reporting. Routine and repetitive accounts such as Receivables, Inventory, and Payables are managed by business units established one per ledger in one subledger that ties to each ledger. The BUs are country management, same as the folks who manage the ledgers.Inventory is owned by the legal entities using the ledgers and accounting for inventory in the subledger is located in inventory orgs. A shared service procurement business unit procures on behalf of many companies (LEs) and directs vendors to invoice the appropriate company (companies are registered LEs which are permitted by law to take up legal ownership of goods and services, unlike management entities and other unregistered organizations) so that group/enterprise can take legal ownership appropriately.

Reference Data

Transactional Data

OU Partitioned Tables

Operating Unit

EBS Model

Both Reference Data and Transactional Data Striped by the Same OU

PresenterPresentation NotesIn EBS, the Operating Unit was used as the mechanism to partition both the setup or reference data and transactional data.

Fusion Model

Reference Data Set

Reference Data Set Partitioned Tables

Reference Data

Business Unit

Operating Unit Partitioned Tables

Transactional Data

Separation of Reference Data from Organizational Partition

PresenterPresentation NotesIn Fusion, we separated the organizational partition which is used for transactions from the reference data set partition to allow for sharing across organizations where desired.Reference Data Set now partitions Reference DataAnd the Business Unit (formerly Operating Unit) partitions Transactional Data

This separation of the reference data set from the organizational partition means that reference data will not have to be redundantly defined and maintained for those cases where the same reference data is applicable to multiple organizations

Sharing Setup Data: EBS vs. Fusion

EBS Limitation Setup Data NOT sharable across BUs (formerly OUs).

Examples: AP Payment Terms

AR Transaction Types

Customer Account Sites

Supplier Sites

US Legal Entity

OU East OU West

Payment Terms 2/10 Net 30

Net 15

Net 30

Net 45

Payment Terms 2/10 Net 30

Net 15

Net 30

Net 45

PresenterPresentation NotesIn EBS, setup data, such as AR Transaction Types or AP Payment Terms were striped by OU. So if you had 10 OUs, you would need to duplicate those setups 10 times.What a pain. Something as simple as payment terms, such as 2/10 Net 30, or Net 45 are pretty standard and should be sharable.

Sharing Setup Data: EBS vs. Fusion continued

Fusion: Reference Data (Setup Data) Can Be Shared Across BUs

US Legal Entity

BU East BU West

2/10 Net 30

Net 30

Net 45

Payment Terms: COMMON

Immediate

Payment Terms: EAST

Net 15

Payment Terms: WEST

PresenterPresentation NotesIn Fusion, we borrowed PeopleSofts SetID concept to allow setup data (referred to as reference data) to be shared. So those common Payment terms applicable to multiple BUs can be shared. This allows you to reduce duplication and maintenance. In this example, we have a Payment Term Reference Data Set called Common that is being shared by two BUs.

But for reference data unique to a BU, you can partition it. You may want to partition it by regions, countries, divisions, whatever makes sense.

Additional Info. About Reference Data SharingReference data sharing facilitates sharing of configuration data such as jobs and payment terms, across organizational divisions or business units. You define reference data sets and determine how the data is shared or partitioned. Use reference data sets to reduce duplication and maintenance by sharing common data across business entities where appropriate. Depending on the requirement (specific or common), each business unit can maintain its data at a central location, using a set of values either specific to it or shared by other business units.You can share reference data after it is filtered on the basis of sets. A common reference data set is available as the default set, which can be assigned to several business units sharing the same reference data. For commonly used data such as currencies, you can use the common reference data set and assign it to multiple business units in various countries that use the same currency. In cases where the default set cannot be assigned to an entity, you can create specific sets. The data set visible on the transactional page depends on the sharing method used to share reference data.

Reference Data Set 2


Org 1


Org 2


Org 3 Org 1 Org 2 Org 3

Reference Data Set 1 Enterprise


Org 1 Org 2 Org 3

Reference data set per org.

(same as EBS)

Reference data set shared by all orgs. Note: Enterprise shipped for seed data.

Selected sharing of reference data sets across organizations

Common Reference Data

Common reference data set shared by all but retain org. specific data where appropriate


Org 1 Org 2 Org 3


Fusion Model: Implementation Choices

PresenterPresentation NotesIn Fusion, you have much more flexibility in how you want to share reference data.

In the first example, you could duplicate setup data per organization (The same way it was done in EBS).Or, you can have all your organizations share a common set of setup data.You can have selected sharing of reference or setup data where 2 or more organizations share, but another organization does not.And lastly, you could have a common set of reference data shared by all organizations, but retain organization specific data where needed.

Fusion Business Unit

Business Unit (BU): A unit of an enterprise that performs one or many business functions which can be consolidated in both a managerial and legal hierarchy

Business Functions Requisitioning Purchasing Receiving Invoicing

Note: Only BUs with the Procurement business function can register suppliers and create supplier sites. The sites are then assigned to other BUs that have a client/service provider relationship.

No more replication of unnecessary supplier sites!

PresenterPresentation NotesI mentioned Operating Unit is now called Business Unit. In addition to the name change, we now associate Business Units with Business Functions to better support shared service centers. The Business Functions include Requisitioning, Purchasing, Receiving, and Invoicing.

So you can have a dedicated BU perform the purchasing for your other Bus.

BU 1

Source Request Buy Pay

BU 2

BU 3

BU 1


SSC

BU 2

BU 1


SSC

BU 2

Intra-co. Invoicing

BU 1


SSC

BU 2

Intra-co. Invoicing

Decentralized Centralized Sourcing, Local Execution

Transfer Procurement to Local BU Complete Shared Services

Fusion Supports Flexible Procurement Models

PresenterPresentation NotesOracle supports center-led procurement organizations by supporting any combination of procurement models.Whether you want a completely decentralized procurement function where the local regions source, buy, and pay for their own goods and services, or a dedicated shared service center or a hybrid where you have centralized sourcing with decentralized buying and payments, Oracle supports them all.

Note: Center-Led Procurement allows your organization to optimize efficiency, cost savings and potential tax benefits by decoupling the demand source from where the buying actually takes place.

Questions?


Additional References

Fusion Financials Oracle Fusion Applications Enterprise Structures Concepts Guide Oracle Fusion Applications Financials Concepts Guide Oracle Fusion Applications Common User Guide Oracle Fusion Applications Financial Control and Reporting, Accounting

Transactions, Tax Transactions and Reporting Guide EPM Enterprise Performance Management Workspace Administrator's Guide Oracle Enterprise Performance Management Workspace User's Guide

docs.oracle.com/cd/E37017_01/nav/financials.htm


Other Fusion Documentation http://docs.oracle.com/cd/E37017_01/nav/financials.htm

Oracle Fusion Enterprise StructuresAgendaEBS versus FusionEBS versus FusionAgendaEBS Chart of Accounts versus Fusion COAAgendaEBS GL versus Fusion GLEBS GL versus Fusion GLAgendaEBS Enterprise ModelFusion Enterprise Structure ModelEBS ModelFusion ModelSharing Setup Data: EBS vs. FusionSharing Setup Data: EBS vs. Fusion continuedFusion Model: Implementation ChoicesFusion Business UnitFusion Supports Flexible Procurement ModelsSlide Number 20Additional ReferencesOther Fusion Documentation

Documents

Fusion Enterprise Structures Versus EBS 1