Commitment Control. Making It Work for Your Institution

Commitment Control Making It Work for Your Institution

About SpearMC and Your Presenter

Your Presenter Bullet Points Jessica Mann SpearMC Practice Director jessica.mann@spearmc.com 2014 HEUG Midwest Regional

About SpearMC Founded in 2004, SpearMC is a technology and professional services firm specializing in PeopleSoft FSCM, HCM, ESA PeopleTools Development and System Administration PeopleSoft Test Framework Oracle Cloud ERP and HCM Oracle Business Intelligence PeopleSoft Training Project Management Oracle Public Cloud QA & Test Automation Host Analytics EPM

Our History

Agenda 1. Commitment Control Overview 2. FHCRC 9.0 KK Set Up and Business Process 3. Preparing for 9.2: Process Improvement Review 4. FHCRC 9.2 Future State Design 5. Exception/Error Reporting Improvements 6. Conversion Process 7. Challenges/Lessons Learned

Home of Fred Hutchinson Cancer Research Center and yes, we do get sun sometimes. Welcome to Seattle! Home of Fred Hutchinson Cancer Research Center and yes, we do get sun sometimes.

PeopleSoft 9.2 Almost!! Upgrade go-live: 3/21/16 First Implemented 8.4: 2003 GL Assets AP/PO Contracts, Grants, PC AR/BI HRMS (9.0 Upgrading to 9.2) Custom Effort/LCD in FMS/HR

Introduction Fred Hutch Cancer Research Center has been using Commitment Control since version 8.4 As a part of their 9.0 9.2 upgrade, Fred Hutch Cancer Research Center established several overall strategic improvement goals. One of the main strategic changes was to improve Commitment Control to allow greater flexibility in controlling budgets, reduce the number of Commitment Control errors, and improve the quality of Commitment Control status and error reporting. This session will first begin with an overview of their previous 9.0 Commitment Control setup and pain points. The design improvement and 9.2 configuration and reporting solutions will then be discussed. Next the session will review the conversion process and cutover steps. Lastly, challenges and lessons learned will be shared. Our Goal Today: Review some of the pitfalls we faced in our original design, what we changed to make KK work for FHCRC and how we are implementing that change

Commitment Control Overview What s it all about?

What is it? 1. Optional feature in PeopleSoft to track/control transactions on a specified chartfield value 2. Track/Control future obligations: preencumbrance/encumbrance 3. Tie revenue to expense and incorporate revenue in spending authority 4. Control transactions based on different factors a) Start/End dates can be different than start/end date of the controlling chartfield b) Status place chartfield on Hold or Closed

What is it? b) Amount of Budget available Control don t allow overspend beyond a % tolerance Track with budget allow overspend but require that a budget be setup Track without budget allow transactions to post regardless of whether a budget is setup

What is it? 5. Highly configurable a. Can select which chartfield to control We picked project; you might pick department id b. Can set up control at different combinations of chartfields c. Can have different control setup for different based on a unique value (we used budget ref)

Overview of KK process KK will stop transactions based on KK configuration Provide Error messages Enable authorized users to override selected errors Track warnings (doesn t stop the transaction) http://docs.oracle.com/cd/e13228_01/fscm9pbr0/eng/psbooks/fscc/book.htm

Commitment control ledger Adds another ledger to the mix Transactions post independently to KK ledger To reconcile or not reconcile??

Can set controls at different Levels Lower level settings override higher level settings Ledger Group KK Budget Period Defaults from higher level to lower level if no setup at lower level Control Chartfield Budget Attribute

Levels at which control can occur Ledger Group Allows setup of multiple control methods based on chartfields selected KK Budget Period Different than Grant Period A defined calendar period (month, year, etc) Control Chartfield The chartfield chosen to control (e.g project id) Budget Attribute A combination of chartfields (e.g. Project/ Budget Ref or Project/Activity ID)

FHCRC 9.0 KK Set Up and Business Process KK 9.0 Configuration

KK at FHCRC 1. First implemented in 2003 in 8.4 2. Goals: Keep it simple For sponsored projects: Control spending on projects by budget ref and Resource Type if needed (exception basis) For non-sponsored: Track at project only - Not a high priority to control nonsponsored projects by fiscal year or other period Insure that combination of chartfields is valid did not use combo edits

Summary of KK setup Used KK for validation of CF if no budget for combination invalid Must be a budget posted whenever a chartfield changes Many not critical for controlling transactions

KK at FHCRC Control Option: Track with Budget and Control requires budget to be established for all chartfields set up for the ledger group If any value changes new budget must be posted Budget Type Ledger Group Control Option Sponsored Parent Control Child Track w/ Budget Non-sponsored Parent Track w/ Budget Child Track w/ Budget

Modules impacted by KK Setup in Installation Options KK enabled only for expense-related modules only Billing and Receivable not enabled did not want to complicate things with revenue ledgers

5 Keys: The Parent Ledger (CC_PAR) Business Unit, Project ID, Activity ID, Budget Ref, and Funding Source (Chartfield 2)

Parent ledger (CC_PAR) Control options Ruleset: All projects used the same budgetary attributes Control CF: Project ID is primary CF being controlled

Parent ledger (CC_PAR) Control options Based on requirement for sponsored projects Non-sponsored projects wanted Track with Budget

Parent ledger (CC_PAR) Keys/Translations Chartfields included at the parent level: BU, Project ID, Activity ID, Budget Ref and Funding Source

Parent ledger (CC_PAR) budget period status No requirement to track by a calendar period Did not use in 8.4 or 9.0

Parent ledger (CC_PAR) Control cf Each project can be managed separately if control options need to be different than ledger group setup

Parent ledger (CC_PAR) Control cf Page not used for sponsored - Needed to be controlled at lower level (e.g. Bud Ref)

Parent ledger (CC_PAR) bud attribute Sponsor controls set via Budget Attributes Record entered for each Budget Ref

Parent ledger (CC_PAR) - Budget Attributes Set Options hyperlink used to change settings

Parent ledger (CC_PAR) - Budget Attributes Budget Attribute Options allow control for combination of key chartfields Budget Attribute settings override the Control CF settings as well as the Ledger Group settings This project/budget ref is set to Hold and has an end date of 10/28/14

The child ledger (CC_prj) 11 Keys: Business Unit, Project ID, Activity ID, Budget Ref, Funding Source (Chartfield 2), Deptid, Program Code, Operating Unit, Fund Code, Account and Resource Type

Child ledger (cc_prj) control options

Child ledger (cc_prj) keys/translations At child level a budget must exist for the chartfield combination but it can be overspent If a value changes, a new budget must be posted

Preparing for 9.2 Process Improvement Review

How has it gone? 1. Implemented in v8.4: 2003 2. Upgrade to v9.0: 2009 few changes made although pain points were there 3. Upgrade to v9.2: 2015-2016 Lots of known pain points for users Lead by SpearMC, conducted process improvement review in Spring, 2015 Identified several areas of improvement for KK

A Review of KK at FHCRC or as we call it.watch what you ask for.. Decisions made to meet the goals gave us just what we asked for. and then some

Modules impacted by KK KK enabled only for expense-related modules only Billing and Receivable not enabled Transaction entered via Receivables bypassed controls Charges were posting to projects that were tightly controlled No ability to associate revenue in KK - to increase spending authority we had to post a budget

Modules impacted by KK Enabled Billing and Receivables in Commitment Control Added Revenue Ledgers so revenue can be associated with the related expense ledger

Summary of KK setup Used KK for validation of CF if no budget for combination invalid Must be a budget posted whenever a chartfield changes Many not critical for controlling transactions

Key improvement identified Use of KK to perform edit of chartfields not efficient Valid chartfield combinations not critical to control of expenses Lots of errors generated and budgets posted because of common changes in department or other CF values - Users didn t understand errors - Finance didn t like posting budgets for noncritical chartfields

Changed Chartfields used in KK Simplified chartfields required in KK Removed all not critical for control Eliminates budget entry for changes to non-essential CF

Control setup in KK Budget Type Ledger Group Control Option Sponsored Parent Control Child Track w/ Budget Non-sponsored Parent Track w/ Budget Child Track w/ Budget Control Option: Track with Budget and Control requires budget to be established for all chartfields set up for the ledger group If any value changes new budget must be posted

Control setup in KK Used same KK setup for sponsored and non-sponsored projects No budgetary calendar used Rolled accounts up to a summary account level Budgets entered at summary level Transactions entered at detail account level

Key improvement identified Use of same ruleset did not work for nonsponsored They thought they didn t care but Level of control Sponsored wanted to continue with control at account/type level Non-sponsored - didn t care about control at resource type - Cared at higher level (Labor, Capital, F&A, Revenue, Everything else)

Addition of mid-level ledger group Added a third ledger to allow non-sponsored to control at a higher level than resource type Sits between Parent and current Child ledger Does not include resource type/ rolls account up to expense grouping

Change in KK account rollups CC_SUM Created a new tree with rollup of summary accounts into expense groupings CC_PRJ

Key improvement identified Use of same ruleset did not work for non-sponsored Use of a calendar Non-sponsored projects use budget ref 00 - does not denote a period of time like sponsored - transactions tied to fiscal year based on FY on transactions Lack of a calendar meant that fiscal-year based projects never ended in KK kept going on and on and on and.. Could not control FY based projects based on budget Reports became meaningless all fiscal years added together for all history

Created 2 rulesets and Added Calendar Separate ruleset for Life to Date vs Fiscal Year based projects Based on Budget Ref 00 = Fiscal Year Based: Tied to fiscal year calendar 01-99 = Life to Date based: Tied to calendar with 1 period that never ends Requires the conversion, at go-live, of Life to Data non-sponsored projects from budget ref 00 to budget ref 99 Writing off balance in budget ref 00 Carrying forward unexpended balance to budget ref 99

Customizations Creation of budget attributes for sponsored projects triggered by posting budget Parent: Created budget attribute for each project/budget ref Child: Created a budget attribute for each resource type for which a budget was posted Created non-sponsor budget upload process - changed control option for project to Track with Budget on parent ledger

Creation of Budget Attribute Finalization of budget triggers code to create budget attributes for Project/Bud Ref as well as each Resource Type Clicking Finalize produces.

Creation of Budget Attributes Lots of Budget Attributes to be maintained!! Significant time spent maintaining dates on child level

Creation of Budget Attributes Removed customization in 9.2 OSR wants to use budget attribute at parent for each budget period of a project/award Added excel to ci to load budget attributes as needed Finance wants budget attribute to load based on defaults setup for the type of non-sponsored project Added new page to store default values based on project type Added code to custom budget upload for nonsponsored to insert rows when budget is posted (based on default)

Reporting Used delivered online, PS Error Inquiry Very difficult for users to understand what the problem is Incorporates a maize of hyperlinks to navigate through Solution: Created custom, online error page. Provides users with meaningful messages and who to contact

Reporting Two custom reports existed in Crystal Reporting Commitment Control Status Report: Summary of Budget, Expenses and KK Setup for the Project/Budget Ref Commitment Control Transaction Report Detail of transactions in error including info useful to user for resolving Changes in KK structure broke reports Crystal Portal being abandoned in favor of new reporting solution not worth retrofitting existing reports Did not include all info required by users (KK Budget Dates) Decided to rebuild both reports in PS Query - Needed to create views to support new queries/other reporting

FHCRC 9.2 Future State Design KK 9.2 Configuration

Ledger for a Unit

Budget Definition Added new Effective Date (as of Fiscal Year begin date) Changed Ruleset CF

Budget Definition Added additional roll up level: CC_PRJ (Grandchild), CC_SUM (Child), CC_PAR (Parent)

Budget Definition Created Rulesets to allow managing Fiscal Year projects differently than Life to Date projects

Budget Definition Eliminated GL ChartFields from Budget Checking (with the exception of Account and Budget Ref)

Budget Definition Added Calendar ID to manage Fiscal Year projects by year

Budget Definition If transaction has 00 budget ref, used Annual (AN) calendar (annual period exists for each fiscal year)

Budget Definition Associated multi-year Calendar Id for LTD projects

Budget Definition If transaction has 01-99 budget ref, use All budget periods (AL) calendar (1 period = 7/01/1960 6/30/2099)

Budget Definition Associated multi-year Calendar Id for LTD projects

Budget Definition Added a Rollup/Summary Level to have the ability to control or turn off spending at an Expense Grouping level

Budget Definition Eliminated GL ChartFields from Budget Checking (with the exception of Budget Ref)

Budget Definition Added Revenue Ledgers to allow spending authority to be increased by Revenue for certain Projects

Budget Definition Created a new detail ledger so that encumbrance detail can be tracked and PO Roll over functionality can be used

Non-Sponsor KK Defaults Expanded existing Non-sponsor Budget Upload customization to be flexible to add default settings by Project Type at both the Control Chartfield as well as the Budget Attribute level (optional for Budget Attribute)

Non-Sponsor KK Defaults

Exception/Error Reporting Improvements New Commitment Control exception and error tools being rolled out in 9.2

Requisition Pre-check

Requisition Review Errors

KK Status REPORT

KK Transaction Report

CONVERSION PROCESS New Commitment Control exception and error tools being rolled out in 9.2

Conversion Process 1. Scope 2. Approach 3. Tools

Conversion Process - Scope 1. Budgets Included for Open Projects (Sponsor LTD, Non-Sponsor 2016, Non- Sponsor LTD) Source: Commitment Control 2. Pre-encumbrance Not included (low volume, all pre-encumbrances will be cleared at go-live either Approved/Valid budget status or cancelled) 3. Encumbrance Roll open POs to new KK structure 4. Expenses Included for Open Projects Source: Datamart (Submodule Accounting Line tables and GL Journals)

Conversion Process - Approach Pre-Upgrade MTP 1. Pre-cutover Data Clean Up 2. Update KK Configuration in 9.0 pre-upgrade with future dates Post-Upgrade MTP 1. Temporarily updated Configuration (Auto-override KK, Activating old ChartFields) 2. Perform PO Roll 1, Budget Check, Collect Costs 3. Update KK Configuration changed effective date 4. Post KK Budget and Expenses with new KK Structure 5. Perform PO Roll Part 2, Budget Check, Collect Costs 6. Reload Budget Attributes (where needed) 7. Reset Configuration (from #1 above)

Conversion Process - Tools 1. Commitment Control Journal Uploads (Budget) 2. Excel to CI (Non-sponsor budget LTD) 3. General Ledger Journal Uploads 4. SQL Updates/Deletes

Lessons Learned 1. Generate Award does not successfully populate Project/KK End Date with Close Days for Parent Ledger when have more than two children 2. Budget Journal Upload (Commitment Control > Budget Journals > Import Budget Journals) File Layout delivered as fixed format but can change to CSV PSPTFX_LSTPURGE missing LASTUPDDTTM 3. Updating Budget Definition time out issues 4. PO Roll customized to carry forward Req ID 5. Journal Spreadsheet Upload errors for _ in Ledger Group for SQL Server (workaround use 64-bit)

Lessons Learned, Cont. 6. Needed to include zero dollar budgets 7. Budget Date Changed Copy Journal Default to Recalculate Budget Date 8. Related Content can only be applied to page field up to level 2 9. Drilling URL bug 10. AR Items created through on-line pending items needed SQL insert since it was not budget checked pre-go live

FHCRC 9.2 Future State Design KK 9.2 Configuration

Concluding thoughts 1. Implementation of KK is a balancing act Use the functionality you need even if it seems complicated at first simple is not always good Don t use anything you don t really need Be sure to flesh out the business requirements Watch what you ask for!! Avoid running into. 2. If you need to make changes Don t be afraid to change But it does take work Practice, practice, practice Give yourself time for the conversion

Questions?

THANK YOU!

Jessica Mann Practice Director SpearMC Consulting jessica.mann@spearmc.com E-mail: smithj@youruniv.edu Marcus Bode Managing Director SpearMC Consulting E-mail: mbode@spearmc.com

This presentation is available for download from the Conference site at https://www.heug.org/page /us-alliance-conference-files Note: Sessions from previous HEUG conferences are also available.

appendix Print Screens of v9.0 KK setup