You are on page 1of 1

http://oracleappsoneworld.blogspot.com/2012/04/considerations-for-multi-country.

html
Considerations for Multi country implementation of Oracle Apps

Best-practice framework in a multi-legislation, multi business group
environment:
Below are a sample of our considerations and best practices while implementing Oracle Applications in a multinational Company with employees across the globe:
1)
2)

a.
b.
c.
d.
e.
f.
3)

4)

5)
6)

7)

Understand business vision: Structured analysis of the current business operations and future growth plans.
Finalize Organizational Modelling: Driven from the vision, plan for number of business groups, legal entities
and set of books to be implemented. The best practice is that if there are multiple companies operating as different
entities in the same country, their representation in Oracle should be as different Legal Entities within a single
business group. Some of the other considerations which help in in making a decision on the number of business
groups include:
How many countries does the business operate in?
How many of these countries have Oracle provided legislation?
For countries for which Oracle does not deliver a legislative pack, how many employees does the business
currently have and what are the future growth plans in these countries?
Can one single business group be used for employees across multiple countries, each having a small number of
employees? (Each additional business group represents additional maintenance costs over the lifecycle of the
application)
Are external payroll providers being used in any of the countries? If yes, what data needs to be provided to them to
process payroll?
Are there any specific legislative needs (in terms of reporting or privacy) for each country?, etc.
KFF and DFF design: KFF (or Key Flexfield) is used to capture key company information, such as how are jobs and
positions represented across the company. While each country may have differing requirements, it is important to
consider global consolidated reporting requirements, which typically needs uniformity across countries. A typical
approach to address global as well as local concerns is to have common global fields across all countries, followed
by a flexible number of local or country specific fields. A similar consideration needs to be adopted for DFFs
(Descriptive Flexfields), through defining appropriate “DFF contexts”.
Instance strategy: How many instances should be deployed for Production? Whilst often overlooked in initial
design, this is a key operational decision to make. While one instance is obviously the best strategy, there may be
practical reasons for going for multiple production instances. This is mainly driven by how business-critical the
application is, and how much regular maintenance downtime can be accommodated.
Employee numbering: Should employee numbering be Global or local? Global numbering would mean that there
are gaps in the sequence of any specific country. Local numbering would mean a repetition of employee numbers
across countries. An alternate best practice approach to this scenario would be to use “unique” local numbering.
Design Security: Understand who in the business would need access to which part of employee data and also to
what population of employees. Data privacy laws are very different between countries and this drives the data
security design. Also, current and future business processes should be analysed to understand whether data is
maintained locally by each business unit or by shared services. The best practice to adopt here is the sharedservices approach, which recommends centralization of resources for better operational efficiencies.
Reporting: At the minimum, each country where the company operates as a registered business needs mandated
legislative reporting. Rather than building a separate report for each country, a good practice is to analyse and
group similar reports across countries. Next, build “master” database views that include all columns needed to
produce all related reports across countries. Through use of XML Publisher templates or Discoverer Reports, each
country can then easily customize the output from these views to consider only relevant columns for the country.
This practice reduces maintenance and gives more flexibility in the hands of businesses to drive the format of
report presentation.