University of Memphis | Data Standards | Back to Contents

arrowhead 3.0  Creating and Managing Records

3.1  Rules for Clean and Accurate Records

Search first. Before you create a new record for a person or organization, you must conduct a complete ID and name search to make sure that person or organization has not already been entered in the Banner database. Each user must conduct a thorough search to prevent entering a duplicate record. Duplicate records create problems in multiple parts of the system and take many hours of staff time to locate, merge data, and remove.

Never Use:

  • the pound sign (#) within the address; it causes a problem with the Banner letter generation function.

  • the percent sign (%) and the underscore (_); both are used as wildcard characters in Oracle SQL queries.

  • the asterisk (*), the ampersand (&), the brackets ([ ]), the braces ({ }), and the question mark (?) in creating a record; these characters have special meaning with the Oracle TEXT product.

  • the left single quote (`), also known as the grave accent. The IRS and the Social Security Administration forbid the use of these characters in a name.

  • Abbreviations: If there is enough space, do not use abbreviations. When an abbreviation is required, use the abbreviated form set out in these Data Standards. If you cannot find a needed abbreviation is in these Standards, contact the University's Data Administrator for the proper abbreviation to use. Do not follow an abbreviation with a period.

Follow data entry rules. Some data fields have specific data entry rules. See that data element's specific section for its data entry rules. Except where specifically noted, avoid abbreviations.

Punctuation: With few exceptions, do not use punctuation in the name fields or the address fields. Hyphens, periods (e.g., St. John), and apostrophes (right single quote marks or acute accent marks only) may be used in the name fields when part of the legal name. However, do not use periods after a first or middle initial. Further, you may use a slash or a hyphen in address fields when required for clarity. (See Name Standards and Address Standards for more information.)

 

3.2  Multiple PIDMs Management

A "duplicate PIDM"--the duplication of the same record in Banner tables--is a serious problem. The PIDM (Person IDentification Master) is the internally assigned system number that connects all the data that is associated with a Banner ID Number. A Banner ID number record can represent student, employee, vendor, etc.

Duplicate PIDMs can occur for many reasons, including:

  • failure to perform a complete search

  • error keying in data in INB (Internet Native Banner)

  • error keying in data over the web (Self-Service Banner)

  • feeds to Banner from governmental agencies, testing agencies, etc.

Purging duplicate PIDM's or "containing" (isolating) duplicate PIDMs that cannot legally be purged, requires a planned and coordinated effort that occurs on a regular basis. This effort must be coordinated among the functional areas which are stewards of the Banner modules of Finance, Student, Financial Aid, Alumni, and Human Resources. Key Banner module users must be involved on an ongoing basis to resolve duplicate PIDM entries before further use of the duplicate record(s) prohibits its being purged from the system. When duplicate PIDM records cannot be system-purged, they will be "contained" so further use of the unusable record will be severely limited (i.e., W-2 Form).

On a nightly basis a series of scripts will run against key Banner tables to identify potential duplicate PIDM records. A Duplicate PIDM Report of potential duplicate PIDM records, sorted by Last Name, then first Name, will be created. The report will identify the modules in which the possible duplicate records exist (Location Management, Recruiting, Admissions, Academic History, Billing, Payroll, Alumni, Students, etc.) Based on the report, which will be distributed electronically, the concerned departments will coordinate the effort to determine if there are actual duplicate records. If so, the contacts in each functional area will coordinate the cleanup effort and begin the process that includes:

  • adding ";DONOTUSE" at the end of the last name field to alert users to not make any additional data entries to the record,

  • disabling the PIN of the duplicate record so it cannot continue to be accessed over the web,

  • placing a hold on the duplicate record to prevent further transactions from occurring against the record,

  • marking duplicate vendor PIDMs with ";DONOTUSE", and

  • moving the data from the duplicate (in-error) record to the correct record.

Once all data is moved to the correct record, the in-error PIDM will be purged from the data base, if legally possible.

 

3.3  Offices Authorized to Create Records

The following departments/offices shall have the ability to create new records as specified below and any required prerequisite records (e.g., General Person records).

Record Types Office
Donor Advancement
Employee Human Resources
Faculty Faculty Administrative Services
Financial Aid Financial Aid
General Person
(for Accounts Receivable - student and non-student)
Bursar, Audiology & Speech Language Pathology, Intensive English for Internationals, ID Office (for PEP initiative).
Prospect / Applicant / Student All University Admitting Offices
(Graduate, Undergraduate, Law, Continuing Education)
Sponsor Grants and Contracts
Vendor Procurement
Vendor Accounts Payable

The absolute minimum data necessary to create a new entity in Banner is a name. However, to meet University data needs and to ensure data integrity and accurate record-keeping, the following data should also be captured where pertinent to the type record being created:

  • Address and/or telephone number
  • Gender
  • Birth date
  • Social security number
  • Federal Tax ID

At various points in the building of new records (new employees, potential donors, potential students), some of this data may not be available. If none of the information noted above is available, data entry personnel should verify with a supervisor whether it is appropriate to add the new entity.

 


University of Memphis | Data Standards | Back to Contents