Pidm Problem Solved

1. Pidm Problem Solved Joseph Francis Vipul Patel

2. Session Rules of Etiquette • Please turn off your cell phone/pager • If you must leave the session early, please do so as discreetly as possible • Feel free to ask questions during the presentation Thank you for your cooperation!

3. Topics of Discussion • What is a Multiple PIDM? • Banner 7.x Common Matching • New Process for Identification & Resolution of Multiple Pidms

4. What is a Multiple PIDM? • A single entity (person or non-person) is assigned two or more internal identification records in Banner (PIDMs). A single entity is now treated as multiple entities. • Multiple PIDMs are caused by data entered in Banner by various User offices at various stages without accurate matching searches.

5. The Importance of Eliminating Multiple Pidms • The painful problems resulting from multiplepidms include: • Blocked Financial Aid • Blocked Registration – Students • Un-credited Payments – Students • Incorrect W2s – Employees • Incorrect 1099s - Contractors

6. John Smith John A. Smith John Smith Jonathon Smith John Smith John Smith Johnnie Smith Banner 7.x Common Matching A general rule is that a multiple PIDM issue is easier to resolve the earlier it is caught. When additional information is added to either record, resolving the problem becomes exponentially more difficult. BANNER DataInput

7. Banner 7.x Common Matching • Common Matching greatly reduces and helps in the prevention of the creation of duplicate records when people are added via Banner forms. • The Common Matching Entry Form (GOAMTCH) allows you to determine whether a person matches an existing record before it is entered into the database. • The GOAMTCH form is called automatically from the form when an ID is generated or entered, and the ID does not already exist in Banner.

8. GOAMTCH - Common Matching Entry Form

9. New Process for Multiple Pidm Identification & Resolution • Identification of Multiple Pidm • Submission of Multiple Pidms identified - Marked for data pull (form, Job) • Data pull - Extract data (Automated) • Analysis • Review / Analyze data • Make merge decisions (automated with manual override) • Merge Processing • Generate the merge script based on the merge decisions. • Run the script in pre-PROD Database

10. New Process for Multiple Pidm Identification & Resolution (Continued) • Approvals • Approvers will receive email notifications from the new tool • Approvers will complete their approvals directly in Banner • Approvers can see the status of all their merges at all times • Merge in PROD - Run the merge script in PROD • Re-Synchronization (Just before step # 7) • Verify that the approved merge decisions are still valid • If the data has changed, return the control to # 4 above • History - All merged data is maintained in the database for later reference and generating reports

12. GZRPIDM Report for identifying potential multiple pidm records Match Level Key: • 1 - Last Name + First Name + Middle Name • 2 - SSN • 3 - Last Name + Birthdate • 4 - (First Name + Last Name) + ((State + Zip) or (City + Nation)) Note: Name matches ignore case, spaces and non-alphabetical characters

13. GZRPIDM Report for identifying potential multiple pidm records

14. GZAPENT – GW Multiple Pidm Entry Form

15. GZAPIDM – Pidm Merge Form

16. GZAPIDM – Table LevelMerge Decisions There are three characters to choose from when addressing the records on your spreadsheet. “C” – Change pidm “D” – Delete pidm “L” – Lower level (or) Special instructions Special instructions indicates several scenarios such as; name/ address correction, deletion of one record on the bad pidm, but keeping several records that are on the same pidm, etc.

17. GZAPIDM – Parent-Child Relationship

18. GZAPIDM – Record-Level Data

19. GZAPIDM – Record-level data • Column value changes may be entered for any column. If the column is a primary key field then the form will validate accordingly. • Validation includes datatype, data size, primary keys, and foreign keys (parent child relationships). • Upon completion of the Merge Analysis the data will be re-synced with Production to ensure that it is still current. The merge script will be generated and run in pre PROD database.

20. Approval Process • After the script has been generated and run in pre-Prod database, the Analyst will Determine the approvers. • Based on approver rules (pre-defined approval areas based on departments and Banner modules, users assigned to each approval area), each PSN will be assigned to the appropriate approvers. • Each approver will receive an email to review the merged data in pre-Prod. • Once all required approvals have been attained , the re-sync job will run again. If the data is still current, the merge script will be run in Production.

21. Approval Form – Main Tab The Approvers Form will display all PSNs which have tables that are part of the approving area.

22. Approval Form – Activity Tab The Activity tab displays all of the activities performed on that PSN by all Approving Areas, including comments and decisions.

23. Approval Form – Tables The Tables tab displays a list of all tables in the approving area for the PSN, that are affected in this merge.

24. Approval Form – Approving Areas The Approving Areas tab displays the decisions, along with the latest comments, if any, made by each approving area for that PSN

25. Email Notifications • The email notification subscription form is used for identifying approvers and notifying them when a multiple pidm resolution requires their approval. • Taskforce members may subscribe to email notifications of pidm merges that require their approval. They may also designate their substitute for when they are unavailable. • All status changes for the PSN are eligible for email notifications and analysts, approvers and DBAs (and others) may choose to subscribe to notification on any step of the process (and the relevant data of that step).

26. Email Subscription Users will receive their emails based upon the following: • The Users can subscribe to receive daily / weekly digest or individual emails of notification when they need to approve Multiple Pidm merges. • The User Group defaults are stored in the GZRPEDF table.  If a user belongs to more than one user group the broadest interpretation of the rules is used. • The body of the email is generated using the data in the Email Context Table (GZBPECX).  

27. Resynchronization Process • At various points in the process, as well as on demand, the saved data in pre-Prod database will be re-synced with Production data. • This will identify additional transactions or updates (if any) that have taken place against any of pidms in a PSN under review. • Some changes may require that the merge script be re-created.

28. Merge in Production • If the re-synchronization process does not show any errors, the merge script is run in Production • The PSN is marked as Closed • An email notification is sent to the impacted approving areas to notify them of a successful merge

29. Summary • The multiple pidm resolution process is a consolidated solution within our existing ERP system. • This automated tool is user-friendly and can be easily exercised by end-Users or Functional Analysts. • Re-synchronization at various stages of the resolution process eliminates the problem of data being created in production for bad pidm and not merged to good pidm that would have resulted in orphan records in Banner. • Maintaining historical data for audit and reporting purposes.

30. Q&A ?