Multi-Org Simplification R12

Multi-National SIG User Presentation

Webinar July 23, 2014

Prepared by Board of the MN-SIG and :

Sangeeta Sameer, GE, Board Member
Jacques Bouchet, Oracle, Board Member
Mike Fisk, GE
Mrunal Potdar, Facebook
Hans Kolbe, Celantra Systems, Board Chair

Agenda
1.

Introduction - MN-SIG Chair Hans Kolbe, Celantra Systems

- Mission of the MN-SIG
- Multi-Org Challenges and Confusion, Terminology
2. R12 Direction and Options Oracle (Jacques Bouchet, Oracle)
3. Oracle GE User Presentation
11I Multi-Org Models, Challenges, and Evaluation (Sangeeta, GE)
R12 Multi-Org Implementation Model (Mike, GE)
4. Oracle FaceBook User Presentation
11I Multi-Org Models, Challenges and Evaluation (Mrunal,
FaceBook)
5.
6.

Additional Available Solutions (Rene Roembell)

Questions - Answers

2012 OAUG Multi-National SIG

Multi-National SIG
Mission of Multi-National SIG

Issues of the Multi-National SIG

Application Upgrade Strategy - R12,

Fusion Apps, Co-Existence Options for
multi-nationals

Legal Entity, Operating Unit, Multi-Org

Access (Shared Services, Compliance,
Localizations)

Inter-Company (multi-tier, trading,

accounting, pricing, )

Global Project Management and

Support

Global Chart of Accounts Secondary

Ledgers

Multi-language, multi-byte (MLS &

NLS), Time Zones

Tax and Legal Compliance Challenges

(coordinate solutions in different
regions)

Global Single Instance

Cross-Module and Cross-Geographies

Processes and Issues specifically
facing global or multi-country Oracle
applications users
Organize exchange of ideas and
experiences
Take active role in OAUG
Enhancement process with Oracle
Corporation
Synchronize with other SIGs and
GEOs

Board Members:

Hans Kolbe, Celantra Systems Chair

We are looking for new board members and invite you to join our board !

Thomas Simkiss, BizTech Corp. Vice Chair

Michelle Zaharoff, Agilent Membership Liaison
Dan Chaffer, Qualcomm
Kevin Elshaw, State Street Bank of Boston
Alex Fiteni, FILLC, E-Business Tax Lead
Markus Hentschel, Bearing Point
Sangeeta Sameer, General Electric
Jacques Bouchet, Oracle Global Strategy, Oracle Liaison,
Mrunal Potdar, Facebook associate member
Maryanne DiGravio, Terex - associate member

International Multi-Org
Configurations
Simplification
Options & Challenges

Drivers and Goals for Oracle Multi-Org

Simplification

Reduce IT implementation time, configuration, testing, and complexity of support

Model the legal structure independently of operational structure and accounting

structure

Reduce time to integrate acquisitions and roll-out new modules and functionality

Ensure global processes by reducing number of configurations and

synchronizations challenges

Simplify and speed up monthly closing

Silo Model (Ledger and OU)

1 Ledger-1 Legal Entity-1 Operating Unit
Secondary
Ledger
Primary

Secondary
Ledger
Primary

Secondary
Ledger
Primary

Secondary
Ledger
Primary

Secondary
Ledger
Primary

Ledger

Ledger

Ledger

Ledger

Ledger

L
E

L
E

L
E

L
E

L
E

OU

OU

OU

OU

OU

Partial Silo Model (OU)

1 Ledger-n Legal Entities-n Operating Units
Secondary
Secondary
Secondary Ledger
Ledger
PrimaryLedger
Ledger

L
E

L
E

L
E

L
E

L
E

OU

OU

OU

OU

OU

Cross Legal Entity Operating Unit (CLEO)

1 Ledger many Legal Entities - 1 Operating Unit
Secondary
Secondary
Ledger
Ledger
Secondary
PrimaryLedger
Ledger

L
E

L
E

L
E

OU

L
E

L
E

Possible Configurations
(User Presentations)
Unique Operating Unit per single country

A ) Single Ledger & OU per Oracle LE (Complete Silo)

B) Shared Ledger / Separate OU per Oracle LE (Partial Silo)
C) Shared Ledger and Shared Op Unit per country across LEs where exist (CrossLE Model per country)
Shared Operating Unit for multiple countries

D) Single Ledger & Single OU if local statutory currency is the same (EURO
Countries)

E) Single Ledger & Single OU if corporate functional currency is the same (USD
Functional branches, global supply chain companies)

F) Single Ledger & Single OU across multiple local and corporate functional
currencies using secondary ledger for local reporting.

10

Countries, Currencies, Legal Entities

Words we use / Terminology is important

Country = Currency: Not always. Yes a single country normally has its unique
local statutory currency, except for EURO countries.

Functional Currency - Local = Corporate: Not always. Local Statutory currency

most often equals the corporate functional currency, except where corporate
currency is the predominant transaction currency (FASB 52).

Legal Entities - Oracle LE = Real Legal entity: Not always. We may differentiate
between a branch versus a subsidiary. The branch is not a standalone
company, but merely a registration of a foreign company with limited authority and
limited compliance obligations. A subsidiary on the other hand is a standalone
regular company. Both are legal structures, and the Oracle LE can represent
both types of structures.

11

Key Assumptions and Challenges

Multi-Org Simplification must serve the business: Operational and business

drivers overrule any of these configurations. If business need separate
processes and management structures, they should be separated into separated
Operating Units and/or ledgers. We are discussing the what are the Oracle
technical or external legal constraints? And how do we deal with them?

Drivers / Challenges need to be addressed

Local and Functional currency
Sequencing requirements in Sub-Ledgers and GL journals drive separate ledgers
Country Localizations where needed and used
User Access and Risks of User Error (Defaulting and Security Rules)
IT interfaces and Programs may need to be adjusted
Business Processes mapping / may need adjustments

12

Jacques Bouchet-Oracle,
Director Global Strategy

Country Localization feature support in EBS 12

Architecture
EBS 11.i

Country context given by profile option per Responsibility

Change country = change Responsibility
Multiple transaction currencies (MRC) (duplicates transactions)
EBS 12

Country context for transactions given by Operating Unit (OU);

Change country = assign OU for each transaction in Sub-ledgers
R12 includes new functionality to use LE to drive country compliance , especially in new modules
such as EB-Tax , Payment, Cash Management. Op Unit is merely a default.

Only one functional currency for transaction reporting = primary ledger currency
Multiple currencies for Accounting Entries only

Country Localization feature support in EBS 12

Architecture
Country context for transactions

Drives Global Descriptive Flexfield behavior (additional fields given by localizations)

Drives some country specific features (i.e. Withholding)
Drives some localization features packaging (often country per Op Unit or Responsibility)
Country statutory currency for reports

Needs to be Primary Ledger currency since no more MRC at transaction level

Oracle standard sub-ledger reports only available in primary functional currency,

Secondary functional currency needs reporting extension / customization
Applies to
VAT report and accounting
Turnover report / AR Invoice register
Withholding tax calculation and reports

Considerations for Multi-Org Structure Decisions

Balance cost benefit of setting up

More sophisticated structures (multiple Ledgers & OUs) with less customization cost
Simpler structures (common Ledger, common OU) with customization cost

Decision points does a country need:

Sequential Numbering per Legal Entity

Transaction level
Accounting Entry (Journal) level

Local Chart of Account (Germany, France, Mexico) for accounting electronic filing and audit
Electronic Fiscal Audit file per LE at Transaction level
VAT reporting at transaction level (EB-Tax reports by LE available)
Withholding tax processing

Sangeeta Sameer, IT
Leader-General Electric

About the Presenters

Sangeeta Sameer

IT Leader, with General Electric for 11 years

Previously, Senior Principal Consultant with Oracle for 6 years
Focus on ERP, Oracle Financials and Project Accounting
Presented at OAUG Conferences in 1999, 2006 and 2014

Mike Fisk

Power & Water Segment - COE General Ledger Manager

12 years with General Electric
Previously was Finance Design Lead on P&W Business ERPs
Focused on Project Accounting, Integrated Reporting & Stat
Compliance

Introduction

PGS (Power Generation Services) operates in

more than 100 countries around the world
Started Release 11i implementation in 2004,
with Italy go-live in 2006, followed by 5 more
countries in 2007
Shared Operating Unit Concept introduced to
Speed up country deployments
Last set of countries rolled out in 2012

73 Countries Implemented
2006
Italy

2007

2008

2009

UK
Ireland
Spain
France
Germany

Austria
Switzerland
Czech Rep
Denmark
Luxembourg
Norway
Netherlands

Japan
Singapore
Taiwan
Belgium
Hungary
Israel
Latvia
Romania
Sweden
Poland
Croatia
Finland
Portugal
Cyprus
Korea
Malaysia
Thailand
China
Hong Kong
Brunei
Australia
New Zealand
Vietnam

2010
Indonesia
Turkey
Greece
United States
Saudi Arabia
Qatar
UAE
Kuwait

2011

2012

India
Egypt
Pakistan
Ghana
Iraq
Canada
Lebanon
Bahamas
Tunisia
Brazil
Argentina
Dominican
Bahrain
Republic
Chile
Ecuador
Colombia
Panama
Algeria
Morocco
Jamaica
Mexico
Nigeria
Oman
Peru
Trinidad & Tobago
Venezuela
Virgin Islands
South Africa

Design change in 2008 Implementation Speed changed

Shared OU - Why we deviated from Country/LE

pure design to include cross-country OUs in 11i?
From single ledger per country & separate OU per LE to a hybrid model that included
single ledger and single OU across countries and LEs

Time & Money

Cost benefit of individual implementation/set up of country solution

Focus on low volume/low complex countries delayed more complex country roll outs
In Europe 20 countries made up ~3% of region volume! (common theme globally)

Maintenance & Support

Significant maintenance required for multi Operating Units/Set Of Books

Multiple modules and GLs to close every month
Testing of multiple Operating Units

User Experience

Shared Service Users had to switch responsibility when working across countries

Country/LE pure implementations for low complex/low volume countries

did not make economical sense

Implications of shared OU in 11i

What we needed to address .
-

Trial Balance in local currency if different from Functional currency

Accounting in daily rates
Oracle Localization reports
Local Chart of Accounts These countries were not put in Shared OU
VAT @ daily rate on invoices customized for this
Sabrix required customization to handle multiple countries from single OU
Invoice printing program more complex (language, rates)

What was not impacted

All GE Management reporting in appropriate currencies

Ability to report Permanent Establishment (PE) and non PE for GEII LE by country
Visibility to originating currency of all transactions
Key tax documents remained inherently compliant (invoices)
All Cognos reports including the custom Stat and Tax reports built

Decision Criteria for Shared vs. Pure OU

COUNTRY

Permanent
establishment
YES

Count
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

OU
OU_IFS_IT
OU_PS_ES
OU_PS_GB
OU_PS_IE
OU_PS_DE
OU_PS_FR
OU_PS_AT
OU_PS_JP
OU_GETAS_TR
OU_PS_US
OU_PS_BH_GEWLL
OU_PS_DZ_GEIOA
OU_PS_LA_GEISA
OU_PS_NG_GEIONL
OU_PS_OM_GEILLC
OU_PS_VE_TMCA
OU_PS_ZA_GESA
OU_PS_IN
OU_PS_IN_GEPSIL
OU_PS_PK
OU_PS_EC_ENSYS
OU_ESHQ_LA_U_GEII
OU_PS_CA_GECII
OU_PS_AE_GEEFZE
OU_PS_LA_U_GEIOC
OU_PS_EURP_U
OU_PS_EURP_E
OU_PS_ASIA_U
OU_PS_ASIA_U_GEIOC_
U
OU_PS_ME_U
OU_PS_LA_U_GEII

Dedicated/
Shared
Dedicated
Dedicated
Dedicated
Dedicated
Dedicated
Dedicated
Dedicated
Dedicated
Dedicated
Dedicated
Dedicated
Dedicated
Dedicated
Dedicated
Dedicated
Dedicated
Dedicated
Dedicated
Dedicated
Dedicated
Dedicated
Dedicated
Dedicated
Dedicated
Dedicated
Shared
Shared
Shared
Shared
Shared
Shared

NO

Sales volume
significant

NO

YES
#
Countrie
s
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
14
5
9
3
13
12

Complexity
Score > 500

YES

NO

SHARED
OPERATING
UNIT
Luxembourg
Switzerland

Latvia

COUNTRY SPECIFIC

Norway
Turkmenistan
Poland
Belgium
Romania
Finland

Denmark

Mike Fisk, Senior Account

Leader-General Electric

R12 Requirements For Business

11i Historical Experience
Ease of use valued over control
IT and Initial set up cost reduced, but.
100,000+ man hours of work over a decade, fixing,
settling, reporting, explaining cross-LE Segment
transactions

Multiple Business Legal Entity

Scenarios
USA Standalone LEs
Local (Non-US) LEs

MOAC and Ledger Sets solve 95% of usability

issuesPA project search still aggravating
Operational LEs should be in single ledger in future.
Controllership through growth is unstainable
otherwise

Design Considerations
Some LEs need Stat Ledgers, some dontcreating
extra transactions in shared secondary ledgers not
desired (volume, document sequencing)

Non-Operational LE (Holding Cos, Tech, etc.)

USA LE with Non-US Branches
Scope = Branch Permanent Establishment

These LEs with only 1 or 2 users and few/no

subledgers may be controlled enough to be shared?

oPE Scope subject to local Stat

oNon-PE scope treated as US
oA country can have both treatments
oProjects can switch treatments
oFunc Currency of Branch determined with
combination of PE and Non-PE
oBank Accounts can be shared across Branches

Need to be in same OU to not cause business

disruption
New Info: When in doubt, take conservative
PE route to minimize project switching
To share bank accounts, Oracle requires you to be in
same Oracle Legal Entity,
2
New Info: Controllers now want branch
5
pure banking

R12 Analysis: Shared OU vs Pure OU

Pros
Shared
OU

Country
Pure OU
per LE

Cons

Ability to share data across Legal Entities

& OU

In Standard R12, if desire is to have multiple LE per

OU then need to override default legal entity context

Reduced concurrent request load on

system

Risk that a LE will have access to customers or

supplier information where there is no contractual
relationship. More risk of error.

Sub-ledger document sequencing not by legal entity

Complex data segregation rules required to ensure

that cross legal transactions cannot be booked in
system

If problem with closing, all LEs affected

If multiple OUs data can be segregated by

creation of multiple responsibilities and security
rules but if this is design may not be able to use
MOAC functionality

Allows use of Standard R12 LE definitions and

functionality

AP/AR document sequencing maintained at OU

Level. If OU is maintained at Statutory Department
level, we are compliant

Supplier/Customer information can be separated by

OU less errors

Multiple OU enable bank account strategy under

R12. Can attach bank account to OU or LE so can
determine level of bank account sharing

Ability to isolate closing issue to a specific OU or

country/legal combination , so region actionable.

Increased concurrent request load on system

R12 Design: One Primary Ledger for all Branches within a Legal Entity with same
GE GAP functional currency

Summary
Shared OUs/Ledgers

Was the right decision for 11i and supported growth at the time in these countries

Still may be appropriate for smaller countries or non-operating LEs in R12

For GE, larger operating LEs had too much loss of control when shared in 11i

Pure Design

Users not impacted as much with MOAC

More setups, offset by speed with fewer customization

IT Cost may be higher, but may be offset by long-term finance cost

Mrunal Potdar - Facebook

Finance Technology Partner

Facebook Implementation
Current State
One Oracle Legal Entity (Multiple BSVs)
One Ledger
Multiple OUs (owns multiple Inventory
Orgs)
Common Asset book (Corporate and Tax
Books)
Proposed State
One Legal Entity per BSV requiring subledger support (more than One Legal
entity)
One Ledger
Common OU (Own all US Inv orgs)
Common Asset book (Corporate and Tax
Books)

Project Goals
Consolidate US OUs to one OU and
design scalable Source to Pay business
process for operational efficiency gains
Define Legal Entities using standard
functionality and assign BSVs (company
codes)
Reduce PO cancellations significantly
Improve US Payments accuracy and turn
around time
Accounting accuracy
Reduce Period close overhead (multi OU
to single US OU)

Facebook Implementation
OU Consolidation Impact
Eliminates

need for supplier setup in multiple operating units

Eliminates need to run key processes like invoice validation, create accounting, transfer to GL in multiple
OUs
Improve PO change process and eliminates need for PO cancellation
Allows transfers between inventory orgs within US OU for all US data centers
Speeds up close process (avoids review and sweeping of unaccounted transactions in multiple US OUs)
Improves IT's velocity / ability to roll out new entities from current time line of 4-6 weeks to few days to one
week
Simplify Invoice to Pay process leading to productivity gains overall Outsourcing effort
Supplier site cleanup including obsoleting redundant sites and merge duplicates
Key Challenges
Delinking

of BSV from existing Legal Entity and assigning it to new Legal Entities
Ensuring seamless transition to users for accounting impact
Non PO Invoices processing and accounting (Expense Accruals)
Payment processing transition - transition towards standard functionality of using bank account owning legal
entity to achieve segregation of payments
Sub-ledger reporting as existing OUs are consolidated in common OU. Correlating POs / Invoices /
Payments to BSVs in post OU consolidation requires reporting changes
EB Tax / Vertex changes to support Common OU

Additional Available Solutions

Statutory Sequencing Utility Gapless

By Legal Entity

Multiple Sequences within LE

Across LEs within single ledger

Across LEs Within single Op Unit
Invoice& Credit Memo
DOM, EU, NON-EU (Italian Requirements)

Statutory Journal Reporting w. Sub-Ledger Detail

Available from secondary or consolidation ledger

From Corporate to Local Chart of Accounts
From Corporate to Local Calendar

Rene Roembell Frankfurt MN-SIG; European Subchapter

Thank you Questions and

Suggestions, please

Contact:
Hans Kolbe
hanskolbe@celantrasystems.com

33