Sie sind auf Seite 1von 32

Adapting Oracle Purchasing Approval

Workflow Processes for Compliance in a


Global and Decentralized Environment
Your Environment

• Location: One, Multiple US or Global?


• Purchasing: Centralized or Decentralized?
• Process: Requisitions? Purchase Orders?
• Matching: 2-way or 3-way?
• Application: Extensions or Vanilla installation?
• Compliance: Internal/external audit? Federal?
Sponsorship?
• Approvals: Manual, Oracle standard hierarchies or x?
CMU Environment
CMU Financials Computing Environment

• 1999 – Oracle Financials 11.0.3 implemented


• 2004 – Upgrade to 11i (11.5.10)
• 2007 – Multi-Org / Multi-Currency (Globalization)
• 2008 – ATG 6 security patch upgrade
• 2009 – Planned DB upgrade to 11g
• 2010 – Possible upgrade to Rel 12, Workflow conversion
to BPEL …
Presentation Overview

• Describe the drivers for our Multi-Org / Multi-Currency


(Globalization) project in purchasing, namely:
– Global Decentralized Purchasing and Approvals
– Compliance and Custom Centralized Approvals
– Multi-Currencies
• We will conclude with a list of technical solutions and if time
permits, drill down on a topic of interest to this group.
Challenge #1:
Global Decentralized Purchasing and Approvals

• Definition
– Global Decentralized Requisitioners, Buyers, and Data Entry
– Global Supervisory Hierarchies
• Challenge Description
– Global Data Entry and Validation
– 14 Fluctuating Currencies => Maintain Validation/Approval Limits
– One operating unit and set of books for each country
– Limited Supervisors with Approval Rights in some Sets of Books
– Standard Hierarchy uses Set of Books and $ Limits
– Validations on Multicurrency for Form Fields (Bid Checklist etc.)
– Set of books functional currencies of AUD and USD
Challenge #1:
Global Decentralized Purchasing: Set of Books

GBL
Cur: USD

Cm Global Consolidation
GL Balances Only
INTL
USA Cur: USD
Cur: USD
CM Intl Consolidation
Carnegie Mellon GL Balances Only
GL, AR, AP, PO, GM, LD, IE
QAR AUS
Cur: USD Cur: AUD

CM Qatar CM Australia
GL, AR, AP, PO, LD, IE GL, AR, AP, PO, LD, IE
Challenge #1:
Global Decentralized Purchasing and Approvals

• Limitation of Oracle ‘Seeded”


– Multiple Currencies
– Approvers in Different Time Zones
– Buyer Job and Approval Group Limits could push approval
notification directly to System Override (Top of Hierarchy)
– Compliance requires some Centralized Approvals
• Manual Forward To
– Validations on Multicurrency for Form Fields (Bid Checklist etc.)
Challenge #1:
Global Decentralized Purchasing and Approvals

• Extension to Resolve issue


– Currency Conversion - Use Inload Daily rates process to pull
conversion rate into workflow. Convert all PO’s to USD. Define
approval limits in USD.
– Required Bid Checklist Descriptive Flex Field (DFF).
– CUSTOM.pll programming validates user entered value for Bid
Checklist Use Inload Daily rates process to pull conversion rate into
workflow. Convert all PO’s to USD. Define approval limits in USD.
– Compliance and Custom Centralized Approvals
Challenge #2:
Compliance and Custom Centralized Approvals

• Definition
– Maintain Compliance with the approved purchasing system
• Challenge Description
– Show due diligence and the use of procedures for audit purposes
• Federal organizations (DCAA, ONR, IRS)
• External Audit Organizations (PWC)
• Internal Audit (University Audit Services)
– Automate Buyers Matrix
• Compliance rules dictate that approvers outside of standard hierarchy
review certain types of purchases.
• Buyer Actions Matrix
Challenge #2:
Compliance and Custom Centralized Approvals
Challenge #2:
Compliance and Custom Centralized Approvals

• Limitation of Oracle ‘Seeded”


– Seeded Hierarchy limited to account string and $ limits. Buyers had
to forward PO’s to compliance individuals. If not forwarded, the PO’s
could not find an approver within an individuals hierarchy so they
ended up going to the one individual at the top of the hierarchy with
system over-ride capability.
– This person then had to route PO’s manually.
– Full time job.
Challenge #2:
Compliance and Custom Centralized Approvals

• Extension to Resolve issue


– Extended standard Oracle PO Approval Workflow to ‘front load’ CMU
checkpoint approvals to before the start of the supervisor hierarchy
approval process. Within the workflow, numerous processes,
functions, attributes and messages were created.
– Leveraged AOL and FND module (application object library)
• Checkpoints => Responsibilities
• Approval Limits, Account string includes/excludes => Value Sets,
Security Rules
– PO Approval Workflow Diagram
Challenge #2:
Compliance and Custom Centralized Approvals
Challenge #2:
Compliance and Custom Centralized Approvals

Oracle Workflow Technology


• Integral to Oracle database & E-Business Suite (11i, 12)
• Models Business Processes
• Procedure execution (PL/SQL)
• System of Notifications
• Components
– Development/Client Tools – WF Builder, loader, definition Files
– Oracle Server – BES, Directory, Notification Services, WF Engine
– Application Server – IAS, Notification Mailer
– Browser/Client – Web Notification Worklist, Mail application
Challenge #2:
Compliance and Custom Centralized Approvals

• Benefits of Fix
– Compliance
– Automated routing of PO’s (was a full time job)
– Flexibility as functional resources are able to maintain approval
structure and implement business routing rules for approval within
the application structure.
– Maintenance minimal as we limited ‘hard coding’ by leveraging AOL
Challenge #3:
Multi-Currencies

• Definition
– One operating unit and set of books for each country
– Functional Currencies of AUD and USD
– Multi-Currencies
• Challenge Description
– Fluctuating Currencies => Maintain Approval Limits
– 3 SOB with 14 Currencies into One Global PO Approval Workflow
• Limitation of Oracle ‘Seeded”
– Details on How Seeded Process Works
Challenge #3:
Multi-Currencies

• Extension to Resolve issue


– Leveraged In-load Daily rates from (OANDA http://www.oanda.com)
to pull conversion rate into workflow.
– Define approval limits in USD
– Translate foreign currency amounts to USD for comparison
• Benefits of Fix
– Eliminates need to revalue approval limitation with USD to XXX
currency fluctuation.
List of Technical Solutions

• DFF & Code Package for Bid Checklist Validation


• Extended Seeded PO Approval Workflow
– “Abstracted” workflow
– Workflow builder diagram
– CMU business rules engine package
– Inload Daily Rates Process
• Multicurrency Conversion Prior to PO Approval Workflow
– 3 SOB with 14 Currencies into One Global PO Approval Workflow
Drill Down on Topic of Interest

• Extended Seeded PO Approval Workflow


– Extended standard Oracle PO Approval Workflow to ‘front load’ CMU
checkpoint approvals to before the start of the supervisor hierarchy
approval process. Within the workflow, numerous processes,
functions, attributes and messages were created.

• Gambling anyone?
Extended Seeded PO Approval Workflow

• “Abstracted” Workflow
Start
Customization/Approval Checkpoints
Supervisory Approval Groups
End
CMU PO Approval Workflow
CMU PO Approval Workflow
PO Approval Top Level CMU extension -- Workflow Builder Diagram

Top Level CMU Compliance


Approval
StandardPO
Blanket
Contract
Planned PO
PO Yes Yes
CMU Get Document CMU Bid Check CMU Entity Check CMU Functional CMU Top Level
Type Currency Check Checkpoint Approval

CMU Set Approval


Message
No No

Final Appoval
Reject Seeded Supervisor
CMU Set Instance
URL
Wait Approval Not Needed
Approve

Hierarchy Approval
Set PO Status to
Pre-Approved No
Timeout
Yes Activity Performed
CMU Set Action
History
Activity Performed
Yes No Yes Yes Valid Action Yes Activity Performed Activity Performed Activity Performed
Can Owner Verify Approval Is Forward To Reserve Before Retroactive Update Approve PO Get Preparer PO Approved Launch Processes to Raise Change Event Send Supp Raise Send PO Print Document Fax Document Email PO Noop And End (Approved)
CMU Set Line Approve? Authority provided? Approve Invoiced Notification Attribute Notify Temp Labor 2 Communication for Event Process Process
Details Equal <Default> Releases/ Std POs. Requesters Retroactively
Passed Verification No changed releases <Any>

Update PO Action Invalid Action


History (Reject) Forward No No
No No Yes Yes
Compare Number Yes No
Get Preparer Does PO Need Block ASLs, Mass Or
Start Verify PO Notification Attribute Signature? update Release
No
No Yes
End (Invalid Action)
CMU Doc Failed Activity Performed
Correctness Check Invalid Action No Yes Yes
Find Approver Is PO Pre-Approved? Approve And End (Invalid Action) Does User want to Mass Update
Failed Verification Forward PO Mass Update Releases/ Std POs.
Releases?
No
Approve And Forward

Forward Valid Action PO Rejected


No Yes Timeout Approve
Does User want SR Noop And
<Any> and ASLs created
No
End (Invalid Action) Reject The PO Yes

No
No Yes Valid Action Reject Valid Action Activity Performed Wants to Consume Noop
Return PO to Is Forward-To User Forward PO Notify Approver Reject PO Get Preparer PO Rejected Raise Change Event End (Rejected) When Req Demand
Submitter Name Valid? Notification Attribute 3 background_flag=Y,
Wait for Background Yes <Default>
Invalid Action Process
Activity Performed Invalid Action

Create SR and ASL Consume Req


End (Invalid Action) Demand
End (No Approver End (Invalid Action)
Available)
CMU PO Approval Workflow
PO Approval CMU Checkpoints -- Workflow Builder Diagram
CMU PO Approval Workflow

Typical Custom Checkpoint (Benefits)


CMU PO Approval Workflow
• Currency Conversion

– Extended Workflow with ‘CMU Functional Currency Check”


Function
– Use converted amount to evaluate for approval limits
– Maintain approval limits in one currency
– Leveraged seeded packaged procedures to convert
• po_notifications_sv3.get_doc_total
• gl_currency_api.convert_closest_amount
CMU PO Approval Workflow
• Create Checkpoints by leveraging Oracle Roles
(responsibilities), Value Sets and Security rules.
• A little unorthodox, but it works …

– Workflow allows approval notifications to be sent to all members of a


Responsibility (Expand Roles). Create a responsibility for each
checkpoint, assign the members. “First Response Wins”
– Application Setups - Create value set security rules and define sets
of elements / ranges of values for things like Amount and each GL or
GM account segment.
• Security rules are assigned to a responsibility - approvers multiple roles
ok
• Workflow functions reference these rules in routing CMU custom
approvals
CMU PO Approval Workflow
– Using built in functionality means our data is stored in apps tables –
do not have to build this structure from scratch or hard code it
• Define high and low $ amount approval ranges
• Define general ledger account code segment ranges that fall into each
checkpoint’s bucket.
• Write custom PL/SQL code to bump against these tables
• Functional users can change values via the application. Technical help
not needed for specific values; not hard coded
CMU PO Approval Workflow

Create value set security rules


PATH: System Administrator =>
Security => Responsibility
Value Set => Define
CMU PO Approval Workflow

Assign Security Rules to


Responsibility Role
… and then assign role to
approver
Contact Information

• Jamie Christner
– Carnegie Mellon University
– Manager, Financial Systems
– jc5v@andrew.cmu.edu

• Carol Rigdon
– Carnegie Mellon University
– Principal Software Engineer, Administrative Computing and Financial
Systems
– Carol.rigdon@cmu.edu
Questions ???

Das könnte Ihnen auch gefallen