Multi-Org Structure in Oracle 11i Applications – a compilation from Oracle Manual

Overview:

The Oracle Applications organization models define organizations and the relationships among them in arbitrarily complex enterprises.

It dictates how transactions flow through different organizations and how those organizations interact with each other.

Features:

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

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

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

•Can sell products through one legal entity and ship them from another. The system automatically recognizes the inter-company sale between the shipping organization and the selling organization by generating inter-company invoices.

Levels of Organization:

•Set of Books

•Business Process

•Legal Entity

•Operating Units

•Inventory Units

Set of Books (SOB):

A financial reporting entity that uses a particular chart of accounts, functional currency, and accounting calendar.

Oracle General Ledger secures transaction information (such as journal entries and balances)by set of books. When we use Oracle General Ledger, we choose a responsibility that specifies a set of books. We then see information for that set of books only.

Business Group:

The business group represents the highest level in the organization structure, such as the consolidated enterprise, a major division, or an operation company. The business group secures human resources information.

For example, when we request a list of employees, we see all employees assigned to the business group of which our organization is a part.

Legal Entity:

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

Operating Unit:

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. Each user sees information only for their operating unit. To run any of these applications, we choose a responsibility associated with an organization classified as an operating unit.

Inventory Organization:

An organization for which we 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.

The following applications secure information by inventory organization:

Oracle Inventory, Bills of Material, Engineering, Work in Process, Master Scheduling/MRP, Capacity, and Purchasing receiving functions.

To run any of these applications, we must choose an organization that has been classified as an inventory organization.

Limitations on Multiple Operating Units per Set of Books:

•Multiple Organizations enabled products do not support viewing secured data across operating units.

•Multiple Organizations enabled products, process transactions within an operating unit. There is no additional support for centralization/decentralization of business functions.

•When the Multiple Organizations enabled products post to Oracle General Ledger, you need to run the posting process from each operating unit. You cannot run the posting process for all operating units in the set of books in a single process.

•In–transit shipments across organizations in different sets of books are not supported.

•Supplier and customer tables are shared across operating units. However, you must define supplier sites and customer addresses for each operating unit. For example, if multiple operating units buy from the same supplier site, the supplier site must be defined once for each operating unit.

•You should not specify any centralized statements site, centralized dunning site, customer–level order type, or customer–level salesperson because customer addresses, order types, and salespeople are not shared across operating units.

•You should specify the tax code at the customer level only if you have identical tax codes across operating units.

•The Customer Merge process allows you to merge only addresses and sites within the same operating unit, since transactions are secured by operating unit. If a customer has active addresses in other operating units, the Customer Merge process does not make the customer inactive.

•You can receive against purchase orders only in the operating unit to which your responsibility is connected.

•Legal entity reporting (such as tax reporting) that involves sub ledger products is done at the operating unit level. If all the operating units for a given set of books belong to the same tax reporting entity, you must sum the tax data manually.

For Oracle R12, the Multi-Org Structure differs from 11i. Features of R12 Multi-Org Structure will be published shortly.