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

2

© 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

3

– Vice Chair Michelle Zaharoff. Celantra Systems – Chair  We are looking for new board members and invite you to join our board ! Thomas Simkiss. BizTech Corp. Terex . General Electric Jacques Bouchet. Mrunal Potdar. E-Business Tax Lead Markus Hentschel. Oracle Global Strategy. Qualcomm Kevin Elshaw.Board Members:            Hans Kolbe. State Street Bank of Boston Alex Fiteni. FILLC. Oracle Liaison. Facebook – associate member Maryanne DiGravio. Bearing Point Sangeeta Sameer. Agilent – Membership Liaison Dan Chaffer.associate member 4 .

International Multi-Org Configurations Simplification Options & Challenges 5 .

Drivers and Goals for Oracle Multi-Org Simplification  Reduce IT implementation time. 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 6 . testing. configuration.

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 7 .

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 LE’s 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. 10 . global supply chain companies) F) Single Ledger & Single OU across multiple local and corporate functional currencies using secondary ledger for local reporting.

Currencies. Yes a single country normally has its unique local statutory currency. Local Statutory currency most often equals the corporate functional currency. A subsidiary on the other hand is a standalone regular company.  Legal Entities . We may differentiate between a “branch” versus a “subsidiary”. except where corporate currency is the predominant transaction currency (FASB 52). but merely a registration of a foreign company with limited authority and limited compliance obligations.Countries. except for EURO countries. 11 .Local = Corporate: Not always. Legal Entities Words we use / Terminology is important  Country = Currency: Not always.  Functional Currency .Oracle LE = “Real” Legal entity: Not always. The branch is not a standalone company. Both are legal structures. and the Oracle LE can represent both types of 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 . If business need separate processes and management structures.Key Assumptions and Challenges  Multi-Org Simplification must serve the business: Operational and business drivers overrule any of these configurations.

Jacques Bouchet-Oracle. Director Global Strategy .

Only one functional currency for transaction reporting = primary ledger currency Multiple currencies for Accounting Entries only . Change country = assign OU for each transaction in Sub-ledgers R12 includes new functionality to use LE to drive country compliance . Payment.Country Localization feature support in EBS 12 Architecture EBS 11. especially in new modules such as EB-Tax .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). Cash Management. Op Unit is merely a default.

Secondary functional currency needs reporting extension / customization Applies to VAT report and accounting Turnover report / AR Invoice register Withholding tax calculation and reports . 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.e.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.

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.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. 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 .

IT Leader-General Electric .Sangeeta Sameer.

Oracle Financials and Project Accounting  Presented at OAUG Conferences in 1999.COE General Ledger Manager  12 years with General Electric  Previously was Finance Design Lead on P&W Business ERP’s  Focused on Project Accounting. Senior Principal Consultant with Oracle for 6 years  Focus on ERP. 2006 and 2014  Mike Fisk  Power & Water Segment . with General Electric for 11 years  Previously. Integrated Reporting & Stat Compliance .About the Presenters  Sangeeta Sameer  IT Leader.

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 .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.

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 .

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 GL’s 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 .Shared OU .

- 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.Implications of ‘shared’ OU in 11i What we needed to address …. 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 .

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 .Decision Criteria for Shared vs.

Mike Fisk. Senior Account Leader-General Electric .

2 New Info: Controllers now want branch 5 pure banking .) • USA LE with Non-US Branches Scope = Branch “Permanent Establishment” These LE’s 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. • 100. reporting. but…. document sequencing) • “Non-Operational” LE (Holding Co’s. Oracle requires you to be in same Oracle Legal Entity.R12 Requirements For Business 11i Historical Experience • Ease of use valued over control • IT and Initial set up cost reduced. Controllership through growth is unstainable otherwise Design Considerations Some LE’s need Stat Ledgers. fixing.000+ man hours of work over a decade. explaining cross-LE Segment transactions Multiple Business Legal Entity Scenarios • USA Standalone LE’s • Local (Non-US) LE’s MOAC and Ledger Sets solve 95% of usability issues…PA project search still aggravating Operational LE’s should be in single ledger in future. take conservative PE route to minimize project switching To share bank accounts. etc. Tech. settling. some don’t…creating extra transactions in shared secondary ledgers not desired (volume.

all LE’s affected • If multiple OU’s – 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. so region actionable. 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. we are compliant • • Supplier/Customer information can be separated by OU – less errors • Multiple OU enable bank account strategy under R12. If OU is maintained at Statutory Department level. More risk of error. 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 .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. • 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. Increased concurrent request load on system .

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

but may be offset by long-term finance cost . larger operating LE’s had too much loss of control when shared in 11i Pure Design  Users not impacted as much with MOAC  More setups.Summary Shared OU’s/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 LE’s” in R12  For GE. offset by speed with fewer customization  IT Cost may be higher.

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) .

‘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.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 . Correlating POs / Invoices / Payments to BSVs in post OU consolidation requires reporting changes EB Tax / Vertex changes to support Common OU .

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. EU. European Subchapter .Additional Available Solutions  Statutory Sequencing Utility – Gapless  By Legal Entity    Multiple Sequences within LE    Across LE’s within single ledger Across LE’s Within single Op Unit Invoice& Credit Memo DOM. NON-EU (Italian Requirements) Statutory Journal Reporting w.

please Contact: Hans Kolbe hanskolbe@celantrasystems.com 33 .Thank you – Questions and Suggestions.