Sunteți pe pagina 1din 20

Multi Org Setup

Revised 09/23/15

Application:

General Ledger

Setup:

Multi-Org Setup

Objectives:

1. To Setup Multi-Org

Prerequisites:

1. The General Ledger setup needs to be completed through the creation


of the Set of Books

Overview.2
Multi-Org Planning...3
Multi-Org Setup6
Effects of Multi-Org....13
Multi-Org Lessons Learned....14
Summary.......14
Appendices A and B.15

Copyright 2000 KPMG Consulting, LLC


All Rights Reserved

Page 1 of 20
/var/www/apps/conversion/tmp/scratch_2/287507009.doc

Multi Org Setup


Revised 09/23/15

Overview
It is an important lesson before beginning any efforts on a Multi-Org solution to understand basic
terminology. As you learn it becomes quite helpful to familiarize ones self with the basic terms below
and accept them as defined. Accepting and learning this terminology will make the rest of this training
paper easier to understand. This in turn will make it easier to communicate with other experienced
Multi-Org implementers and more importantly with the client.
Let us first look at the key elements:
Set of Books: This is the highest level at which the financial entities are segregated. Any entity with a
particular Chart of Accounts structure, functional currency or calendar must be a separate Set of
Books.
Organization: Any entity you define using the Define Organizations form is called an Organization.
Organizations are then assigned Classifications. The Classification(s) an Organization is assigned
determines its type and use. Business Group, Legal Entity, Operating Unit, Inventory
Organization, and HR Organization are all Organization Classifications. An Organization may be
assigned more than one Classification e.g. the Organisation Vision Operations may be assigned the
Classifications of Legal Entity, Operating Unit, HR Organization and Inventory Organization
Business Group: Represents the highest level in the structure. This may be the consolidated enterprise
or a major division of a company. Currently, Business Group has no other purpose but to segregate
HR information. If you request a list of employees (in any module) you will only see those employees in
the Business Group of which your Operating Unit is a part. Multiple Legal Entities can relate to a
single Business Group.
Legal Entity: Represents a legal company for which you prepare fiscal or tax reports. A Legal Entity
relates to a single Set of Books. Currently Legal Entity has very limited use outside of Intrastate
movement reporting.
Operating Unit: Any autonomous organization, which uses the following applications:Oracle:
Cash Management
Payables
Purchasing
Receivables
Release Management
Sales and Marketing
European Localizations

Order Management and Shipping Execution


Projects
Property Management
Release Management
Sales Compensation
Service
Latin America Localizations

An Operating Unit is associated with a single Legal Entity. the database tables in the above
products are secured by Operating Unit (e.g. customer and supplier names are shared across OUs, with
Copyright 2000 KPMG Consulting, LLC
All Rights Reserved

Page 2 of 20
/var/www/apps/conversion/tmp/scratch_2/287507009.doc

Multi Org Setup


Revised 09/23/15

sites being specific to each


Inventory Organization: An Organization for which you track inventory transactions and balances.
Oracle Inventory, Bills of Material, Engineering, Work in Progress, Master Scheduling / MRP, Capacity
and Purchasing (receiving) secure information by Inventory Organization. Inventory Organizations
may be related to any Operating Unit(s) within the same Set of Books. The relationship between
Inventory Organization and Set of Books is used for financial purposes only (creating requisitions
and replenishing supplies).
HR Organization: HR Organizations are only utilized by Oracle HR and Oracle Projects products and
have no impact on the Financial or Manufacturing applications. This facilitates a complex organization
structure for HR tracking but a more simplified structure for the operational side of the Business
Responsibility: This is a Grouping of functionality and system data often related to a job role or
responsibility. Responsibilities are associated with a Set of Books, Operating Unit and Inventory
Organization where appropriate through profile settings (e.g. MO: Operating Unit defines the
Operating Unit for that Responsibility).
Balancing Segment: 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; each of these must balance within it. All required inter-company entries will
automatically be created within the Set of Books to ensure companies can never be out of balance.
Security Rules: Security rules limit (by responsibility) the values of a Flexfield which the user will see.
E.g., a user will only see the Department values in the Accounting Flexfield which they have
authority to see.

Multi-Org Planning
In preparing a client site for a multi-org implementation, it is suggested that you combine the planning
of this part of the overall Oracle applications implementation with the Chart of Accounts Design
Workshop.
The most critical step in implementing an Oracle Multi-Org solution on any platform is careful and
adequate planning around Multi-Org details. To develop your Multi-Org model, it is often easiest to
start to think first of the Org in these three layers:
Set of Books,
Legal Entity,
Operating Unit

Copyright 2000 KPMG Consulting, LLC


All Rights Reserved

Page 3 of 20
/var/www/apps/conversion/tmp/scratch_2/287507009.doc

Multi Org Setup


Revised 09/23/15

Adopting a simplified structure of few dimensions makes it easier to work with other consultants and
clients unfamiliar with Oracle Applications and the Oracle Multi-Org functionality.
It is often easier to start in a matrix and identify these three elements first. Please note there are five
layers to a Multi-Org model and they are as follows:
Business Group,
Set of Books,
Legal Entity,
Operating Unit
Inventory Unit.
We will now look in detail at the approach to be used to develop the Multi-Org support materials; this
approach will enable you to combine the use of KPMGs R2i Rapid Return on Investment approach and
successfully implement Oracle Applications, using Multi-Org. A sample of the matrix used to
supplement the organizational model is included as Appendix A.
Step 1: Develop your Multi-Org Organizational model. Essentially this represents the clients MultiOrg organization chart. The more time that is spent developing this model before starting the actual setup, the more this will increase your chances for a successful Multi-Org validation report and accurate
view of the client organization.
Step 2: Identify in a listing format all of the Legal Entities and their names, as a pre-data listing.
Step 3: Identify all of the proposed Organizations or Operating Units. This is used as a check to ensure
that we include all Operating Units. Note: It is not uncommon to have requirements for more
operating units in applications such as Receivables than in Payables. Often, we find that because
AR represents the revenue business stream and drives the business, a need to track separate Receivables
is common. This is often supported by the best practice notion of shared service centres or centralized
Payables functions. Be aware, however, that applications that centralize functions by defining an OU
automatically determines the mode of operation of other applications using OU. For instance, you
cannot easily implement decentralized Purchasing with centralized Payables. Neither can you say that
your client will centralize Cash Disbursement but decentralize vouchering.
Step 4: Put all of the above gathered information together in one matrix. Essentially, the matrix is
formed of the following columns:
1.Organization Name, 2.Is it a Legal Entity? 3. Is it an Operating Unit? 4. Is it an Inventory
Unit? 5. Set of Books, 6.Legal Entity Name, 7.Applications.
The first column is the Organization Name. The second column identifies whether this organization is a
legal entity or not. The third column identifies whether or not this organization is an Operating Unit.
The fourth column is to identify whether or not the organization is an Inventory Unit. The fifth column
identifies which set of books the organization belongs. The sixth column identifies the legal entity name
Copyright 2000 KPMG Consulting, LLC
All Rights Reserved

Page 4 of 20
/var/www/apps/conversion/tmp/scratch_2/287507009.doc

Multi Org Setup


Revised 09/23/15

that the organization belongs. The last column identifies which applications need to support the
organization (this helps to identify which organizations do not require subledger functionality such as a
holding corporation).
Step 5: Using the details from your matrix put them in to a graphical organizational format. Draft the
organizational chart as follows:
First, list your Sets of Books across the top, treating them as an equal top tier of your organization.
Next using your matrix create a Legal entity layer on your organization chart for all legal entities,
properly aligning the legal entities with their respective Set of Books.
Next add the Operating Unit layer, for any organization you identified as an Operating Unit you need to
add a box to represent them graphically aligned under their respective legal entity. Note it is possible to
have more than one Operating Unit associated with one legal entity (it can be a many to one). Appendix
A contains an example of the graphical layout.
It is very critical at this point to review both your matrix and graphical representation ensuring that you
have all organizations from your matrix represented. Next, review with the client both for accuracy and
for completeness. Often-new operating units are identified after first discussion. Some tips to help you
ensure you have all the components are as follows:
1. Does every Set of Books (SOB) have at least one Legal entity? (If not you may want to find out
what the SOB represents)
2. Do you have at least one Operating Unit listed for any legal entity which resides in a different set of
books which you identified the need to use a subledger application such as AP, AR, OE, PO, or INV?
Note: you can have one Operating Unit support many legal entities within the same set of
books, granted you do not have a requirement for data separation (such as security at a
supplier site level by entity).
3. Ask yourself and then ask the client, do we need to issue statements, invoices, and track Receivables
for multiple companies tracking them at the individual company level and have separate reporting? If
so, verify that you have an operating unit for each of these.
Once you have verified all of the information gathered to date, add the remaining 2 layers to the
organizational chart the Business Group and Inventory Org layers. Unless you have a defined
requirement for more than one HR Business Group, then you can list the HR Business Group at the top
of the organizational model with all Sets of Books reporting to the HR Business Group. Lastly, add
your inventory Orgs to the model identifying them with the appropriate Operating Unit. Even if you
are not using inventory, you will still need to identify at least one inventory org for each
operating unit. If you are implementing Inventory, ensure that you validate and create all
necessary inventory Orgs that you need to meet your requirements.
Before, moving into set-up, another area that is worthwhile to pre-plan is identifying the responsibilities
you need to access each subledger-operating unit. As a minimum, you need to identify a super-user or
manager responsibility for each operating unit for each subledger to perform set-up activities required
Copyright 2000 KPMG Consulting, LLC
All Rights Reserved

Page 5 of 20
/var/www/apps/conversion/tmp/scratch_2/287507009.doc

Multi Org Setup


Revised 09/23/15

at the operating unit-subledger level. This will help ease the facilitation and management of ensuring all
of the necessary profile options are updated for each responsibility for each operating unit. The correct
setting of all necessary profile options could avoid significant administrative problems for the project
team.
A tip that could prove helpful to managing this effort is to create a Responsibility / Profile Matrix. The
matrix should list the necessary profile options settings necessary for each responsibility. This matrix
can then be used as a document for checking progress against each specific option for each
responsibility as it was completed. For example in a recent project in the U.S, there were five operating
units for Receivables and five custom responsibilities for Receivables. This resulted in 25
responsibilities just for Receivables, with at least nine profile options for each responsibility, which need
to be verified or updated. In this example, it would have been risky to manage this volume without a
structured approach. A sample of the matrix is included as Appendix B.
Multi-Org Set-up
As with any traditional implementation plan, after understanding the basics, careful planning and analysis you are ready
to begin set-up. The set-up tasks specific to Multi-Org need to occur before initiating the set-up for any of the subledger
modules (such as AR, AP, OE, PO, INV, etc.). This occurs first because there is a utility that your DBA initiates for MultiOrg, which essentially partitions the database for the operating units. Once this activity has taken place there are several
set-up steps within each module, which is affected by Multi-Org in one capacity or another. The effects of Multi-Org will
be discussed in the next section.
A list of the Multi-Org set-up steps and order are listed below. Refer to the R2i Multi-Org Configuration Guide. A brief
description of each step is located in the Oracle Multiple Organization Reference Manual - the part number is listed
following this section. There are 21 potential Multi-Org set-up steps identified as the following:

(MO 1) Develop the Organizational Structure (see section 2)

(MO 2) Define Set of Books


Set of books will be defined in the GL set-up. Depicted is the R2i Set of Books, Refer to the GL
configuration guide for more detailed information on the steps to follow in setting up your set of
books. Note if your company structure requires that you define a business group, define the set of
books before the business groups.
Note if you have a set of books which does not have a requirement for subledgers, the setup for
these SOBs can be done after the conversion to Multi-Org. The postponement of these SOBs
allows you to get through the Multi-Org specific setup steps sooner, allowing the subledger modules
to begins setup sooner.

Copyright 2000 KPMG Consulting, LLC


All Rights Reserved

Page 6 of 20
/var/www/apps/conversion/tmp/scratch_2/287507009.doc

Multi Org Setup


Revised 09/23/15

(MO 3) Define Multiple Business Groups if not using default.


Oracle Applications provides default Business Group: Setup Business Group. Create additional
Business Group(s) associated with the planned Organization Structure.
If the client requires multiple Business Groups, you must define all of the Business Groups at
this point.

Copyright 2000 KPMG Consulting, LLC


All Rights Reserved

Page 7 of 20
/var/www/apps/conversion/tmp/scratch_2/287507009.doc

Multi Org Setup


Revised 09/23/15

(MO 4) Create an Inventory Responsibility and assign the Set of Books and Business Group. This
is a System Administrator exercise.

(MO 5) Log on to the Responsibility defined in MO 4 with the assigned Business Group and Setup
of Books.
Do not define any new organizations or organization hierarchies until you have associated
each business group with a responsibility.

(MO 6) Define Locations for the Legal Entity, Operating Unit and Inventory Organization.

(MO 7) Define Organizations Structure and Relationship Legal Entity


In the define organization window define organizational relationships by assigning classifications to
each organization. You can classify an organization as any combination of legal entity, operating unit
and inventory organization. Specifications can only be done in the following order: 1.Legal Entity,
2.Operating Units, 3. Inventory Organizations. Refer to the Oracle Multiple organizations manual for
more detailed information on set up

Copyright 2000 KPMG Consulting, LLC


All Rights Reserved

Page 8 of 20
/var/www/apps/conversion/tmp/scratch_2/287507009.doc

Multi Org Setup


Revised 09/23/15

Create the Legal Entities for the Business Group. The Legal Entity will be tied to a Set of Books
defined in General Ledger.

(MO 8) Define Organizations Structure and Relationship Operating Unit


Create the operating units for each legal entity, and link each operating unit to the legal entity.
Copyright 2000 KPMG Consulting, LLC
All Rights Reserved

Page 9 of 20
/var/www/apps/conversion/tmp/scratch_2/287507009.doc

Multi Org Setup


Revised 09/23/15

(MO 9) Define Organizations Structure and Relationship Inventory Organization


Create an inventory organization for each operating unit. The inventory organization will be tied to
the set of books, legal entity, and operating unit defined in the Multi-Org Setup.

(MO 10) Define Responsibilities

Copyright 2000 KPMG Consulting, LLC


All Rights Reserved

Page 10 of 20
/var/www/apps/conversion/tmp/scratch_2/287507009.doc

Multi Org Setup


Revised 09/23/15

In sysadmin use the define responsibility window to define the responsibilities for each subledger
application associated with each operating unit. When a user signs onto Oracle Applications, the
responsibility the user chooses determines the data, windows, menus reports and concurrent
programs that user is authorised to access.

(MO 11) Set Business Group Profile at each Responsibility


For the profile option HR: Business Group, set the profile option for each responsibility, either to
Setup Business Group, or if appropriate, a newly created Business Group.

(MO 12) Set Operating Unit Profile Options at each Responsibility


In System Administration, define the appropriate MO: Operating Unit for each responsibility.
At the site level, a default operating unit must also be set in order to be able to convert to multi-org.
For a fresh installation, the default can be any operating unit desired.

(MO 13) Conversion to Multi-Org


Conversion to multi org requires the assistance of a DBA or System Administrator. Ask the Database
Administrator to run the Autoinstall facility adadmin. This function should be used for a standard
installation or a multi-org installation. An option within adaadmin is to convert to multi-org
architecture. In choosing this option, this will enable the multiple organization support feature and
add operating unit context to existing data. This process will also copy seed data to all operating
units that have been defined. If adaadmin has previously been run, use the Replicate Seed Data job in
system administration to update the organization and run the multi org reports to verify the process

(MO 14) Change Order Management Parameter


The Oracle document, Multiple Organization Setup and Implementation, indicates that the OM:
Item Validation profile must be set at the responsibility level. In prior releases of the Oracle
applications, there was an OE: Item Validation Org that need to be set at the responsibility level.
However in release 11i, there is an Item Validation Org parameter in Inventory that must be set to
the proper operating unit during Order Management Configuration.

(MO 15) Set Profile Options Specific to Operating Units


A number of profile options need to be set for each responsibility for each operating unit where
applicable. These include but are not limited to GL: Set of Books, and HR: User Type. Refer to the
R2i configuration guide, and the Oracle Manual Multiple Organizations in Oracle Applications for
a complete list of profile options that need to be set for each responsibility.

Copyright 2000 KPMG Consulting, LLC


All Rights Reserved

Page 11 of 20
/var/www/apps/conversion/tmp/scratch_2/287507009.doc

Multi Org Setup


Revised 09/23/15

Some profile options such as AR: Receipt Batch Source and AR: Transaction are secured by
operating unit, and when they are set, they have to be set for each operating unit at the responsibility
level.

(MO 16) Define Inventory Organization Security (Optional)


Within Inventory Organization Security, access to inventory organizations can be restricted to
specific responsibilities. For example, the client may wish to restrict the Manufacturing users to
certain organizations according to the organization heirachy.

(MO 17) Setup Subledger Applications


This qualifies as the point at which modules other than General Ledger can begin their set-up
activities. It is important to carefully co-ordinate the start of these activities and make sure your
project team members use the newly defined Operating Unit responsibilities to complete set-up.
Remember that OU-specific applications need to have setup done for each defined operating unit.

(MO 18) Secure Balancing Segment Values by Legal Entity (Optional)


Using the define security rule window create rules that secure data entry of balancing segment
values for each legal entity. Each security rule is composed of one or more security rule elements
that specify a range of values to include or exclude.

(MO 19) Verify Multi-Org Setup


Run standard Multi-Org Validation Setup Report to identify any problems with the set-up. Resolving
any identified exceptions on the validation report eliminates the risk that a missed setup step is the
cause of any unforseen future issues making the trouble-shooting process easier.

(MO 20) Implement Document Sequencing (Optional)


After Multiple Organizations have been implemented, document sequencing can be setup. This is a
common requirement for European companies.

(MO 21) Define Intercompany Relations (Optional)


Define Intercompany Relations is only necessary when using the Multiple Organization
Intercompany Invoicing functionality. Intercompany relations need to be defined for each
Shipping/Selling relationship in the organization. Defining these relations will allow for the creation
of automatic intercompany invoices.

(MO 22) Set Top Reporting Level Profile (Optional)

Copyright 2000 KPMG Consulting, LLC


All Rights Reserved

Page 12 of 20
/var/www/apps/conversion/tmp/scratch_2/287507009.doc

Multi Org Setup


Revised 09/23/15

The reporting level a user can choose is restricted by the reporting option MO: Top Reporting
Level. The three choices available for this profile are: Set of Books Level, Legal Entity Level, and
Operating Unit Level.

(MO 23) Setup Conflict Domain (Optional)


A conflict domain is an abstract representation of the groupings used to partition data. When a
program is listed as incompatible with another, the two programs cannot run simultaneously in the
same conflict domain. Two incompatible concurrent programs may run at the same time if they are in
different conflict domains. To maximize the concurrency in a multiple organization environment,
conflict domains can be setup for operating units.

Copyright 2000 KPMG Consulting, LLC


All Rights Reserved

Page 13 of 20
/var/www/apps/conversion/tmp/scratch_2/287507009.doc

Multi Org Setup


Revised 09/23/15

Effects of Multi-Org
As you continue through the implementation or upgrade to the multi-org process, it is important to keep
in mind and understand the effects of Multi-Org. This section will describe some of the aspects, which
are important to understand during this process. Some of these elements may affect how you define
your operating units or how many of them you define; others can be classified as informational to
understand what it means to your data and/or functional groups. This section is not going to represent
all of the potential effects, but will highlight some of the ones which we have learned through our US
implementation experience.
The introduction of Multi-Org into an implementation model introduces the concept of shared
elements and non-shared elements. Shared elements can be defined as items which are either shared
across operating units within a Set of Books or shared across operating units, and Sets of Books, within
a database instance. It is important to realize that later means that some set-up components are shared
across Sets of Books being available to all operating units defined in a particular database instance.
Non-Shared elements can be define as set-up components which are not shared across the operating
units, which means for each operating unit established you would need to perform this set-up step.
Some examples of each category are located below:
Examples of:
Set-up Components which are shared across Operating Units within a Set of Books:
AR Periods, Open/Close AR Periods.
Set-up Components, which are shared across Operating Units and Sets of Books, within a database,
instance:
Flexfield Definitions, Customer Headers, Supplier/Vendor Headers, Customer Profiles, Locations, Bank
Headers.
Non-Shared Components:
AR Transaction Types, AR/AP Bank Account Details, Customer Sites, Supplier/Vendor Sites.
Some of the traditional time estimates for entering set-up may need to be increased to accommodate for
the increased effort to set-up all the non-shared steps for each operating unit. Every implementation has
variables and conditions that make it unique in its own sense. However, what we found is that after
having done this a number of times, that we used an estimate of an additional day effort for each
operating unit. For example if we had 5 operating units for AR, if we were keying a full set-up, we
added an additional 2 days to our traditional time estimate for performing activities for the AR
module. Note that our estimate assumes the use of resources experienced in performing set-up.

Copyright 2000 KPMG Consulting, LLC


All Rights Reserved

Page 14 of 20
/var/www/apps/conversion/tmp/scratch_2/287507009.doc

Multi Org Setup


Revised 09/23/15

Multi-Org Lessons Learned


In addition to the items noted throughout this guide, this section will highlight some of the additional
lessons we have learned from our US multi-org implementations.
When defining your General Ledger responsibilities, if you are planning to use the standard SmartClient
drill down capabilities, you will need to define a separate GL responsibility for each operating unit you
require drill down capabilities. Responsibilities are tied to an operating unit, and it is a one-to-one
relationship. For example if you have 3 operating units and you allow GL Inquiry users to utilize drill
down capabilities into AR, you will need 3 GL Inquiry responsibilities. If one person in your
organization is responsible for all three operating units, they will have three responsibilities assigned to
them in order to access the drill down functionality.
When designing and planning for data conversions into an Oracle multi-org environment you should
keep in mind the impact that, the number of operating units can have. For example, if you have three
operating units for AR and you need to convert your open balances. You will need to do this at an
operating unit level and run the Auto-Invoice programs for each operating unit, thus effectively
increasing the number of jobs to covert that you may need to run by three. An additional point to keep
mind specifically for AR is that the Auto-Invoice process is typically spawned to optimize the execution
process of this resource intense job. Typically for most organizations, this results in only one operating
unit being converted at time. So, plan accordingly! Note these factors are dependent on individual
platform, memory, processor and concurrent manager configurations.
Clients that are implementing decentralized ordering are always staggered when they realize that Sales
Organizations that share customers have to re-enter the same record in different OUs.
Clients that have sought to implement Shared Services for Payables while retaining their separate
Purchasing organizations have to deal with the Multi-Org limitations. Operationally, this means they
have to set-up multiple Supplier Site records. Upon payment time the Payables Staff not only have to
use different responsibilities, but they also cannot combine check payments for the same supplier
servicing different OUs.
When you disable an organization, there is no relationship revalidation for the LE-OU-Inventory
Organization hierarchies so you really have to be careful.
Summary
In Conclusion, Multi-Org can be implemented successfully in a rapid or traditional implementation
timeframe. As in any implementation on any platform, proper planning is critical. Take the time
with the client to plan and review your multi-org requirements and understand them with your business
processes, it will support your efforts to a successful implementation on any platform.

Copyright 2000 KPMG Consulting, LLC


All Rights Reserved

Page 15 of 20
/var/www/apps/conversion/tmp/scratch_2/287507009.doc

MO Multi Org Setup


Revised 23/09/15

APPENDIX A
Multi-Org Set-up Chart Details
Set of Books
Set of Books Name

Copyright 2000 KPMG Consulting, LLC


All Rights Reserved.

Functional
Currency

Accounting Flexfield Structure

Calendar

Page 16 of 18
/var/www/apps/conversion/tmp/scratch_2/287507009.doc

MO Multi Org Setup


Revised 23/09/15

Organizations
Organization Name

Copyright 2000 KPMG Consulting, LLC


All Rights Reserved.

Page 17 of 18
/var/www/apps/conversion/tmp/scratch_2/287507009.doc

MO Multi Org Setup


Revised 23/09/15

Organization Multi-Org Matrix


Organization Name

Copyright 2000 KPMG Consulting, LLC


All Rights Reserved.

Is it a Legal
Entity?

Is it an
Operatin
g Unit?

Is it an
Invento
ry Unit?

Set of Books

Legal Entity

Operating.
Unit

Application
s.

Page 18 of 18
/var/www/apps/conversion/tmp/scratch_2/287507009.doc

MO Multi Org Setup


Revised 23/09/15

APPENDIX B
Responsibility Profile Options
Module

Responsibi HR:
Business
lity
Group

EX:
AR

OE:Set of Sequentia
GL:Set of AR:Recei OE:
Books
pt Batch Transacti Books
l
Source
o Batch
Numberin
Source
g

INV:Inter
compan
y
Currenc
y
Conversi
on

Tax:Allo Tax:Inveto Tax:Invoic


ry Item
e Freight
w
for
Freight
as
Override
Revenue
of Tax
Coded

AR Collector

Copyright 2000 KPMG Consulting, LLC


All Rights Reserved.

Page 19 of 18
/var/www/apps/conversion/tmp/scratch_2/287507009.doc

MO Multi Org Setup


Revised 23/09/15 for Release 2.2

Copyright 2000 KPMG Consulting, LLC


All Rights Reserved.

Page 20 of 18
/var/www/apps/conversion/tmp/scratch_2/287507009.doc

S-ar putea să vă placă și