Description of the decision to be made

In DEFINE we have a process (Object Code Audit Groups) where we can audit which object codes can be used for a particular account.  This means that we can limit the use of the salary object codes to certain accounts.  While the process that creates financial transactions in legacy will still retain these audits, we won’t have the ability to audit object codes against accounts in Workday.

In order to process payroll transactions in DEFINE we will need to be able to assign accounts to these transactions.  In Workday, accounts will be loaded as Cost Centers (example:  AC14-7488-7010).   Additionally, because we need to be able to report on accounts at the unit code level, we are loading unit codes as Cost Center Hierarchies.  DEFINE will continue to be the authoritative source for both accounts and unit codes.

To prevent an overabundance of audit failures as we’re creating financial transactions, instead of bringing in all accounts that exist in DEFINE, we are loading a subset of accounts to Workday.  (Attached are the rules we are currently using to determine which accounts should be brought into Workday as a part of the data conversion process.) .  Additionally, we will be adding salary object codes to Object Audit groups as stated in the SC.0032 document titled Funds Checking. 

After the initial load to Workday, we will have to have an integration that will synch up DEFINE with Workday.  We will have 2 separate integrations – one for accounts and the other for unit codes. 

For the account integration, we will be changing the main account screen (CA3) in DEFINE to note whether or not a specific account also exists in Workday:

When a new account is entered by FAR or SPAA, the person entering the account will need to put Y in this new field.  Updates to accounts where the Send to Workday is Y will be sent near real time to Workday.  Not all updates will trigger this integration to Workday.  Only changes to the account attributes we are loading to Workday will trigger this integration (Fund, Title, NACUBO, Federal Element, Project funding begin and end dates).

If an account is inactivated in DEFINE, then this inactivation will be sent to Workday so that the cost center can be inactivated in Workday.  If the cost center can’t be updated programmatically, a report will be made available to the sustainment team and manual intervention will be required. 

At Go Live, we will have a sweep process to update this new field.

For the unit code integration all new unit codes will be pushed to Workday.  For updates to unit codes, just like for the accounts, only certain updates made to the unit code record will be pushed to Workday (example:  title change).   Additionally, similar to the process used for accounts, if the unit code changes can’t be done programmatically, a report will be made available to the sustainment team and manual intervention will be required.  

Concerns/Feedback/Outstanding from subcommittee

None.

Recommendation from subcommittee

Move forward with the account/unit code load and integration process explained herein.

Timeframe

Present at the November 15, 2017 steering committee meeting. 

Recommended decision maker

Workday Steering Committee based on recommendation from Workday Bridging Subcommittee

Recommended Campus Stakeholders to Engage

Workday Bridging Team (includes payroll, accounting, budget, sponsored projects), Workday Bridging Subcommittee