Session ID:

Prepared by:

Chart of Accounts Maintenance

using Data Relationship

Management and a Custom

Approval Workflow

10566

Prith Barman

Senior Project Manager

McDonald’s Corporation

Chandan Bedi

Enterprise Architect

McDonald’s Corporation

Introduction

2

• Speaker

• Company

• Department

• Standard reports will be created and leveraged across markets

• Consistent Global Configurations

• Reduces Customizations

• Minimizes Testing Cycles

• Standardize Processes

• Reduces Manual workarounds

• Decreases Maintenance of Report Writing

• Supports Multi-GAAP & IFRS

• Increases Audit-ability & Data Integrity

• Improves Controls

• Simplifies accessibility to data across Countries

Improves Accuracy &

Visibility

Drives Efficiencies

Consistent Reporting

Faster Deployment

Need for Global Chart Of Accounts

3

Benefits of Chart Governance

Enhance auditability for Chart of Account changes across all Business

Groups

Achieve efficiency by leveraging technology to automate approval and

notification process

Increase speed to meet immediate period close needs.

Ensure all boundary applications are in synch with the approved Chart

of Accounts

4

Design Considerations for Chart

Governance

Master Data System to store Segment

values, Hierarchies and Business Rules

Design

Requirements

Oracle Data Relationship Management

(DRM)Technology

Technology was already used by Hyperion to

master hierarchies information

McDonald’s

Rationale

5

Design Considerations for Chart

Governance (Cont.)

Workflow requirements for Approval routingDesign

Requirements

Oracle Service Oriented Architecture (SOA)Technology

A workflow solution to manage & govern the

process. Details to follow in upcoming slides

McDonald’s

Rationale

6

Design Considerations for Chart

Governance (Cont.)

User Interface to request segment values,

hierarchies and code combinations and

provide approvals

Design

Requirements

Oracle Applications Development Framework

(ADF)Technology

Rich user interface to request/update the

information. Technology already used by

other applications

McDonald’s

Rationale

7

Design Considerations for Chart

Governance (Cont.)

Integration with any other system using this

information, like OBIEE and Oracle E-

Business Suite

Design

Requirements

Oracle Data Integrator (ODI)Technology

Usage of Change data capture feature & bulk

upload. Technology already in use by other

applications

McDonald’s

Rationale

8

Design Considerations for Chart

Governance (Cont.)

System to store Legacy to Oracle Code

Combination Mapping

Design

Requirements

Oracle E-Business Suite (EBS)Technology

Global chart to legacy account mapping

already existed in EBS

McDonald’s

Rationale

9

Design Considerations for Chart

Governance - Summary

Design Requirements Technology McDonald’s Rationale

Master Data System to store Segment

values, Hierarchies and Business

Rules

Oracle DRM Technology was already

used by Hyperion to master

hierarchies information

User Interface to request segment

values, hierarchies and code

combinations and provide approvals

Oracle ADF Rich user interface to

request/update the

information. Technology

already used by other

applications

Workflow requirements for Approval

routing

Oracle SOA A workflow solution to

manage & govern the

process

Integration with any other system

using this information, like OBIEE and

Oracle E-Business Suite

Oracle Data

Integrator

Usage of Change data

capture feature & bulk

upload. Technology already

in use by other applications

System to store Legacy to Oracle

Code Combination Mapping

Oracle EBS Global chart to legacy

account mapping already

existed in EBS

10

Oracle DRG Consideration

Product /

Vendor

Pros Cons

Oracle

BPEL /

Middleware

• Current version of DRM

includes enhanced WDK

(Workflow Development Kit) for

BPEL 11g

• Most commonly used for

custom workflows with DRM

• Extension of existing Oracle

platform

• Custom UI required.

• Uncertainty around product

roadmap for DRM WDKs as

Oracle’s focus shifts to the new

DRG product.

Oracle

Hyperion

DRG

• Existing vendor – DRG is an

extension of the DRM

application

• Includes capabilities for forms,

workflow, and DRM integration

• No custom coding

• Organization skillset already

being developed for DRM

application

• Risk associated with brand new

product

• Requirement for CCID workflow

approval will not be supported by

DRG workflow on the DRM dataset

• Lack of customization will require

fit/gap analysis against detailed

requirements.

• Potential incremental licensing

and/or infrastructure costs

Buy DRG vs Custom Build Consideration

11

Market and Shared Service Level Groups

Market Ledger Owner (MLO)

SSC Close Analyst

Central Governance Group / General Request Approvers

Chart of Accounts Delivery Team (COA

DT)

Corporate Controller Group (CCG)

Groups Involved

12

Person in the Country

responsible for COA

changes

Market and Shared Service Level Groups

Market Ledger Owner (MLO)

SSC Close Analyst

Central Governance Group / General Request Approvers

Chart of Accounts Delivery Team (COA

DT)

Corporate Controller Group (CCG)

Groups Involved

13

Person in the Shared

Services who is

responsible for Ledger

close

Market and Shared Service Level Groups

Market Ledger Owner (MLO)

SSC Close Analyst

Central Governance Group / General Request Approvers

Chart of Accounts Delivery Team (COA

DT)

Corporate Controller Group (CCG)

Groups Involved

14

Person responsible for

reviewing and approving

COA change requests

prior to CCG’s approval

Market and Shared Service Level Groups

Market Ledger Owner (MLO)

SSC Close Analyst

Central Governance Group / General Request Approvers

Chart of Accounts Delivery Team (COA

DT)

Corporate Controller Group (CCG)

Groups Involved

15

Person who is final

approver for all segment

values and Business

rules

Market and Shared Service Level Groups

Market Ledger Owner (MLO)

SSC Close Analyst

Central Governance Group / General Request Approvers

Chart of Accounts Delivery Team (COA

DT)

Corporate Controller Group (CCG)

Groups Involved

16

Groups Involved (Cont.)

Domain Market Ledger

Owner

SSC Close

Analyst

COA

Delivery

Team

Corporate

Controller

Group

Code

Combination Accountable Responsible Consulted Informed

Segment values Informed Responsible Consulted Accountable

Business Rules Informed Responsible Consulted Accountable

Org Hierarchies Accountable Responsible Consulted Informed

17

General Request

Normal request for any Segment Value and

Business Rule changes

Process

Description

Market Ledger OwnerInitiated by

User

~ 7 Business DaysExpected

Turnaround

18

Code Combination Request

Request to update Code CombinationsProcess

Description

Market Ledger Owner or COA Delivery Team

or SSC Close Analyst

Initiated by

User

~ < 1 HourExpected

Turnaround

19

Immediate Need Request

Urgent requests to modify code combinations

and limited updates to segments

Process

Description

SSC Close AnalystInitiated by

User

~ < 1 HourExpected

Turnaround

20

Hierarchy Updates Request

Requests to update the organizational

hierarchy for location entities

Process

Description

Market Ledger Owner or COA Delivery TeamInitiated by

User

~ < 3HourExpected

Turnaround

21

COA Solution Diagram

22

COA Solution Diagram

1

1

1

User request for new or

changes to existing

segment values, code

combinations & Hierarchies

23

COA Solution Diagram

2 3

2

2

24

User enters the

updates in the ADF

forms

COA Solution Diagram

4

ADF Web Forms

trigger Oracle BPEL

based approval

process.

25

COA Solution Diagram

5

Approval Cycle occurs

for the types of

requests that need

one.

26

COA Solution Diagram

6

Data is updated into

DRM post Approval.

27

COA Solution Diagram

7

Mapping team is

notified to make

segment mapping

updates as required.

28

COA Solution Diagram

8

Segments and/or code

combinations are

staged from DRM to

custom staging area

on the ODI server.

29

COA Solution Diagram

9

Segments and/or code

combinations are

staged from ODI to

Oracle Open Interface.

30

COA Solution Diagram

1 2 3 4

1 2

1 2

5

6

7

8

9

31

COA Solution Technical ArchitectureLandscape of DRM MDM Project

Ora

cle

DR

MO

racl

e EB

SO

racl

e SO

AU

IB

usi

nes

s U

sers

Phase

General Request

Stag

ing

tab

Stag

ing

tab

fo

r d

elta

&

CC

ODI job

Stag

ing

tab

-Im

md

iate

nee

dC

C+S

eg

Oracle EBS

ODI job

Login page Request Page Details page Submit Page

SelectUIWorkflowSelectionProcessABCS

GR

NotifyUserGroupsProcessABCS

DRM webservices

RequestDRMAddUpdateNodeProcessABCSImpl

1.General Request2.Global-Sub-Local

Marketing ManagerMarketing Manager

notification

COA GroupCOA Group CCG GroupCCG Group

Approve/reject

Request Approved1.Add Segments

2.Update Segments 3.Move Segments

DRM Applicationdelta

CC Request Immediate Need

DR

MEr

rorH

and

lingA

BC

S

Login pageResp/Req

PageSubmit

Page

CC

SyncODICodeCombinationsProcessABCS

1.Code Comb2.Imm Need ->Direct ODI call

Reject

Login pageResp/Req

Page

Submit Page

Imm Need

Cu

stom

Ap

p

Datab

ase

ADF Error Handing

PLSQL Proc to move data

32

Technical Data Flow – DRM to EBS

Step Source Target Capabilities Utilized

1 ADF Screens ODI DRM Landing Tables

For immediate need functionality for Code Combinations:• SOA directly writes to a database table.• SOA calls an ODI execution using web services.

2 ODI DRMLanding Tables

ODI DRM Staging Tables

For all functionality:• ODI moves data from the DRM landing tables to the DRM

staging tables, within the same schema.• This process occurs on a single server.

3 ODI DRMStaging Tables

Oracle EBS Staging Tables

For all functionality:• ODI moves data from the DRM staging tables to the Oracle EBS

staging tables, across two servers.

4 Oracle EBS Staging Tables

Oracle EBS For all functionality:• ODI calls a .bat script on the Oracle EBS server, invoking

concurrent jobs.

33

General Request

34

General Request

35

General Request: Segments

36

General Request: Hierarchies

37

General Request: Hierarchies

38

General Request: Hierarchies

39

General Request: Code Combinations

40

General Request: Code Combinations

41

General Request: Code Combinations

42

General Request: Code Combinations

43

General Request: Code Combinations

44

General Request: Code Combinations

45

Immediate Request

46

Immediate Request

47

Immediate Request

48

Immediate Request: Code Combinations

49

Immediate Request: Code Combinations

50

Immediate Request: Code Combinations

51

Immediate Request: Code Combinations

52

DRM Sample Screen

53

Securing the COA Application

54

• Application Access:

SSO through OAM Integration.

No local WebLogic user provisioning.

• Application Security:

Delivered through ADF Enterprise Roles.

Design of roles to give access to certain application windows per

role

• Data Level Security:

Ledger mapping to ADF Enterprise Roles in local table.

Lessons Learnt

55

• Validate you are licensed properly to use all your technology tools:

Unlimited user of WebLogic License

Oracle SOA Suite License.

ODI License

You will have WLS install in Hyperion/DRM but you can’t use it

for custom code.

Confirm with Oracle your usage of DRM SDK Web services.

Be wary of the “Limited use License” that comes with Oracle

products.

• The DRM product can run multiple “instances”, i.e. a DEV and TEST

version on the same install. ADF and SOA needs separate application

servers installed to be able to do this.

• Use ODI “Change Data Capture” (CDC) feature and do incremental

loads instead of full table truncate. This will reduce application down

time.

• Add a Code Combination bulk load feature.

• Start small with valid Code Combination rules and then building on

them.

Questions?

56