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.
BANNER
John Smith
John Smith
John A. Smith
Jonathon Smith
John Smith
John Smith
Johnnie Smith
Data Input
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)


9.
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
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 resynced 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 Tab
The 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
?