2006 Oracle Applications User Group Collaborate ‘06 April Nashville, Tennessee OAUG Multi-National SIG Group Managing Global and Local Data Elements Gavin Cockayne and Ash Patel, IBM-Consulting Hans Kolbe, Celantra Systems

Global Instances come at a price. There are numerous data elements which are global in nature and are shared across the instance. This creates challenges for global implementation and support teams: 1.Global Visibility can lead to confusion through inconsistent and duplicate data 2.Compliance and Control Issues through unauthorized access across organizations This is a critical issue for global implementations. It has not been sufficiently addressed in project preparation or functionality. It will not surface, until the project is well underway. Global Data Elements – What is the problem ?

All data elements must be included in the analysis. In most cases, potential issues regarding “Global Data Elements” can be resolved using the following methods: Naming convention - Develop a global naming convention so that users are aware of their elements. Restricted setups - In some cases, restriction to certain setups can avoid issues. Education – Educating ALL parties of the potentials issues they could cause and other could cause them is sufficient. Global Police - A team of functional experts who role is to monitor and control global elements Automation of Data Visibility and Access Control – what tools are available? Global Data Elements – General Approach

Perspectives for Naming Conventions and Data Access Process Definition Operators: Find the right customer, vendor, payment term quickly. Operators in countries and factories, Operators in Shared Service Centers Analyst: Certainty of data - an apple is an apple Ease of sorting and extracting: same data element is in the same spot (descriptions – codes) Application Support: know where to find a problem, quickly resolve user issues Interfaces and extracts: Banking, CRM Systems, warehouse and inventory systems Data Migration: Identify data elements that are touch points, Identify missing data elements and defaults, Methods to identify and eliminate duplication, Reconciliation methodology Compliance: Determine impact of each data element, Assign owner to each data element, Assign process of entry and updates, Assign controls and process to measure compliance

Example Listing of Data Elements

Example of Identification Needed

Journal Sources - Sources can be used globally and in most cases seeded sources are used globally, however, if changes are made to one of these sources e.g., requires approval then this change will affect all locations that use this source. Cross Validation rules – Since cross validation rules can be accessed by anyone who has access to setup, it is critical that access is restricted and users are educated in the potential issues this could cause if not taken seriously. Solutions Police all seeded sources and do not allow changes to any seeded source. Use naming conventions to differentiate sources belonging to different entities. Examples of Solutions - GL

AR Payment terms: Since this is functionality drives credit checking, discounts and due dates, it is imperative that this is looked at globally. Solution: Education and Naming convention. Customer headers - Customer headers are Global since some critical info is held at this level this could cause serious problems. For example if you are using “Sales Channel” as a qualifiers in pricing, if this is changed all pricing will be affected. Solution: Custom pll – to associate customer to responsibility and restrict changes to customer setups if it is not your customer. AP Payment terms - Since this drives when you pay your suppliers and discount you take, changes to this could be costly. Solution: Naming convention, education OM Price Lists – Price lists headers are global and if the same items are used in various orgs then the prices for those styles are available to all orgs Solution: Custom pll - to associate pricelist header to responsibility and restrict changes to price lists if it is not your price list. Pricing Modifiers are global - Access to modifiers and qualifiers are global Solution: Functionality - Use Selling Org as first qualifier.. Examples of Solutions – AR, AP, OM

Detail –Customer Naming Convention TopicRequirement Option AOption BComment Customer Header Use Clear definition of customer header and its use for data conversion, financial and analysis reporting. Option A) Each separate Legal establishment of the Customer i.e. Adam Opel GmbH Deutschland Option B) Customer Enterprise Name i.e. Opel Option A has been selected Legal Name printed on external documen ts Correct printing is essential for collections in AR. Legal names may be identical in 2 different countries. Belgium and France both use SA, Austria and Germany GmbH Customer name changes can be accommodated easier. Legal Name is defined in a separate field on header Legal Name must be defined on bill-to and ship to addresses Decided that a different field will be used for printing Customer Address Use Customer Addresses are separated by Operating Unit. Needed for billing and shipping Each Address will be used for one purpose only Addresses can have multiple purposes

Detail – Customer Naming Convention Customer Header Naming Convention assuming one header per legal establishme nt Easy and quick identification for customer service and finance staff across all entities. No duplication. Prefix or Suffix of Entity dealing with this customer XXXX. Followed by Space then customer name without Inc. GmbH extension, all in Caps. Customer’s Legal Name only. Alternative: Suffix (LL) country code identifying the country of customer legal establishment, not necessarily the country of the PPG entity dealing with the customer How to find customer header quickly Many customers may have similar or same names Allows to narrow search to my entity’s clients Alternative will allow to limit search to 1 country Access/ Use by multiple entities Headers are accessible from all OUs Naming convention would give clear separation and provide some protection against accidental changes and overrides. Risk is limited through business process. All changes done through central group.

Questions - Discussion Has anyone encountered any other global data elements? Purchasing/AP tolerances, Order Holds, AP Aging Periods, PO Approval Groups Customer Headers are now Org stripped!? Has anyone suggested any other solutions to global data issues? How much time on your project is dedicated to discussing global elements? Not enough How do you think Oracle should address global elements? Not sure yet. Reference Data – like inventory items with Master Org. What tools exist to help in this process?