chart of accounts maintenance using data relationship
TRANSCRIPT
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