Multi-org structure in Oracle

How to design the multiorg structure in Oracle. Best Practices and guidelines for an effective multi-org organizational structure in Oracle Applications. Defining the Organizational Structure in Oracle Applications using Multiorg functionality,

Some Basic MO entity Definition: 

The Oracle Applications organization models define organizations and the relationships among them in arbitrarily complex enterprises. This organization model serves as the cornerstone for design of all the Oracle Applications products. It dictates how transactions flow through different organizations and how those organizations interact with each other. 

The Multi org Structure in Oracle Applications supports the following basic business Needs  

• Use a single installation of any Oracle Applications product to support any number of organizations, even if those organizations use different sets of books.Define different organization models

• Support any number of legal entities within a single installation of Oracle Applications.

• Secure access to data so that users can access only the information that is relevant to them.

• Sell products from a legal entity that uses one set of books and ship them from another legal entity using a different set of books, and automatically record the appropriate inter company sales by posting inter company accounts payable and accounts receivable invoices.

• Purchase products through one legal entity and receive them in another legal entity.

• You can create an internal requisition (sales order) in one organization, then ship from another organization, with correct inter company invoicing.

• You can run your reports at the set of books level, legal entity level, or operating unit level 

1. Business Group in Oracle

The business group represents the highest level in the organization structure, such as the consolidated enterprise, a HR major division, or an operation company. The business group secures human resources information. For example, when you request a list of employees, you see all employees assigned to the business group of which your organization is a part.

2. Legal Entity in Oracle

A legal company for which you prepare fiscal or tax reports. You assign tax identifiers and other legal entity information to this type of organization. 

3. Balancing Entity in Oracle

Represents an accounting entity for which you prepare financial statements. This is a segment in the Accounting Flexfield structure (usually the Company segment) at which all accounting  entries must balance. There may be multiple companies within the same structure, and each of these must balance within itself. Each legal entity can have one or more balancing entities. 

4. Operating Unit in Oracle

An organization that uses Oracle Cash Management, Order Management and Shipping Execution, Oracle Payables, Oracle Purchasing, and Oracle Receivables. It may be a sales office, a division, or a department. An operating unit is associated with a legal entity. Information is secured by operating unit for these applications. 

5. Inventory organization in Oracle

An organization for which you track inventory transactions and balances, and/or an organization that manufactures or distributes products. Examples include (but are not limited to) manufacturing plants, warehouses, distribution centers, and sales offices. 

6. HR Organization in Oracle

HR organizations represent the basic work structure of any enterprise. They usually represent the Functional Management, or reporting groups that exist within a business group. 

7. Project Organization in Oracle

Oracle Projects allows you to define organization hierarchies to reflect your company’s organizations structure. You can add Oracle Projects– specific organization types to the organization hierarchy (for example, projects organizations or Expenditure organizations) to help you to better manage your project control requirements. You assign project and expenditure hierarchies to operating units. 

8. Asset Organization in Oracle

An asset organization is an organization that allows you to perform asset–related activities for a specific Oracle Assets corporate depreciation book. 

Checkpoints to identify Multiple Operating unit requirement: 

The following requirements / scenarios identify the design for multiple Operating Units -

Decentralized Accounting - If the division performs the Accounting functions like Payable and Receivables accounting independently and generates individual Trial Balances which are subsequently consolidated at the LE / Business group level in GL

Decentralized Purchasing – If the division independently raises a Purchase Order and the item can be received in another division and the Receiving / Inventory AP Accrual accounting is done in the Receiving division

Decentralized Sales – When you enter sales orders, you can choose any inventory organization as the shipping warehouse. The shipping warehouse may be in a different legal entity than the operating unit that enters the sales order, and it may post to a different set of books.

Data Security - You can limit users to information relevant to their division. For example, you can limit access for users to sales orders / Purchase Orders / Sales or purchase invoices associated exclusively with their division.

Inter company Accounting - Sales orders created and shipped from one legal entity to a different legal entity automatically generate an inter company invoice to record a sale between the two organizations. If the business scenario needs generation and accounting of Inter company Sale (Receivable) and Purchase (Payable) invoices it points to a multiple operating unit design

Legal Requirements: Does your organization have the knowledge of legal and fiscal requirements of all countries in which you operate? If yes, and there are diverse legal and fiscal requirements which need to be segregated from each other, then it is proper to go in for multiple operating units 

Information shared across Operating Units:

1. Flexfield definitions

2. Customer Header (customer site is at the operating unit level)

3. Supplier Header (supplier site is at the operating unit level)

4. Employee Definition 

Information specific to each Operating Units:

Cash management

1. System parameters

2. Bank accounts

3. Bank transaction codes

4. Bank Statement open interface

5. Reconciliation open interface

6. Forecasting open interface

7. Cash forecasting templates 

Order Management

1. Hold sources

2. Order types

3. Holds 

Payables

1. Supplier sites

2. Matching tolerances

3. Distribution sets

4. Bank accounts

5. Tax names and groups

6. Financial options

7. Expense report templates

8. Payable options 

Receivables

1. Auto Accounting

2. Contact phones

3. Customer address

4. Customer relationships

5. Customer bank accounts

6. Customer call information (call records, topics)

7. Distribution sets

8. Transaction sources

9. Lockbox definitions

10. Memo lines

11. Receipt sources

12. Receivables activities

13. Remit to address

14. Remittance bank accounts

15. Salesperson, sales territories assigned to salespersons

16. System options

17. Tax exemptions and exceptions

18. Tax codes

19. Tax rates

20. Tax names and groups

21. Transaction types

22. VAT taxes 

Projects

1. Implementation options

2. Expenditure types

3. Non–labor resources

4. Usage cost rate overrides

5. Expenditure type cost rates

6. Employee rates

7. Burden schedules

8. Bill rate schedules

9. Resource list

10. Project types

11. Project templates

12. Auto Accounting 

Purchasing

1. Supplier sites

2. Financial options

3. Receiving Options

4. Control rules/groups

5. Purchasing options

6. Job/position controls

7. Freight carriers

8. Document controls 

India Localization

1. Organization Additional Information

2. Tax Codes

3. Tax Category

4. Item Category

5. Supplier Additional Information

6. Customer Additional Information

7. Income Tax Authority

8. Customs Authority

9. Excise Authority

10. TDS Sections / Codes

11. TDS Details

12. TDS year Information

13. BOE Agent

14. Bond Registers

15. Assessable Price Lists 

Approach and Techniques for MO Design:

Below mentioned is the approach to identify the current Financial and Operating structure of the organization, which needs to be translated into a Multi Org design within Oracle Applications 

• The Current Financial and Operating Structure portray the legal and operating entity structures, business organizations, financial operating environments, revenue and cost centers, and financial consolidation path. It may also catalog other operating entities.

• Information about current and proposed organization structures may have been discussed during the applications acquisition cycle, and may have been one of the deciding factors in the selection of the application package. Be sure to gather this information, if available. 

• Start the internal organization analysis by interviewing the highest-ranking financial official possible, since that position will likely have the most knowledge of the financial and operating structure of the organization.

• The financial statements will reflect the operating structure to allow profitability, balance sheet and cash flow reporting, and analysis against that structure. Reporting and analysis begins by capturing and valuing operational transactions that occur at the specific event level.

• Once you create a clear picture of the organization structure, and have mapped it to the Application Multi Org design, you may want to reexamine the project plan for the application implementation, especially in the case of a financial implementation. It may make more sense to implement sequentially by organization, rather than simultaneously across the entire enterprise.   This may also impact the Application Deployment Plan, which occurs later in the project. 

Some Specific Business Scenarios which influence the MO design:

Shared Services

Any organization will have a shared services function and it is always a debate as to what are the cost benefits involved if we try to centralize these shared services function, which means we implement them in a single Operating Unit structure. The questions, which will drive the strategy, are: 

• Types of transactions to centralize

• Location for Shared Services

• Interaction with Business Units 

Business Drivers behind implementation of Oracle Apps in Shared Services (Single Operating Unit Mode) are: 

• Economies of scale

• Technology leverage

• Processes re-engineered with best practices

• Processes standardized

• Greater span of control

• Increased focus on process measurement

• Leverage specialized skills

• Sharing of information and resources across businesses

• Customer service focus 

Typical functions included in shared services 

The initial scope of Shared Services is typically focused on non-customer transactional services.

Financial Processes Shared Services

1. Accounts Payable

2. General Ledger

3. Fixed Assets

4. Accounts Receivable

5. Analysis & Reporting

6. Billing/Credit

7. Procurement

8. Treasury

9. Tax 

Human Resources Shared Services

1. Payroll

2. Travel & Expense

3. Benefits Admin 

Common back office functions can be streamlined using various solutions –

1. Document Management (Imaging and Workflow using)

2. AP Invoice Scanning

3. Routing for coding

4. Routing for approvals

5. Electronic storage

6. Expense Report receipt management 

Interaction with Business Units

In case we are deciding to implement a single operating unit structure, then create a Service Level Agreement between the Shared Service Center and the Business Unit:

1. Turnaround time on transactions

2. Different transactions included

3. Month-end closing procedure

4. Month-end closing timeline

5. Define owners for each transaction