An Oracle White Paper May Oracle Fusion Applications Setting Up a Minimal Enterprise Structure to Support Procurement Shared Services

Transcription

1 An Oracle White Paper May 2012 Oracle Fusion Applications Setting Up a Minimal Enterprise Structure to Support Procurement Shared Services

2 Disclaimer The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle s products remains at the sole discretion of Oracle. Warning This document is intended to provide an introduction to the setup of a Shared Services Enterprise Structure and is not a comprehensive setup document.

3 Executive Overview... 1 The Concept of Shared Service Centers... 1 Background... 2 Procurement Modes that can be mapped in Fusion Applications... 3 Decentralized procurement... 3 Procurement shared service... 4 Payables and Procurement Shared Service Payables and Procurement Shared Service Case Study... 7 Introduction... 7 Definition of the Enterprise Structure... 8 Locations Inventory Organizations Requisitioning Business Function Purchasing Business Function Service Provider Relationships Suppliers and Supplier Sites Transactions Account Builder Intercompany Transactions Recommendations Conclusion References... 28

4 Executive Overview This document describes a minimal representation of an enterprise structure to support shared sourcing and procurement services to requisitioners from multiple companies in multiple divisions and in multiple countries. The document is targeted at implementation consultants, particularly those deploying the Fusion Procurement offering and aims to provide an introduction to the key concepts of shared services and complement this introduction with a sample organization representation. In addition to procurement professionals, financial staff in the deploying enterprise will also need knowledge of the deployment options and the reasoning behind the selection of a particular model. The Concept of Shared Service Centers Shared Service Centers are corporate level organizations tasked with conducting common operations that support the core lines of business of an Enterprise. The services provided can be in the areas of Human Resources Management, Payroll, Payables Accounting, and Procurement. The latter is the subject of this paper. Consolidating procurement services into a single procuring entity that serves multiple business units within an enterprise could, if properly implemented, result in the following benefits: Increased bargaining power, economies of scale, and cost savings Formation of a more focused procurement workforce Increase in buyer specialization and better generation of specifications, and more accurate efficient catalog management Centralized and standardized Information deployed across the enterprise Centralized processes which could result in the reduction of redundancy and effort duplication, and a more responsive procurement organization 1

5 Background The issue this document aims to address is how much of an enterprise structure will need to be set up for an enterprise with several lines of business, operating in several jurisdictions, and whose sourcing and procurement transactions are conducted through a shared service center. As its the name suggests the purpose of this paper is to discuss the minimal setup requirements for shared services procurement. Implementers should however be aware that simpler implementations are also possible as listed below: No Subledgers, / No Legal Entities: if the only requirement that is fulfilled for a company from Fusion Applications is the production of its financial statements, a company may have a very lightweight implementation as a balancing segment within a chart of accounts. No Subledgers: : If more functionality is supported for it such as tax reports it may also need a more formal representation as a legal entity within the Legal Entity System. Subledgers: If other functionality is tracked for the company, such as its invoices and payments it may need to have a representation in the subledgers. In general the subledger transactions are managed by a business unit and a business unit may process transactions on behalf of many legal entities. If you are processing an invoice in an accounts payable department, there will generally be a legal entity that the majority of those invoices are processed for. This default legal entity is part of the business unit definition. 2

6 Procurement Modes that can be mapped in Fusion Applications The tables that follow outline several modes of procurement that can be modeled in Fusion Applications. The examples used are for illustrative purposes and do not exclude other configurations not represented below. The Requisition Source is a Business Unit (BU) enabled to place requisitions The Procuring and Sourcing Organization represents the entity that manages the sourcing process and that releases purchasing documents on behalf of the Requisition Source BU. The Invoice and Payment column represents the Sold to organization that assumes the liability for the payables Invoices and payments on behalf of the Requisition Source BU. The Intercompany Column refers to required intercompany transactions. This is applicable in cases where payments to suppliers are made from a BU other than the Requisition Source BU. These scenarios are mentioned but not treated in this paper. Decentralized procurement REQUISITON PROCURING AND INVOICING AND PAYMENT INTERCOMPANY SOURCE SOURCING BU1 BU1 BU1 NONE BU2 BU2 BU2 NONE BU3 BU3 BU3 NONE In decentralized procurement, various business units in the enterprise operate their procurement functions independently. 3

7 Figure1. Decentralized Procurement Procurement shared service REQUISITON PROCURING AND INVOICING AND PAYMENT INTERCOMPANY SOURCE SOURCING BU1 BU4 BU1 NONE BU2 BU4 BU2 NONE In Shared Service mode, the procurement functions are carried out by a central organization on behalf of several requisitioning organizations. Payables Invoices and Payments are processed by the Requisitioning / Receiving Organizations. No Intercompany Transactions are conducted in this mode. In this mode the balancing segment of the Chart of Accounts (COA) needs to be mapped to the Legal Entities the BUs belong to Figure2. Shared Services Procurement 4

8 Payables and Procurement Shared Service -1 REQUISITON PROCURING AND INVOICING AND PAYMENT INTERCOMPANY SOURCE SOURCING BU1 BU4 BU4 BU4 to BU1 BU2 BU4 BU4 BU4 to BU2 The procurement organization can also act as a more comprehensive shared service center managing global procurement as well as payables invoicing and payments on behalf of requisitioning business units. In this mode, intercompany receivables and payables Transactions are required for reconciliation, and the balancing segment of the COA needs to be mapped to the Legal Entities the BUs belong to. Figure3. Global Procurement - Example 1 Payables and Procurement Shared Service -2 REQUISITON PROCURING AND INVOICING AND PAYMENT INTERCOMPANY SOURCE SOURCING BU1 BU4 BU1 None BU2 BU4 BU1 BU1 to BU2 5

9 Other modes of procurement can also be modeled in Fusion Apps, for example The Invoicing and Payment can be made by an organization other than the Procuring organization. In this mode, intercompany receivables and payables Transactions are required for reconciliation, and the balancing segment of the COA needs to be mapped to the Legal Entities the BUs belong to. Figure4. Global Procurement - Example 2 6

10 Case Study Introduction The subject of our case study is the InFusion Corporation which operates two worldwide Divisions; Financial Services and Consulting Services. Each of these two divisions operates in both India and the United States. All 4 legal entities that represent the resulting organization structure, employ people and all employees raise requisitions. All sourcing and procurement activities are conducted by the company s two head offices in India and the US for their respective companies. Figure 5. In Fusion Corporation Enterprise Chart 7

11 Below are the key steps to model the above enterprise with two country based shared Procurement and Sourcing Service Center. Task List / Task Establish Enterprise Structures Manage Locations Manage Inventory Organizations Assign Business Unit Business Function Manage Service Provider Relationships Manage Mapping Sets Manage Account Rules Manage Transaction Account Definitions Definition of the Enterprise Structure Task List / Task Description Product Product Family Establish Enterprise Determine the high-level structures of HCM Configuration HCM Structures the enterprise using an interview style Workbench process. Divisions Legal Entities Business Units Business Unit Set Assignments Location Reference Set Figure 6.Navigational Flow of an Enterprise Setup in the HCM Configuration Workbench 8

12 Figure 7. Sample summary of an Enterprise setup prior to loading the enterprise data into Fusion Apps. The Report is divided into sections listing the Divisions, Legal Entities, Business Units as well as additional information related to the Enterprise. In this task the Enterprise, along with its Legal Entities and Business Units is defined. For InFusion we will setup two Divisions representing the two lines of Business. These Divisions form part of the HCM Organizational Hierarchy which can be used to create Org Based Security Profiles. We will set up four legal entities with two primary ledger one for each country where InFusion operates and each serving two Legal Entities. We will create two Business Units representing country operations. These Business Units will have for now all Business Functions except Procurement. Once the two representative Business Units mentioned above are created, we will need to determine whether to combine our sourcing and procurement shared services with one of 9

13 these BUs or whether to create a separate shared services BU that serves as the consolidation hub for procurement and sourcing activities. In our example above, if the US Business Unit is geographically collocated with InFusion s Corporate headquarters then we would recommend combining the Procurement and Requisitioning business Functions in the US Business Unit Figure 8. Minimal Representation of an Enterprise with Procurement shared services If on the other hand the US Business Unit is geographically distinct from the Corporate Headquarters (For example a Corporate Head Office in a downtown area with an assembly plant in an industrial zone, or a distribution center near a port or an airport, or a call center in another State or Province), then a separate BU assigned the Procurement Business Function would be recommended for better representation. This BU can be expanded at a later stage to provide additional shared services. 10

14 Figure 9. Minimal Representation of an Enterprise with Procurement shared services where the Procurement BU is distinct from the Operational BUs For the remainder of this document we will assume that the Procurement BU is a separate BU as in Figure 9 above, meaning that the Corporate Head Office in the US, where procurement operations are conducted is different from the two US centers of operations Since InFusion is a services organization there is no need to maintain Warehousing Inventory Organizations. However we will see later in this document that Default Inventory Organizations will be setup, but for the purpose of COA balancing segment value derivation rather than for material control. Note: Requisitioning Business Units are linked to Ledgers and in our example the two countries have different ledgers, so having a single Business Unit is not feasible Note: The Procuring Business Function on the other hand does not have a mandatory Ledger Assignment 11

15 Locations Task List / Task Description Product Product Family Manage Locations Create and manage the Global Human HCM locations relevant to your Resources enterprise. For example, create the locations where people work as well as the locations of your external organizations. Locations represent physical addresses of where employees work or facilities are located. These locations are later associated to Inventory Organizations. Figure 10. A Definition of a Location 12

16 Inventory Organizations Task List / Task Description Product Product Family Manage Inventory Configure inventory Inventory SCM Organizations organizations to describe Management distinct entities within the company such as manufacturing facilities, warehouses, or distribution centers. Inventory Organizations are created for each of the Legal Entities identified and modeled above. The purpose of these inventory orgs is their use in the Transactions Accounts Builder as a means to derive the appropriate Legal Entity value and populate it in the Company Code segment for purchasing transactions. This is described in more detail later in this document. Note: More than one Inventory Organization can be created and associate with a single Legal Entity depending on the needs of the organization. In the case of InFusion we will create a single Inventory Organization per Legal Entity Inventory Organizations defined for the purpose of Inventory Management and can serve as their own the Master Orgs or can reference a separate Item Master Org. The Item Master Organization holds the Master Item Records Data. Note: Inventory Orgs must be assigned to the Business Units that manages Business Functions in for their Legal Entities. 13

17 Figure 11. Sample Definition of an Inventory Organization and associated Location Requisitioning Business Function Task List / Task Description Product Product Family Assign Business Assign business functions to Financials Common Financials Unit Business be performed by a business Module Function unit, such as customer invoicing and order capture. Once the Enterprise is defined along with its associated Legal Entities and Business Units, the requisitioning business function is assigned to the country business units to enable them to process requisitions. In our case will not be doing global procurement, so the country business units will also be granted the payables invoicing and payments functions. 14

18 Figure 12. This figure shows a sample Assignment of the Requisitioning and Payables Invoicing Business Functions to a Business Unit, in addition to the assignment of its Default Legal Entity. 15

19 Purchasing Business Function Task List / Task Description Product Product Family Assign Business Unit Business Function Assign business functions to be performed by a business unit, such as customer invoicing and order capture. Financials Common Module Financials Just as we assigned the Requisitioning and Payables Invoicing business functions to the country BUs, we will need to assign to the procuring business unit, whose role will include supplier management, contract negotiation, and procurement order generation, the appropriate business function, namely The Procurement and Procurement Contract Management Business Functions. A Procurement Business Unit does not necessarily need to be tied to a Legal Entity or have an associated Primary Ledger 16

20 Figure 13. This figure shows a sample Assignment of the Procurement Business Functions to a Business Unit, in addition to the lack of an assignment of a Default Legal Entity. 17

21 Service Provider Relationships Task List / Task Description Product Product Family Manage Service Provider Relationships Assign service provider business units to client business units to provide business functions such as procurement, payables payments, and customer payments. Financials Common Module Financials After assigning Business Functions to our Procurement and Requisitioning BUs, we will now create a relationship between them that determines the client (The Requisitioning BU) and the service provider. Figure 14. A sample client Organization (top left) and its Service Providers, and on the lower right, a Service Provider and the clients it serves. 18

22 Suppliers and Supplier Sites When Supplier Sites are defined, we associate to those sites the default Procurement BU (via the Supplier Address definition) and the Client BU to Sold to BU relationship. In our example, this is not required since we are not modeling a global procurement organization. However in order to illustrate the relationship we have included Figure15 below. Figure 15. Sample Supplier Address to Procurement BU Association 19

23 Figure 16. Global Procurement Sample Sold To BU that assumes Financial Liability of Client BU by Supplier Site. Transactions Account Builder In our Example, and based on the customer s business requirements, we have decided to create a Chart of Accounts comprised of 7 segments: Company Code Cost Center Account Sub Account Inter- Company Local Account Spare We now need to apply transaction based derivation rules on the values of the segments of our COA. The Transactions Account Builder (TAB) is the engine that allows us to implement an automated account derivation solution in line with our model of the InFusion Corp with a Shared Procurement Service Center. The Table below lists the distribution accounts in the first column and the three COA segments with values automatically derived based on the attributes of the transaction being completed. To illustrate the intended result, assume the company codes for our India Legal Entities are as follows: 20

24 Company Name Company Code India Consulting Services Ltd 100 India Financial Services Ltd 102 If a requisition is placed by India Consulting Inc, the default charge account should have the value 100 in the Company Code Segment, and if a requisition is placed by India Financial Services the derived value for that segment should be 102. Both Requisitions lines can then be added to two separate Purchase Orders owned by the Procurement Business Unit. Accrual Account Charge Account Destination Charge Account Destination Variance Account Variance Account Company Code Cost Center Account MISPO Purchasing Company Code Account Rule For Charge Account (derives based on Inventory org) MISPO Purchasing Company Code Account Rule For Charge Account (derives based on Inventory org) MISPO Purchasing Company Code Account Rule For Charge Account (derives based on Inventory org) MISPO Purchasing Company Code Account Rule For Charge Account (derives based on Inventory org) MISPO Purchasing Company Code Account Rule For Charge Account (derives based on Inventory org) From the user's default expense account or favorite charge account, or the user selects on requisition From the user's default expense account or favorite charge account, or the user selects on requisition From the user's default expense account or favorite charge account, or the user selects on requisition Table1. Transaction Account Definitions for the Procurement Distribution Accounts MISPO Purchasing Natural Account Rule for Charge Account (two mappings that will default the account from the category and in cases default a fixed asset account based on value) MISPO Purchasing Natural Account Rule for Charge Account (two mappings that will default the account from the category and in cases default a fixed asset account based on value) 21

25 The two rules mentioned in the above table MISPO Purchasing Company Code Account Rule For Charge Account and MISPO Purchasing Natural Account Rule for Charge Account are defined to automate the selection of segment values. Refer to Figure 18 for an illustration of how one of these rules is defined in the Transaction Account Definition In TAB we start by creating a Mapping Set (Figure 17) which in our case is a rule that creates the mapping between the Inventory Organizations and the Balancing Segment Values (BSV) that will populate the Company Code segment in the COA. Task List / Task Description Product Product Family Manage Mapping Sets Create and maintain the rule that Subledger Financials determines the segment or entire Accounting account value based on certain transaction attribute values. Mapping sets are used in account rules. Figure 17.Sample Mapping Set for the Rule used to derive the Company Code Value from the Transaction s Inventory Organization. 22

26 The next two steps in TAB are Definition of the Rule that specifies which Mapping Set to use under which condition, followed by Setting up of the Transaction Account Definition (Figure 18) as outlined in the Table 1 above. Task List / Task Description Product Product Family Manage Account Rules Create and maintain the rules that are used to determine the accounts for subledger journal entries. Subledger Accounting Financials Manage Transaction Account Definitions Create and maintain the object that groups the account derivation rules used to derive default accounts for transactions of an application. Subledger Accounting Financials Figure 18. Sample Account Rules and Transaction Account Definition (TAD) 23

27 Intercompany Transactions Intercompany Transactions become necessary where a Business Unit other than the Receiving one bears the financial liability for purchases made. This topic will not be addressed in detail in this paper. 24

28 Recommendations The resulting organization chart and general flow of procurement transactions is illustrated below and can serve as a model to consider when setting up a shared services procurement and sourcing business unit. Figure 19 InFusion Corporation Modeled in Fusion Apps If we separate the Organizational Hierarchy from the Operational Hierarchy, the shared services model is brought into focus 25

29 Figure 20 Operational and Enterprise Hierarchy * In the Operational Hierarchy chart above, The BUs labeled Requisitioning BU perform multiple other business functions such as sales, material Management, Payables and Receivables Invoicing etc. They represent the full business operations. 26

30 Conclusion Fusion Applications allows for one business unit to source and raise purchase orders on behalf of many clients within the Enterprise. In an implementation where the subsidiary companies have a strong representation in Fusion Applications, or when the Ledgers of these companies are different, then those clients are modeled as separate business units. From the Case Study used in this document, an example would be In Fusion Financials USA and Fusion Financials India. These two legal entities have different ledgers and therefore will be modeled as separate Business Units. In an implementation where the subsidiary companies have a lighter weight representation in Fusion Applications, or when the ledger of the companies are the same, those legal entities serviced by the shared service center are modeled as balancing segment values and not separate business units. From the Case Study used in this document, an example would be In Fusion Financials USA and Fusion Consulting USA. The two legal entities have different ledgers and therefore will be modeled as a single Business Unit. A procuring Business Unit is setup to consolidated sourcing and procurement activities. This Procuring Business Unit can be an independent entity as in the Case Study in this document, or can be combined into a single Business Unit together with any of the operational Requisitioning Business Units. The legal entity on behalf of whom the purchase order is raised is identified through the Inventory Organization associated to the delivery location on requisitions and purchase orders. Accounting in the correct balancing segment is driven through the inventory organization, the delivery location and the default expense account of the requestor that drives the expense accounts on the requisition. 27

31 References Oracle Fusion Applications Enterprise Structures Concepts Guide 11g Release 1 (11.1.3) Part Number E Oracle Fusion Applications Financials Concepts Guide 11g Release 1 (11.1.4) Part Number E Oracle Fusion Applications Procurement Guide 11g Release 1 ( ) Part Number E Fusion Applications Setup Task Lists and Tasks Procurement Fusion Applications Setup Task Lists and Tasks Financials 28

32 White Paper Title May 2012 Authors: Nigel King, Elie Wazen Contributing Authors: Mike Moran, Kathy Myers Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA U.S.A. Worldwide Inquiries: Phone: Fax: Copyright 2011, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. UNIX is a registered trademark licensed through X/Open Company, Ltd oracle.com