1. Program Updates & People Hub
Program Updates & People Hub
March 6, 2017

2. Program Updates People Hub Upcoming Forum Topics Agenda
Spend/Revenue Categories for ISP Journals
COA Converter usage
Web Service Definitions
Testing Reminders
Deployment – Future Forum Topic
People Hub
Upcoming Forum Topics

3. Program Updates

4. Spend/Revenue Categories for ISP Journals
Data Validation errors encountered on some ISP Journals
Spend/revenue category values stalled testing progress
Spend and revenue category values no longer auto-populate in the PTAEO to COA Converter
Instead, system owners need to:
Determine appropriate spend and revenue category values by applying business rules
Work with your local business office to identify spend/revenue category charging instruction values for use in integration files
If business offices encounter actual mapping as opposed to validation errors, they will work with the COA team.
During integration testing for Workday Release 4 impacted systems, some ISP Journal transactions have encountered data validation errors for spend and/or revenue categories when submitting Workday charging instructions. To help address this issue, spend and revenue category values will no longer auto-populate in the PTAEO to COA Converter. Instead, system owners will need to determine the appropriate spend and revenue category values needed to populate test transactions. Actions Requested
System Owners need to work with their local business office to identify charging instruction values for use in integration files, if not done already. This action helps to avoid data validation errors for integration testing.
If actual data mapping errors (as opposed to testing validation errors) are suspected, System Owners are requested to share this information with their business office, and the business office will then work with the Chart of Accounts (COA) team to resolve potential data mapping issues, if appropriate.
Temporary fix is to get rid of validations in wd via configuration….these will be put back in future
Still need to apply business logic to determine revenue/spend categories by working with business offices.

5. Additional Resources for Journals
New: Journal Import File Quick Guide for Impacted Systems - Learn how to create a Workday Journal Import file
New: Yale Service Providers – Guidance for COA Segment Usage in Workday – Learn how to use “internal” revenue and spend categories for internal billing versus external billing and other guidance for Yale service providers
Refer to communication to impacted system owners on Friday, March 3, for more resources
From communication on Friday:
The second one to Yale Service Providers contains information relayed to the business offices which may offer some assistance in understanding the business rules
Resources
New: Journal Import File Quick Guide for Impacted Systems – Learn how to create a Workday Journal Import file
New: Yale Service Providers – Guidance for COA Segment Usage in Workday – Learn how to use “internal” revenue and spend categories for internal billing versus external billing and other guidance for Yale service providers
PTAEO to COA Converter – Convert a single PTAEO to the full Workday string and perform batch uploads of PTAEO’s
Journal File Layout
Journal Input File Layout Sample
Journal Import Requirements and Technical Guidance

6. COA Converter Usage
Departments are doing lots of data clean up at this time and COA mappings are changing frequently.
It might be useful to your testing process to run the PTAEO to COA Converter on a weekly basis

7. Web Service Definitions
COA Validation Tool
This web-based tool validates Workday Charging Instructions (for both single and batch charging instructions). In addition to validating each individual COA segment, the validator looks at the combination of certain COA segments to ensure they are valid.
Note: The tool is currently in a test environment. Production URL will not be available until Workday R4 go live.
COA Validator Service
The main purpose of the COA Validator web service is to provide Yale systems and application owners a tool to validate Workday Charging Instructions. Access to use the web service requires approval and access is given via a service account.  

8. Web Service Definitions
COA Segment Service
The main purpose of the COA Segment web service is to provide Yale systems and application owners data about COA segments, hierarchies and other general COA data. Access to use the web service requires approval and access is given via a service account.
COA Integration Hub 
COA Integration Hub is a SQL Server database that contains information about COA segments, hierarchies and other general COA data. COA data is downloaded from Workday into the COA Hub on a routine interval and is available to use for Yale systems and application owners. Access to use the COA Hub requires approval and access is given via a service account.
BSG Public Confluence site

9. Test Plan on Impacted Systems Website
Testing Reminders
Test Plan on Impacted Systems Website
Test Scenarios & Test cases in HPALM
Program expectations:
Timely & regular updates in HPALM for:
Status of all test cases within all test scenarios
Defects linked to integrations & test cases
All Integration testing completed by 3/31
Exceptions to 3/31 handled on a case by case basis
System owners need to complete a Risk Assessment form
Exceptions to 3/31 discussed at program & executive committee levels
Program expectations of when testing is done
Know what their scenarios are
System owners/testers need to update HPALM

10. Deployment – Future Forum Topic
Overview of deployment topic planned for mid-April (4/10)
Overview to explain:
Where Cutover, Tenant, Data Migration, etc. fit in
When the program expects to engage you for planning through PoCs
If you need to plan cutover activities earlier than mid-April, these will be handled separately on a case-by-case basis
Work with your PoCs to let them know and they will bring to the program for prioritization
Overview will not have everything buttoned up, rather, it explains where Cutover, Tenant, data migration, etc. fit in and when we expect to engage them for planning (through the POCs) so that their needs are considered/worked in to the overall Deploy phase activities.  If there are any systems who insist they need to plan their cutover activities earlier than mid-April, we should handle them on a case-by-case basis and they should work with their POCs to bring that through the Program for prioritization.

11. People Hub
MOVERS, LEAVERS AND JOINERS

12. MOVERS, LEAVERS and JOINERS
Movers, Leavers and Joiners, OH MY!
Movers, Leavers and Joiners, Oh MY!

13. MOVERS, LEAVERS and JOINERS
MOVER – Someone who moves from one department to another department within the organization or
Who changes roles or relationships (ie. Student->Staff, Staff->Student, WorkerAfilliate, etc..
LEAVER– Someone who leaves Yale or leaves your planning unit.
Note: They will no longer have ANY active identity at Yale – or they previously did not have ANY active identity at Yale
JOINER– Someone who joins Yale from outside the organization or joins your Planning Unit from
Outside your Planning Unit.
“IT’S A MATTER OF PERSPECTIVE”

14. IDENTIFYING CHANGE IN PEOPLE HUB
People Hub Incremental Load process
For historical tracking of people data changes over time. This will allow the business to track movement like leavers and movers, job and position movement, etc.
Various views are being created to provide change report for a given time period.
People Hub History Load – This is the process by which we load historical data from systems such as the existing Data Warehouse and SRT, so that reports can be created to track and trend changes going as far back as 30 years.
The actual load of historical data for People Hub will be implemented when RE Data Mart and HR Data Mart are completed.

15. IDENTIFYING CHANGE IN PEOPLE HUB
“Joining, moving and leaving a company present potentially the biggest shift in the IT deltas that Managers and Administrators contend with; and so ensuring closer links with HR for status changes of employment.” 
BLOG:
Position Management
LOAD
People Hub
IDR

16. IDENTIFYING CHANGE IN PEOPLE HUB
“Joining, moving and leaving a company present potentially the biggest shift in the IT deltas that Managers and Administrators contend with; and so ensuring closer links with HR for status changes of employment.” 
PEOPLE HUB HISTORY VIEW
Mover!!!
Leaver!!!
UPI
Name
DEPT
Worker Status
Valid_Period_Start_Date
Valid_Period_End_date
U101
Robert
D101
Active
2/3/2016
4/4/2016
D102
Null
U102
Greg
5/1/2016
8/10/2016
Terminate
U103
Susan
D103
2/25/2017
BLOG:
LOAD
Joiner!!!
Look at Status and Hire Date
People Hub
IDR

17. QUERYING WHAT CHANGED/LAST LOOK
PEOPLE HUB HISTORY VIEW
Mover!!!
Leaver!!!
ALL CHANGES SINCE LAST PULL
UPI
Name
DEPT
Worker Status
Valid_Period_Start_Date
Query_Period_End_date
U101
Robert
D101
Active
2/3/2016
4/4/2016
D102
12/31/9999
U102
Greg
5/1/2016
8/10/2016
Terminate
U103
Susan
D103
2/25/2017
SELECT *
FROM PEOPLE_HUB_HISTORY_V
WHERE Valid_Period_Start_Date > [Last_Pull_Date]
LATEST CHANGE SINCE LAST PULL
SELECT *
FROM PEOPLE_HUB_HISTORY_V
WHERE Valid_Period_Start_Date > [Last_Pull_Date] And Query_Period_End_Date is Null
Joiner!!!

18. QUERYING LEAD/LAG TO THE RESCUE
PEOPLE HUB HISTORY VIEW
Leaver!!!
Mover!!!
ALL CHANGE SINCE LAST PULL
UPI
Name
DEPT
Worker Status
Prev_Worker_Status
Valid_Period_Start_Date
Valid_Period_End_date
U101
Robert
D101
Active
Null
2/3/2016
4/4/2016
D102
U102
Greg
5/1/2016
8/10/2016
Terminate
U103
Susan
D103
2/25/2017
SELECT …,LAG(Worker_Status,1) OVER (PARTITION BY UPI ORDER BY Valid_Period_Start_Date) AS Prev_Worker_Status, …
FROM PEOPLE_HUB_HISTORY_V
WHERE Valid_Period_Start_Date > [Last_Pull_Date]
Joiner!!!
Look at Status and Hire Date > [Last_Pull_Date]
SQL: LAG(Worker_Status,1) OVER (PARTITION BY UPI ORDER BY Valid_Period_Start_Date) AS Prev_Worker_Status

19. People Hub Testing can still be accessed at this time.
PEOPLE HUB STATUS
Finished cycle 1 testing, currently triaging defects and preparing for cycle 2 testing on 3/20/2017
People Hub Testing can still be accessed at this time.
Some Issues found during cycle 1 testing:
When there is a change in position, end dating to not happening correctly
When there is a change in Cost Center, end dating is not happening correctly
Future position is missing in People Hub
Yale Relationship is not available for all active people
Cost Center is missing for a few active people in Workday

20. Other topics/suggestions?
Upcoming Forum Topics
UAT: 3/13
Deployment: 4/10
Other topics/suggestions?

21. Something we didn’t cover today?
Check these Resources to see if it’s been addressed:
Impacted Systems Website -
BSG Public Confluence Site – on+Services+Public+Home
If not, your question to
Or, better yet…
Work with us to address it at a forum & also help your colleagues