Oracle cloud-multi-pillar-implementation-best-practices-wp

Multiple Pillar Oracle Cloud Implementation
Best Practices
Cloud Financials and Cloud HCM
O R A C L E W H I T E P A P E R | S E P T E M B E R 2 0 1 7

1 | MULTI PILLAR ORACLE CLOUD CONFIGURATION BEST PRACTICES
Table of Contents
Introduction 3
Revisiting Key Dependencies between Oracle HCM and Financials Cloud 3
Common Implementation Considerations 5
Which One to Start First? 6
GSI versus Non-GSI Environments 6
Defining Enterprise Configurations – An Overview 7
Enterprise Structures Configurator (ESC) 7
Rapid Implementation Templates for Financials 9
Legal Entities 10
Divisions 12
Ledgers 12
Business Units 13
Reference Data Sets 14
Jobs and Positions 15
Departments and Cost Centers 16
Security and Roles 16
Data Conversion 17
Integration 18
Key Interfaces– Global Payroll 18
Key Interfaces– Planning and Budgeting 19
Workflow Approval 19
Deployment Considerations – HCM and Financials Concurrent (Big Bang) 21

Deployment Considerations – HCM First then Financials (Phased) 21
Deployment Considerations – Financials First then HCM (Phased) 23
Conclusion 24
Appendix – Summary of Financials/HCM Configuration Best Practices 25

Introduction
We have all heard the adage “A chain is only as strong as its weakest link.” Applying this concept to
business software like Enterprise Resource Planning (ERP), we would conclude that a business
solution is only as strong as its weakest integration. Usually overlooked and underestimated,
integration is one of the most important factors to consider as part of your enterprise implementation.
Oracle Cloud Services is an integrated service across Financials (ERP), Human Capital Management
(HCM), Supply Chain Planning (SCM) and Customer Experience (CX) solutions. This white paper
provides implementation leading practices to system integrators who are about to assist customers
with new Oracle Enterprise Cloud Service implementations. The purpose of this whitepaper is to
identify these dependencies and provide you with the information to make informed decisions.
The initial scope of this document will focus on the following ERP and HCM Cloud implementation
scenarios:
» Big Bang Financials and HCM are implemented at the same time.
» Financials then HCM (Phased) Financials is implemented first then HCM is implemented in a
future phase.
» HCM then Financials (Phased) HCM is implemented first then Financials is implemented in a
future phase.
Note: Additional pillars (CX, PPM, and SCM) will be added in a future document release. This is a living document
that will evolve as service policies and features evolve.
This whitepaper will holistically address key configuration decisions and cloud deployment best
practices. The purpose of this whitepaper is not to replace but rather compliment individual
whitepapers and user documentation on individual Oracle Cloud applications.
Revisiting Key Dependencies between Oracle HCM and Financials Cloud
Regardless of the Oracle Cloud solution deployed initially, it is important to plan and consider key information that is
shared across the Oracle Cloud solution. Following is a summary of the information sharing between the Oracle
Cloud Financials and HCM solutions:

Sales &
Marketing
Fixed Assets Purchasing
Accounts
Payable
Field Service
Projects Inventory
Accounts
Receivable
General
Ledger
Expenses
Human Capital
Management
• Employees
• Assignments
• Employees
• Organizations
•Jobs/Positions
• Hierarchies
• Locations
• Competencies
• Time and Labor
• Employees
• Organizations
• Ledgers
• Legal Entity
• Cost Centers
• Payroll Expense
• Employees
• Competencies
• Employees
• Assignments
• Employees
• Assignments
• Employees
• Expense Acct
• Organizations
• Jobs/Positions
• Employees
• Compensation
• Employees
• Assignments
Figure 1. Key Information Sharing between Oracle Cloud Financials and Oracle Cloud HCM
SHARED FOUNDATION DATA BETWEEN ERP AND HCM
» Addresses » Locations
» Assignments » Organizations
» Banks and Bank Accounts » People
» Business Units » Periods of Service
» Competencies » Person Types
» Expense Account » Phones
» Jobs » Positions
» Legal Entities » Qualifications
» Ledger » Departments
KEY INTEGRATIONS BETWEEN FINANCIALS AND HCM
Source Target Transaction Integration
HCM Financials » Payroll Expenses (Distribute Payroll Accounting)
» Time & Labor to Project Costing ( Process Project Cost Transactions)
» Person Information (if not using Oracle Cloud)
» Employment Information (if not using Oracle Cloud)
» Approval Management (Understanding Approval Management)
Historically, Financials and HCM solutions were implemented across multiple database instances, which required
additional point integrations to facilitate configuration and transaction sharing. With Oracle Financials and HCM

cloud services, you have a single data model that eliminates a majority of point integrations. However, because of
this tight integration model, it is important that you consider key configuration decisions across the enterprise
solution, regardless of your specific implementation project scope. Consider the following specific dependencies
you may face.
Expenses
Expenses utilize the employee’s HCM assignment to default the following information:
 Ledger and Chart of Accounts association derived from employee’s assignment Business Unit.
 Legal Entity derived from employee’s assignment Legal Entity (which is derived from the HCM Legal
Employer).
 Expense template based on the employee’s assignment Business Unit.
Projects
Projects utilize the employee’s HCM assignment to default the following information:
 Ledger and Chart of Accounts association are derived from an employee’s assignment Business Unit.
 Legal Entity is derived from primary Balance Segment Value (BSV) of Project charge account.
Self-Service Requisition
The Self-Service features of Procurement Requisitions utilize the employee’s HCM assignment record to default the
following information:
 Self services users are automatically granted the ability to create requisitions in the employee’s
assignment Business Unit.
 Managers are automatically granted the ability to report on the data in their employee’s assignment
Business Unit.
 The default security access can easily be modified to "point at" the correct requisitioning Business Unit.
Approvals
 Financials users needing approval roles (initiators, approvers) must have both a relationship and
Assignment record via employee hire process for approval functionality to work properly.
Deep integration enables effective data sharing; however, it requires a greater understanding of key configurations
across the solution. In the next steps, we will explore the key configurations to address as part of a multi-pillar
implementation.
Common Implementation Considerations
Oracle Cloud Services provides you the flexibility to implement the Financials and HCM Cloud services in either a
phased or concurrent “big bang” deployment approach. In the following sections, we will discuss the key decisions
and main deployment scenarios for a multi-pillar implementation. Remember that requirement management
(gathering, reviewing and validating business requirements) should cover all the Oracle Cloud services
deployment(s). Otherwise, you may increase the risk of implementing conflicting requirements and/or configurations
that will limit your Oracle services business value generation.

Which One to Start First?
Technically speaking, there are no barriers to start with either Oracle’s Financials or HCM cloud services. Oracle’s
Functional Setup Manager (FSM) has the ability to identify the dependencies regardless of starting with either HCM
or Financials first. However, what can easily be overlooked is the impact that people and organizations play with an
implementation. Organizational readiness/availability - which organization is better prepared to support a cloud
implementation, is a key factor for consideration.
To assist you with organizational fit, we recommend that you perform an organizational assessment leveraging the
detailed business process maps in My Oracle Support (MOS).
Figure 2 – Organization Gap Analysis
Essentially you want to compare how your existing organization’s structure (role and processes) aligns with the
Oracle Financials and HCM cloud services delivered roles and responsibilities. This exercise will help quantify the
organization change required for a successful implementation. This analysis will also provide insight into the
potential role mappings that may need to be performed in managing role mappings.
GSI versus Non-GSI Environments
Historically, Oracle Cloud services provide two types of environments to support your cloud services. A Global
Single Instance (GSI) is an environment that can support the entire Oracle Cloud Application Product suite including
CX, Financials, HCM, PPM, and SCM. A Non-GSI environment is an environment that can only support a single
Oracle Cloud Application Product suite. Oracle HCM Cloud and CX Cloud are the only individual service offerings
that may have been deployed in a Non-GSI environment.

Note: With the Release 13 upgrade, all existing Non-GSI environments will automatically be upgraded to GSI
environments. This will create greater flexibility for existing Oracle HCM-Only Cloud customers to utilize other
Oracle Cloud service offerings.
For new customers moving forward, all environments will be provisioned as GSI pods.
Defining Enterprise Configurations – An Overview
Oracle HCM and Financials Cloud provides a series of tools to guide and support you during this most important
step in your implementation. Following is a summary of the tools available:
Figure 3 – Oracle Cloud Configuration Tools
During the implementation, you would utilize Enterprise Structures Configurator (ESC) to simulate and finalize core
enterprise structures across HCM and Financials. Next, rapid implementation templates should be used to complete
configuration setup to support the implementation scope defined in Functional Setup Manager. If needed, both
Financials and HCM provide data loaders for loading large number of values for a configuration (i.e., talent data,
currency rates).
Enterprise Structures Configurator (ESC)
Oracle Cloud Applications have been designed to ensure your enterprise can be modeled to meet legal and
management objectives. This flexibility is an advantage but can seem a daunting task upon initial review. To guide
and streamline the activity, Oracle HCM Cloud Services provides the ESC.
This figure illustrates the process to configure your enterprise using the Enterprise Structures Configurator.

Figure 4 – ESC Interview Process
The ESC is an interview-based tool that guides you through the process of setting up a basic enterprise structure.
By answering questions about your enterprise, the tool creates a structure of divisions, legal entities, business units,
and reference data sets that reflect your enterprise structure.
Note: The leading implementation practice is to utilize ESC for your high level enterprise configuration modeling
activities.
The Enterprise Structures Configurator (ESC) provides the ability to roll back an enterprise configuration in certain
situations:
 Manual: You can manually roll back an enterprise configuration after loading it, for example, because you
decide you do not want to use it.
 Automatic: If an error occurs during the process of loading the configuration, then the application
automatically rolls back any enterprise structures that were created before the error was encountered.
Following are key considerations for utilizing ESC as part of your implementation:
1. ERP has more dependencies on how Business Units must be defined, so start with your Financials
requirements first before addressing your HCM requirements.

2. Do not utilize both ESC and Enterprise Structure Rapid Implementation Templates for the same
configuration values such as Legal Entities, Business Units, and reference data sets. If ESC is used to
configure Legal Entities, then tab Companies and Legal Entities within Rapid Implantation Sheets cannot
be used and manual configuration tasks must be performed. The overlap and usage of these tools should
be analyzed early-on with design considerations.
3. At this time, ESC can only be used for the initial configuration and should not be used for configuration
updates/maintenance.
4. The illustration above only shows one potential use of Divisions. Divisions are useful for a non-Legal
Entity based hierarchy. The concept of divisions in most implementations is actually a slice through Legal
Entities and not an aggregation of them.
5. The following ERP objects are not addressed by the ESC and will require utilizing the appropriate tabs in
the RapidImplementationForGeneralLedger.xlsm rapid implementation spreadsheet:
a. Chart of Accounts, Calendar, Ledger
b. Cost Centers
c. Chart of Accounts Segment Value Hierarchies
d. Document and Journal Sequences
For additional information on utilizing ESC, please refer to the section “Establishing Enterprise Structures Using the
Enterprise Structures Configurator: Explained” in the Oracle Help Center. In the following sections, we will address
Rapid Implementation Templates for Financials
Another method for enterprise configuration is to use the Define Financials Configuration for Rapid Implementation
task list in FSM to streamline your setup configuration. The rapid implementation task list minimizes the time needed
for you to complete your key setups and enable the day-to-day use of Oracle Financials Cloud. Here is an example
of some of the setups that can be done using rapid implementation template:
Figure 5 – Example of Rapid Implementation Template

Rapid implementation is a way to configure a financial enterprise and financial reporting structures quickly using
sheets in a workbook that upload lists of:
 Companies (legal entities)
 Ledgers by country
 Business units
 Chart of accounts and segment values
 Segment value hierarchies
 Financial sequences
 Required subledger accounts
Following are key considerations for utilizing Rapid Implementation Spreadsheets as part of your implementation:
 A primary Ledger is created for each unique country entered in the Companies and Legal Entities sheet.
 You cannot change the Chart of Accounts, Accounting Calendar, or Currency for your Ledgers after the
setup is created.
 You can create more than one hierarchy for any of your Chart of Account segments after the initial
enterprise structure setup
 There is no rollback capability with Rapid Implementation Templates.
For additional information on utilizing rapid implementation templates, please refer to the section “Define Financials
Configuration for Rapid Implementation: Overview” in the Oracle Help Center.
Note: You are not restricted to only use the setup configuration in the rapid implementation task list. You can
manually add the standard Financials offering task lists and tasks to your rapid implementation project to change
and update your setup.
Legal Entities
Legal Entity is a legally recognized entity that can own and trade assets and employ people in the jurisdiction that it
is registered. Legal Entities can own property, trade, repay debt, account for themselves. Each Legal Entity is
accounted for in only a single Ledger, but one Ledger can serve multiple Legal Entities.
As a first step, it is important that key stakeholders across Financials and HCM agree on the legal structure. Each
registered company (with its own tax ID) that performs financial transactions should be defined as a Legal Entity in
Oracle Cloud services.
Sequencing by Legal Entity: you can assign different document, accounting and reporting sequences to each Legal
Entity within a Ledger and / or Business Unit. Sequencing by Legal Entity is enabled at the Ledger level in the
Ledger Options page.
From a HCM perspective, there are two key considerations when creating Legal Entities:

 Will the Legal Entity hire and manage employees? If yes, then the Legal Entity must be denoted as a
Legal Employer.
 Will the Legal Entity be responsible for collecting and reporting payroll taxes on behalf of employees? If
yes, then the Legal Entity must be denoted as a Payroll Statutory Unit.
When a Legal Entity is defined as a Legal Employer, you can create employee information in HCM.
Figure 6 –Example of a Legal Entity defined as a Legal Employer and Payroll Statutory Unit
Designating a Legal Entity as a Legal Employer enables the Legal Entity to be available in HCM. In the illustration
below you will see how we are able to assign an employee to the Legal Employer we previously created.
Figure 7 –Example of a Person assigned to Legal Employer

For additional information on implementation considerations for Legal Entities please refer to the section “Define
Legal Entities” in the Oracle Help Center.
Divisions
Divisions are used in HCM to define the management organization hierarchy, using the generic organization
hierarchy. This hierarchy can be used to create organization-based security profiles. You can roll up Business Units
into HCM Divisions if (a) Business Units process transitions across multiple Legal Entities, and (b) you structure your
Chart of Accounts with a hierarchical management structure.
In Financials, Division is more of a conceptual design (ex. Line Of Business) that can be implemented as a segment
within the Chart of Accounts. For example, a Division can represent a profit center or grouping of profit and cost
centers, where the division manager is responsible for attaining business goals including profit goals.
Division is not a required field in Financials or HCM. Divisions and Legal Entities are independent concepts. In
practice, Divisions are useful for a non-legal entity based hierarchy. The concept of Divisions in most
implementations actually is a slice through Legal Entities and not an aggregation of them.
Note: Division is strictly a Cloud HCM configuration object. Utilizing HCM Division(s) will have no impact on your
Financials configuration.
For additional information on implementation considerations for divisions please refer to the section “Decisions
Explained – Workforce Deployment Planning” in the Oracle Help Center.
Ledgers
Oracle Financials cloud reflects the traditional segregation between the general ledger and associated subledgers.
Detailed transactional information is captured in the subledgers and periodically imported and posted in summary or
detail to the Ledger. A Ledger determines the currency, chart of accounts, accounting calendar, ledger processing
options, and accounting method for its associated subledgers. Each accounting setup requires a primary ledger and
optionally, one or more secondary ledgers and reporting currencies.
Following are key considerations for your shared Ledger structure:
 The number of ledgers and subledgers are unlimited and determined by your business structure and
reporting requirements. Local and corporate compliance can be achieved through an optional secondary
ledger.
 The approach on how period close activities are managed is a key consideration. If period close activities
are completely independent across accounting organizations operating within a country with different
business policies and period close cycles, then separate Ledgers may be appropriate.
 Ensure that your Legal Employer’s Payroll Expense journal can post to the corresponding Legal Entity’s
primary ledger. A specific Legal Employer’s Payroll Expense journal cannot post to multiple Ledgers.
 One per Ledger currency – generally means one Ledger per country.
For additional information on implementation considerations for Ledgers please refer to the section “Implementing
Enterprise Structures - Ledgers” in the Oracle Help Center.

Oracle’s best practice recommendation is that Ledgers should not span countries. Failing to follow this guidance
is likely to result in undesirable consequences down the line.
Business Units
A Business Unit is a unit of an enterprise that performs one or many business functions that can be rolled up in a
management hierarchy. A Business Unit can process transactions on behalf of one or many Legal Entities.
Consider the following illustration:
Figure 8 – Example of an enterprise structure
Following are key considerations for your enterprise Business Unit structure:
 The first step in defining your Business Unit structures across Financials and HCM is to review the
features associated with each type of Business Unit / business function before deciding what organization
levels Business Units will represent.

 Financials has more dependencies on how Business Units must be defined, so start with your Financials
requirements first before addressing your HCM requirements.
o SCM Profit Center Business Units must not span Legal Entities.
o Requisition Business Units will usually not span legal entities (but there is no prohibition).
o Payables Payments Business Units will normally correspond with the disbursement bank
account(s).
 The general recommendation is to define one Ledger and one Business Unit per country. This approach
will maximize the user profile default value capabilities and streamline data entry.
 If you have security requirements whereby you want to segregate areas of the business into secure silos,
OR If you have very different business and operating terms for different segments of the business and they
are run almost as separate companies, then you should consider different Business Units within the Legal
Entity.
 You can tie your list of Departments, Jobs, and Grades to the HCM Business Unit so that parts of your
enterprise have different setups.
 General Practice: When a joint pillar implementation is being designed, the Business Units are initially
defined from a Financials perspective. HCM then needs to use this baseline, although you may require
creating additional Business Units if defining a shared service operation or utilizing Positions.
 Having multiple Financials Business Units (BU) enables shared services Procurement model (with
requisitioning BUs to procurement BU), security by BU (as data roles are BU based) and Intercompany
invoicing between departments (BUs).
 Key configuration decisions for a single versus multiple ERP Business Unit structure:
o Payments processing by each BU or across BU (Cloud Financials supports cross BU
payments).
o 1 or multiple bank accounts for payment processing and supporting intercompany rules.
o Cloud ERP does not support cash receipting / lockbox across Business Units. This will require
cash receipting / lockbox processes setup at the Business Unit level.
For additional information on implementation considerations for ERP Business Units, refer to the section “Business
Units” in the whitepaper “Oracle Financials Cloud: Shared Service Centers (SSC)”.
Reference Data Sets
Oracle Cloud has a reference data sharing feature. The reference data sharing functionality supports operations in
multiple Ledgers, Business Units, and warehouses. As a result, there is a reduction in the administrative burden and
the time to implement new Business Units. For example, you can share sales methods or transaction types across
Business Units. You may also share certain other data across asset books, cost organizations, or project units.

Figure 9 – Examples of Setup Data that can Shared Using Reference Data
Oracle Cloud Applications contains a reference data set called “Enterprise” in Financials and “Common” in HCM.
Define any reference data that affects your entire enterprise in this set. For additional information, please utilize the
following link to see a list of the reference data objects that can be shared across business units (link).
Reference data is not the only option of configuration sharing available in Oracle Cloud Services. For example,
COAs can be shared across Ledgers; Locations are shared across location sets. This detailed sharing option
provides you the flexibility to further refine configuration data sharing in Oracle Cloud Services.
Leading Practice: Reference Data Sets and Business Unit values should be discussed at the same time given their
interdependencies.
Jobs and Positions
As you implement your enterprise model, one of the earliest decisions you face is whether to use Jobs, Positions, or
a combination of both. Jobs and Positions represent roles that enable you to distinguish between tasks and the
individuals who perform those tasks. A job can be defined globally in the common (i.e. Enterprise) Reference Set,
whereas a position is defined within one Business Unit. One of the earliest decisions you will make is whether to
use jobs or a combination of Jobs and Positions.
Note: At a minimum, you need to create Jobs to support your organizational structure.
As part of your discussion, it is important to note the potential impact that positions and jobs may have on
Procurement approvals. There are options for using Job Levels as an alternative to position hierarchies just for the
purpose of Financials approvals. Position hierarchies may require additional maintenance.
For additional information on Jobs and Positions implementation considerations please refer to the “Jobs and
Positions: Critical Choices section in the Oracle Help Center.

Departments and Cost Centers
A Cost Center represents the smallest segment of an organization for which you collect and report costs. A
Department is an organization with one or more operational objectives or responsibilities that exist independently of
its manager and has one or more workers assigned to it. The financial performance of Departments is generally
tracked through one or more Cost Centers. Oracle HCM Cloud assigns workers to Departments, and tracks the
headcount at the departmental level. Employee count within a Department is frequently used to perform allocations
in Oracle Financial and Oracle EPM products. HCM can also utilize person, positions, country, LDG, and Payroll to
establish data security scope for users.
Look at your reporting needs from both an HCM and Financials perspective before you define your Cost Centers
and Departments.
Best Configuration Practice: HR Department(s) logically align to Financial Cost Center(s). This approach will
minimize the configuration required to transfer Payroll expenses to General Ledger (i.e., no detailed mapping or
individual employee distributions required for payroll costing).
For additional information on Departments and Cost Center implementation considerations please refer to the
“Manage Departments – Workforce Structures” section in the Oracle Help Center.
Security and Roles
Both Oracle Financials and HCM Cloud services utilize the same simplified security model to implement user
application security via the Cloud Security Console. Users are granted access to applications with the addition of
Roles to their user and, in turn, these roles are made up of multiple duties which dictate the application access (i.e.
user navigation menu paths available). It is also important to consider whether you plan to implement a shared
services model. Most large customer will have users operating at all levels: enterprise shared services, legal entity
responsibility, regional responsibility, and line management responsibility.
The two most common areas of securing data within the two pillars are:
 Financials utilizes Business Units and their relationships to Ledgers and Legal Entities to secure
transaction processing by business functions, management reporting, and transactional data security for
companies operating shared service centers, and reference data.
 HCM utilizes Organizations and Departments to establish data security scope for users.
Both Oracle Financials and HCM provide the flexibility to define exceptions to the standard default of data security
and, in addition, have more user definable security options available for enhanced control - Data Access Sets &
Segment Value security for ERP and Position Hierarchies & Areas of Responsibilities (AoR) for HCM. The HCM
enterprise structure can also play a role in auto-provisioning rules. Following are the HCM fields that can be used
to automatically assign job roles to users based on the conditions specified.

Figure 10 – HCM fields that can be used for Auto-provisioning Job Roles
For additional information on security implementation considerations please refer to My Oracle Support Advisor
Webcast “Security Console Overview” and “Provisioning Roles to Application Users” in the Oracle Help Center.
Data Conversion
Although HCM and Financials both have strong file based loader capabilities, there are slight nuances about using
each which are important to understand and different places to get your questions answered most efficiently.
1. Data Loading
Oracle ERP Cloud utilizes two methods for loading data (transactions):
 ADF Desktop Integrator spreadsheet tool (ADFDI) – Use this MS Excel-based import feature to import
small volumes of data that typically change on a periodic basic. Currently, ADFDI spreadsheets are
available for Budgets, Currency Rates, GL Journal Entries, etc.
 File-Based Data Import (FBDI) - Use the file-based data import feature to import large volumes of data
from third-party or other Oracle applications. Data is first loaded into interface tables in Oracle ERP Cloud,
then a separate process is used to load validated data into application tables.
For a comprehensive list of Data Imports for ERP please refer to the “File-Based Data Import for Financials Cloud”
on Oracle Help.
Oracle HCM Cloud’s primary method for data conversion is utilizing HCM Data Loader (HDL). HDL supports both
co-existence and full deployment modes of HCM Cloud. A great resource for guidance is the “Data Migration and
Integration Advisor” document on My Oracle Support.
2. Data Validation
Data validation is a key activity within the data conversion process. Oracle has provided the following guidance to
assist you with validating data in the Oracle Financials and HCM Cloud services.

 You should also leverage the following My Oracle Support Document “Oracle Enterprise Resource
Planning Cloud Service: How to Verify Data Conversion Results (Doc ID 2084189.1).
 Oracle HCM also has a data file validator tool for HDL - Data File Validator Tool for HCM Data Loader
(Doc ID 2022617.1)
Note: Both Oracle HCM and Financials data loading tools do not have the ability to rollback transactional data once
it has been committed to the cloud service environment.
Integration
Both Oracle Financials and HCM Cloud Services offer the same types of integration options to 3rd
party external
systems:
1. Predefined Extracts.
2. Web Services.
There are some slight nuances that need to be addressed to ensure effective planning is performed. From a
technology perspective the majority of Oracle HCM web services are based on the REST service architecture while
Financials web services are based on SOAP and REST service architecture. The web services and data
requirements may be different however the end results are the same.
Best Practice: If you are implementing more than 10 interfaces then it is advised that you purchase a dedicated
GSI instance for interface development so you can minimize potential conflict with functional user activities such as
configuration and testing.
For additional information on HCM integration options refer to the “Integrating with HCM Cloud” document in Oracle
Help Center.
For additional information on Financials integration options please refer to the “Cloud ERP Integrations” document in
My Oracle Support.
Key Interfaces– Global Payroll
As a best practice, you should set up accounts in payroll for the equivalent account combinations maintained in
General Ledger. By using a similar structure, you avoid discrepancies, minimize maintenance, and improve
communication between departments when resolving questions about journal entries. For example, specify the
same natural account segment for the payroll cash account as used in General Ledger, so that you can reconcile
the cash account and bank balance for transactions that share the same bank account.
Additional evidence for our recommendation of one Ledger per Country has to do with Global Payroll. One Ledger
per Country simplifies Global Payroll as only once cost allocation flexfield is definable per Ledger. As such, if
multiple Ledgers are used within one Country, careful thought must be given to the structure of the flexfield (CKFF)
and the shared values from any Chart of Accounts structures and List of Values from multiple Ledgers.

Oracle Global Payroll integrates with Oracle Cash Management and Oracle General Ledger. This integration
facilitates the setup of banks, branches, and bank accounts, and the reconciliation of bank statements with payment
transactions.
For additional information on the Global Payroll integration please refer to the “Distribute Payroll Accounting
Information” section in the Oracle Help Center.
Key Interfaces– Planning and Budgeting
Single Sign On (SSO) and role-based security are controlled by Oracle Identity Management, which defines a
security domain for each service instance. After a successful login, access to the service is determined by the role
assigned to the user. An identity domain controls the accounts of users who need access to service instances. It
also controls the features that authorized users can access. A service instance belongs to an identity domain. Users
are shared between the instances; however, access privileges are granted to users separately for each instance
belonging to an identity domain.
You can integrate Oracle General Ledger Cloud data with the Oracle Enterprise Performance Management Cloud if
you use Fusion Cloud Release 11 or higher. This integration enables you to simply pick the desired source ledger
from General Ledger Cloud, set up mappings and then initiate the process to pull the data into the EPM Cloud
applications. This integration can be run manually, or scheduled for a specific time.
For additional information on the EPM Cloud integration with General Ledger Cloud, refer to the “Integrating the
General Ledger with the EPM Cloud” section in the Oracle Help Center.
Workflow Approval
HCM and Financials have each provided some specialized extensions to the common approval management
features. It is important to understand both and optimize the maintenance procedures for the customer. Consider
the illustration below:

Figure 11 – How Financials Approval Services leverage HCM Person and Assignment Information
Both Financials and HCM utilize Oracle Cloud Approvals Management (AMX) for workflow approval management.
AMX utilizes the following list builders to build your approval list.
List Builder Functionality
Human Resources
(HR) Supervisory
The HR Supervisory hierarchy levels are selected. The number of levels available for approval is specified.
Job Level A relative dollar amount is attached to a job. The approval list moves up the HR Supervisory hierarchy to the
point where approval finds a job with the necessary approval amount.
Position A relative dollar amount is attached to a position.
Approval Group Approver groups represent functional or subject matter experts outside the transaction’s managerial chain of
authority, such as Legal or Human Resource personnel. These groups are static.
Note: Financials workflow has an inherent dependency on HCM employee information and HCM organization
structure. Best practice is to ensure that the Oracle HCM Cloud organization structure can support the required
Financials workflow approval lists.
For additional information on Oracle’s Cloud Approval Management, refer to the “Define Approval Management”
section in the Oracle Help Center.

Deployment Considerations – HCM and Financials Concurrent (Big Bang)
In addition to the guidance provided above please consider the following as part of your deployment strategy:
 Resize Stage/Test environment before User Acceptance Testing (UAT).
Consider your UAT activities as a “Dress Rehearsal” for the go-live event. There will be user activity from both
a Financials and HCM perspective. Even though there are subtle infrastructure differences between
Stage/Test and Production environments, resizing your Stage/Test environment will ensure that any potential
for disruption of user activities are minimized.
 Test across product services – business processes cover multiple products and pillars.
There can be a tendency to address a business process by functional areas (HR, Payroll, Benefits, General
Ledger, and Cash Management). This is typically a division of labor to support parallel work streams/activities
and accelerate implementations. However, care must be taken to ensure that work steams/activities refocus on
business processes that may be supported across multiple modules. Example: Configuring and validating the
Payroll process should include booking the payroll expense to the General Ledger.
 Tight coordination across the implementation projects.
Majority of our customers implementing HCM and Financials concurrently have separate implementation
projects for each product family. This approach enables several implementation activities to be performed in
parallel and effective project resource allocation. However, this promotes an increased risk in configuration and
requirements conflicts between the product families. We recommend that a cross-functional team across HCM
and Financials meet on a weekly basis to discuss key configuration decisions and coordination of joint activities
(e.g., testing, instance management, security).
Note: Bank information to pay employees from Oracle Payroll and the bank information to pay employees from
Oracle Expenses Cloud, needs to be managed separately. In Oracle Expenses, the employee has to enter their
bank information.
Deployment Considerations – HCM First then Financials (Phased)
In addition to the guidance provided above the following must be addressed as part of the solution configuration:
 In order for HCM to be configured there are fundamental structures that are required in Financials as part
of the implementation:
o Chart of Accounts
o Accounting Calendar
o Ledger
o Legal Entity
Currently, the integration between the Financials structures created by HCM Cloud’s ESC and Financials
Cloud’s Rapid Implementation templates are not completely integrated, and it is unreasonable to assume

that HCM Implementation Consultants can design the Chart of Accounts and Ledgers before the HCM
project starts, which can take months requiring effort from the finance team.
Note: In this example, we will assume that the initial HCM implementation is NOT including Subledger Accounting or
General Ledger to support Payroll Accounting.
In the interim, Oracle suggests that HCM Implementation Consultants create the bare minimum setup for
Financials or a ‘dummy” setup and then later correct and complete the Financials enterprise structures
when they are ready to implement Financials Cloud.
 Define your Calendar with a starting date early enough to bring over your historical GL Balances
when you implement Financials.
 Define the Chart Of accounts structure with the minimum required segments and values.
 Define a Retained Earnings account.
 Manually define a Primary Ledger using the required Retained Earnings account you defined in
the previous step.
 Do NOT create any Secondary Ledgers or Reporting Currencies.
 Do NOT open any GL Periods.
 Do NOT complete your accounting configuration.
 Do NOT create and Financials transactions.
 Do NOT create any Account Code Combinations.
In the future, when the customer is ready to implement Financials Cloud, the following activities should be
performed to safely modify the Chart of Accounts definition:
 Make the changes to the Chart Of Accounts definition. For example, when you created your
COA when implementing HCM Cloud, you may have only defined three segments: Balancing
segment, Cost Center, and Account. However, after meeting with the finance team, they have
decided on a seven segment chart of accounts.
 Create a new account code combination for Retained Earning and reassign it to the Ledger
definition.
 Disable the original Retained Earnings Combination (it is now corrupt).
 Run the ESS job to rebuild the Essbase cube.
Note: The above changes should be done in Test/Stage first and everything tested, validated and reviewed on both
HCM and Financials before attempting to do it in Production.
 Financials must have at least one Business Unit assigned to a primary ledger, and a default Legal Entity.
Financials also utilizes Business Units to establish data security, and business functions, such as
procurement, invoicing and payment options, expense report templates and reporting options (filtering,
grouping).

 Conversely, implementing Payroll as a part of the HCM implementation will require a discussion on key
enterprise financial structures (Legal Entity, Ledger, Chart of Accounts, and Cost Centers). Currently ESC
does not cover Ledger and Chart of Accounts setup so plan to manually configure these items.
 Rationalize Location and Geography values to facilitate multiple uses. When creating Locations, consider
the various physical locations that can be represented:
o Workforce structure (i.e. work location)
o Fixed Assets
o Legal Entity
o Inventory organization
o 3rd
Party entities (employment agencies, tax authorities)
Note: Some Oracle Cloud Human Capital Management implementations do not require recording of accounting
transactions and therefore, do not require implementation of a Ledger. Be careful not to overlook Ledger and
financial reporting requirements.
Deployment Considerations – Financials First then HCM (Phased)
Along the same lines of thinking, having a minimalist HCM configuration approach can have limiting impacts further
in the implementation.
 If Supervisory Hierarchy is used for Approval Management, make sure every employee has at least one
supervisor assigned. The same is true for Job level. Make sure you have a hierarchy of Job levels.
 Complete a resizing request after the Financials phase deployment but before HCM deployment (after
UAT is completed). Especially if the HCM deployment includes modules that will generate a larger amount
of transactions (e.g., Time and Labor, Payroll).
 If you are implementing Financials first, it may be tempting to define a single HCM Business Unit simply as
a placeholder to define departments, Job structures for tracking employees. Adding additional Business
Units after the fact when you bring HCM on board will require additional effort, so start with your complete
list of Business Units for Financials and HCM.
Note: It is extremely important to have a complete and agreed upon definition on Legal Entities and Legal
Employers. If employee information is loaded to a temporary/placeholder Legal Employer the remedy will
include terminating all employees from the temporary/placeholder Legal Employer and reassigning them to the
correct Legal Employer.

Conclusion
Oracle Financials and HCM Cloud services provide you the flexibility to deploy these services in a parallel or phased
fashion. Integration is a key enabler for both Financials and HCM implementations. Oracle provides tight
integration across Financial and HCM business processes that minimizes setup and maximizes information flow.
This tight integration requires a greater understanding of key dependencies and decision across the entire business
process. The first step in implementing a multi-pillar solution is to design and configure the enterprise structure.

Appendix – Summary of Financials/HCM Configuration Best Practices
Following is a summary of the key configuration components and recommendations for an Oracle Financials Cloud
and HCM Cloud multi-pillar implementation.
FINANCIALS/HCM MULTI-PILLAR CONFIGURATION CONSIDERATIONS
Component Best Practice Configuration Explanation
Ledger, Business Unit Ledger and Business Unit should not cross
multiple countries.
A Ledger is defined to a single currency. Ledger and Chart of
Accounts association derived from employee’s assignment
Business Unit.
Reference Data Define one central reference data set for
key configurations that can be shared
across all business units
The reference data sharing functionality supports operations in
multiple ledgers, business units, and warehouses. As a result,
there is a reduction in the administrative burden and the time to
implement new business units.
Chart of Accounts Common global chart of accounts for all
legal entities.
Easier consolidation of legal entities financial accounting and
financial reporting. Straight forward transfer of Payroll journal
entries into General Ledger.
Divisions Utilize Divisions in HCM to represent if you
have the concept of a division level within
your organization today.
Division is a HCM-only concept and Division(s) are not required
for Financials.
Ledgers Best configuration practice is to have one
Ledger and one Business Unit per country.
Oracle offers three methods for consolidations: (1) Reporting Only
Consolidations, (2) Balance Transfer Consolidations, or (3)
Financial Management Consolidations using Oracle Hyperion
Financial Management.
Legal Entities Each registered company (with its own tax
ID) should be defined as a legal entity in
Oracle Financials Cloud.
Each Legal Entity is accounted for in only one Ledger, but one
Ledger can serve multiple Legal Entities.
Legal Entities & Legal
Employer
A Legal Employer must be a Legal Entity
but not every Legal Entity must be a Legal
Employer.
The Legal Employer is captured at the Work Relationship level,
and all employment terms and assignments within that
relationship are automatically with that Legal Employer. Legal
Employer information for worker assignments is also used for
reporting purposes.
Legislative Data
Group
A single Legislative Date Group (LDG) for
each country.
Create at least one Legal Entity
designated as a Payroll Statutory Unit
(PSU) for each LDG.
Each Legislative Data Group is associated with one or more
Payroll Statutory Units.
Legal Employer &
Payroll Statutory Units
The Legal Employer and Payroll Statutory
Units are the same.
When you set up Legal Entities, you can identify them as Legal
Employers and Payroll Statutory Units, which makes them
available for use in Oracle Cloud Human Capital Management
(HCM). A tax reporting unit is created automatically when you add
a Legal Entity and identify it as a Payroll Statutory Unit. Payroll
Statutory Units are Legal Entities that are responsible for paying
workers, including the payment of payroll tax and social
insurance. A Payroll Statutory Unit can pay and report on payroll
tax and social insurance on behalf of one or many legal entities.

Component Best Practice Configuration Explanation
Cost Centers and
Departments
HR Department logically align to a
FINANCIALS cost center(s)
Better leverage of defaulting values (i.e., Departments) from Job
and/or Position data. Simplifies accounting mapping for Payroll to
General Ledger interface.
Please note that technically HR Departments do not need to
logically align to Financials cost centers, however, this will require
additional effort during personnel changes and increased
configuration for the Payroll to GL mapping.
Job Codes A relative dollar amount is attached to a
job. The approval list moves up the HR
Supervisory hierarchy to the point where
approval finds a job with the necessary
approval amount.
Leveraged for General Ledger journals and Payables voucher
approvals.
Supervisory Level
Approvals
If Supervisory Hierarchy is used, make
sure every employee has at least one
supervisor assigned. The same is true for
Job level. Make sure you have a hierarchy
of job levels.
Ensures that approval workflow works if using the Supervisory
Hierarchy.
User Users should first be created as
employees.
Pre-requisite: Application security requires a legal employer,
business unit, and a work relationship for security assignment.
Locations and
Geographies
Rationalize location values to facilitate
multiple uses.
Location is shared data element for FINANCIALS and HCM.
Having a common set of values will reduce maintenance.

Oracle Corporation, World Headquarters Worldwide Inquiries
500 Oracle Parkway Phone: +1.650.506.7000
Redwood Shores, CA 94065, USA Fax: +1.650.506.7200
Copyright © 2017, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only, and the
contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other
warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or
fitness for a particular purpose. We specifically disclaim any liability with respect to this document, and no contractual obligations are
formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any
means, electronic or mechanical, for any purpose, without our prior written permission.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and
are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are
trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group. 0917
Multiple Pillar Oracle Cloud Implementation Best Practices
September 2017
Author: Brett Beaubouef
Contributing Authors: Becky Alvarez , James Arthurton, Vish Gaitonde, David Haimes, Theresa Hickman, Eamon Kearney, Neil
Ramsay, Ena Singh
C O N N E C T W I T H U S
blogs.oracle.com/oracle
facebook.com/oracle
twitter.com/oracle
oracle.com

Oracle cloud-multi-pillar-implementation-best-practices-wp

More Related Content

What's hot

Similar to Oracle cloud-multi-pillar-implementation-best-practices-wp

Recently uploaded

Oracle cloud-multi-pillar-implementation-best-practices-wp