Pidm Problem Solved

Joseph Francis

Vipul Patel

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!

Topics of Discussion

What is a Multiple PIDM?

Banner 7.x Common Matching

New Process for Identification & Resolution of Multiple Pidms

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.

The Importance of Eliminating Multiple Pidms The painful problems resulting from multiple

pidms include: Blocked Financial Aid Blocked Registration – Students Un-credited Payments – Students Incorrect W2s – Employees Incorrect 1099s - Contractors

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.

John Smith

Data Input

John Smith

BANNER

John A. Smith

Jonathon Smith John Smith

John Smith Johnnie Smith

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.

GOAMTCH - Common Matching Entry Form

New Process for Multiple Pidm Identification & Resolution

1. Identification of Multiple Pidm 2. Submission of Multiple Pidms identified - Marked for

data pull (form, Job)3. Data pull - Extract data (Automated)4. Analysis

Review / Analyze data Make merge decisions (automated with manual

override)5. Merge Processing

Generate the merge script based on the merge decisions.

Run the script in pre-PROD Database

New Process for Multiple Pidm Identification & Resolution (Continued)

6. 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

7. Merge in PROD - Run the merge script in PROD

8. 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

9. History - All merged data is maintained in the database for later reference and generating reports

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

GZRPIDM Report for identifying potential multiple pidm records

GZAPENT – GW Multiple Pidm Entry Form

GZAPIDM – Pidm Merge Form

GZAPIDM – Table Level Merge 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.

GZAPIDM – Parent-Child Relationship

GZAPIDM – Record-Level Data

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.

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.

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

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

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.

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

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).

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).  

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.

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

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.

Q&A

?