Description of the decision to be made

The payroll legacy payroll process creates VP4 documents that post the salary transactions to DEFINE and this process will not have many changes.  For example, these items will remain the same:

• Creating VP4s.
• Providing the data needed for the Cash Management area to determine if salary transactions paid on a state account in a payroll run should be paid on state or local funds
• Using the same salary object codes
• Using the same DEFINE process to assign Cash Accounts and State Cost Centers.
• Using the P voucher numbers (example:  P015959)
• Using DEFINE codes. 

The primary differences will be:

• The integration between Workday and DEFINE to create VP4s will run every night.  If there was a payroll run that day, then VP4 documents will be created. Therefore, we will be creating more VP4s each month and the granularity for when we create separate VP4s will be different.
• We will not have real time funds checking.  The VP4 creation process will send emails to the appropriate account contact if an account will be overdrawn when the VP4s being created are final approved.  Additionally, we will be providing a report that can be run on demand that would reflect any overdrawn accounts.
• We will be getting the data from Workday at a very granular level because having this data at this detailed level will greatly assist with having to debug any issues.  However, just as we do in legacy, we will be rolling up these records to a higher level when posting the transaction.  The granularity level of the salary transactions on a VP4 will be similar to what is used today because we’ll be using the same object codes.  What will differ is that currently both salary and salary encumbrance transactions are on the same VP4 document.  In bridging, these transactions will be on separate VP4s.
• The service dates will be slightly different than what is used today.  In legacy, we create appointments anytime something changes for a person that would cause a change for payroll and the dates of these changes are included in the appointment record.  We will not have this same functionality in Workday.   For example, if a person who is paid monthly gets a raise that is effective on the 12^th of the month, in legacy we would have 2 salary transactions.  One for the old rate from the first of the month to the 11^th and another for the 12^th of the month to the last day of the month.  In Workday, we would have only 1 transaction and the service dates would be from the first of the month to the last day of the month.  While we won’t break down the service dates as we do in legacy, we will still have the correct month for the service - even when the service was for a retro period. 

Concerns/Feedback/Outstanding from subcommittee

None.

Recommendation from subcommittee

Move forward with the posting salary transaction 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