Cognos 8 Business Intelligence the Official Guide

Document Sample
Cognos 8 Business Intelligence the Official Guide Powered By Docstoc
					                                           DRAFT
                 Duquesne University




                  DU-IT
         DATA STANDARDS MANUAL
                                       Version 2.0 -- April, 2007




NOTE: The DU-IT Data Standards Working Groups, representatives from DU-IT Implementation Projects and
Computing and Technology Services (CTS) were responsible for developing the data standards to be used with
SunGard HE Banner, QAS Address Validation, and Adirondack Solutions applications. The Data Standards Working
Group must approve any changes recommended for data standards in use at Duquesne University.




DRAFT                                        Page 1 of 53                            Data Standards Manual
                                         Table of Contents
Summary of Requirements for Creating and Maintaining Accurate Records               4

PREFACE                                                                             5
1. Data Administration                                                              6
        Purpose                                                                     6
        Data Confidentiality                                                        6
        Data Access                                                                 7
2. Common Matching                                                                  15
3. General Person and Non-Person Maintenance and View Processes                     17
        Identifying the Appropriate Data Steward to Perform Changes                 18
        Banner Forms for Completing and Identifying Information Change              21
        Changes to Legal Name, Marital Status, Social Security Number
        and/or Taxpayer                                                             22
ID Number
        General Person and Non-Person View Processes                                23
        General Person and Non-Person Point-o-Entry Processes                       24
        Multiple Person Identification Master (PIDM)                                29
4. Current Identification                                                           32
        “Person” and “Non-Person” DU-IT Banner Numbers                              32
        Name Types32 Last, First, and Middle Names                                  33
        Prefixes and Suffixes.                                                      35
        Preferred First Name                                                        35
        Full Legal Name                                                             36
        Non-Person Names                                                            36
        Summary37
5. Alternate Identification                                                         38
        General                                                                     38
        Name Type                                                                   38
        Change Type                                                                 38
        Validation Tables                                                           38
6. Address Information                                                              39
        Address Type                                                                39
        Address Type Stewards                                                       42
        From/To Dates                                                               42
        Sequence Number                                                             42
        Street Lines 1, 2, and 3                                                    42
        City                                                                        45
        State or Province                                                           46
        Zip or Postal Code                                                          46
        County                                                                      46
        Nation                                                                      47
        Telephone Type/Telephone                                                    47
        Inactivate Indicator                                                        47
        Address Source                                                              47
        Delivery Point/Corrective Digit/Carrier Route                               47
        Validation Tables                                                           47
        Summary                                                                     48
7. Telephone Information                                                            49
        General                                                                     49
        Telephone Type                                                              49
        Telephone Numbers                                                           49
        Primary/Unlisted/Inactive Indicators                                        49
        International Access                                                        50
        Comment                                                                     50


DRAFT                                     Page 2 of 53                   Data Standards Manual
        Address Type                                                                         50
        Sequence                                                                             50
        Validation Tables                                                                    50
8. Biographical Information                                                                  52
        Gender                                                                               52
        Birth Date                                                                           52
        Age                                                                                  52
        Social Security Numbers (SSN) and Taxpayer Identification Numbers (TIN)              52
        Confidential Indicator                                                               52
        Deceased Indicator/Date                                                              52
        Citizenship                                                                          53
        Ethnicity                                                                            53
        Marital Status                                                                       53
        Religion                                                                             54
        Legacy                                                                               54
        Veteran Information                                                                  54
        Validation Tables                                                                    54
9. E-mail Information                                                                        56
        E-mail Addresses                                                                     56
        Comment                                                                              56
        Validation Tables                                                                    56
10. Emergency Contact Information                                                            57
        Priority                                                                             57
        Contact Name                                                                         57
        Relationship                                                                         57
        Address                                                                              57
        Telephone                                                                            57
        Validation Tables                                                                    57
Appendix A.1. – Student, Employee or Vendor “Person” Change Request Form                     58
Appendix A.2. – Student, Employee or Vendor „Person” Social Security # Change Request Form   59
Appendix A.3. – Vendor “Non-Person” Change Form                                              60
Appendix A.4. – “Person” and “Non-Person” Vendor Create Form                                 61
Appendix A.5. – Banner Oracle User Name ID Change Form                                       62
Appendix B – SCT Banner Validation Table/Data Standard Change Request                        63
Appendix C.1. – Prefixes                                                                     64
Appendix C.2. – Suffixes                                                                     64
Appendix C.3. – North American Numbering Plan (NANP)                                         64
Appendix D – Miscellaneous                                                                   65
Appendix D.1. – Calendar Dates                                                               65
Appendix D.2. – Driver‟s License Information                                                 65
Appendix D.3. – Letter and Paragraph Names                                                   66
Appendix D.4. – Quick-flow Names                                                             66
Appendix E – Shared Validation Tables                                                        68




DRAFT                                      Page 3 of 53                          Data Standards Manual
    SUMMARY of REQUIREMENTS for CREATING and MAINTAINING
                    ACCURATE RECORDS
• NEVER SHARE YOUR PASSWORD: Data integrity begins with control over access to the
database. Your user ID and Password creates your identify within the Banner system. Protecting
your password safeguards the validity of the data held in the system and the personal information
of students and staff. It also protects your identity from being misused within the system by
someone else.

• SEARCH FIRST: Before creating a new record for a person or organization, conduct an 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.

• NEVER USE: In creating a record, never use the pound sign (#) or the percent sign (%). The
pound sign can cause Banner database errors and the percent sign has a special use within the
search functions of the system. The ampersand (&) can only be used as part of a legal name,
otherwise do not use it in any other capacity.

• ABBREVIATIONS: There are specific ways to abbreviate words that are shown in this
document and in Appendix C. Please use only these approved forms when entering data.

• PUNCTUATION: Do not add punctuation where there is none. Use hyphens, apostrophes,
dashes, and periods exactly as the person indicates in writing except where noted in the guidelines.

• DATA CHANGES: Please do not make any data changes unless you have the appropriate
responsibility and authority. When you do make changes, please follow the procedures established
in this manual.

• REMEMBER: Many data fields have specific data entry rules. These specific rules are outlined
in this manual and should be carefully followed.




DRAFT                                    Page 4 of 53                         Data Standards Manual
                        DATA STANDARDS MANUAL PREFACE
DATA STANDARDS
Duquesne University (the University) utilizes the SunGard Higher Education (HE) integrated database.
Within this integrated database various modules share data items. The University recognizes that data
standards are vitally important in protecting the data assets of the University by maintaining accurate and
consistent data that is standardized for use in all areas of the University.

The “Data Standards Team” was formed to collaboratively develop this “Data Standards Manual” and it‟s
accompanying “Shared Validation Tables Dictionary.” The “Data Standards Team” has morphed into
Working Groups with specific assignments. The standards in this manual address the data entry standards
for data that is shared among the various Banner systems.

This manual is intended as a standards policy reference guide and is not meant to be used as a training
guide. This manual is also intended to be a living document with the review of each standard continuing on
a regular basis. Any recommended changes to the manual need to be reviewed and approved by the “Data
Standards Team.” (See appendix E).

PURPOSE
The purpose of this document is to establish guidelines for:
    Stewardship of the University‟s data and records maintained in the Banner Database;
    Ensuring data integrity, consistency and completeness;
    Providing appropriate security for personal information about staff and students;
    Providing appropriate access to Banner information system;
    Ensuring that the interpretation of information is accurate and consistent within the University;
    Outlining the responsibilities of users of the information maintained in the database.

ADMINISTRATIVE RESPONSIBILITY
By law, certain data is confidential and the University cannot release it without proper authorization. Users
of the data MUST adhere to any applicable federal and state laws as well as University policies and
procedures related to data protection and confidentiality.

Data is a vital asset owned by the University. All institutional data, whether maintained in the central
database or copied into other data systems (e.g. personal computers), remains the property of the University.
Access to data is provided to support a user‟s official University responsibility. Data will be used only for
legitimate University business.

INFORMATION ACCESS DEFINITIONS
All Banner users are assigned a Log-in User ID and Password. Users ARE NOT to share these access codes
with anyone. The user is responsible for all transactions occurring during the use of their log-in user ID and
password.

“Query” access enables the user to view, analyze, but not change, University data. “Maintenance” access
provides both inquiry and update capabilities. If data is downloaded to a personal computer or other device,
the downloaded data must be safeguarded and utilized responsibly.

The University will provide appropriate training for each type of access which will include the following:
    Reading, understanding and agreeing to the guidelines of this document, and any additional
       requirements identified by the data Steward;
    Hands-on training in accessing, understanding and interpreting the information;
    Maintaining the security, confidentiality, integrity and accuracy of the data accessed.




DRAFT                                        Page 5 of 53                             Data Standards Manual
1. Data Administration
A. Purpose

This manual provides data standards requirements for the protection, access, maintenance, and use
of University data that is electronically maintained on the Banner system. This manual defines the
responsibilities of users who input and access that data. Divisions/departments may have
individual requirements that supplement, but do not replace or supersede the requirements outlined
in this manual.

The Standards outlined in this manual are authoritative for the Banner System AND for all
University Systems that interface with the Banner System.

B. Data Confidentiality

The Banner information system is an integrated database with information on constituents of all
types – applicants, students, employees, vendors, alumni, etc. Many benefits come from this
integration. Personally identifiable information on all constituents is made available to University
employees for the sole and explicit purpose of allowing them to carry out their official University
functions. Any other use is prohibited. The same principles of confidentiality that apply to paper
records also apply to electronic data. It is the responsibility of each school official to understand
his or her legal responsibilities under the Family Educational Rights and Privacy Act (FERPA),
Health Insurance Portability Accountability Act (HIPAA), Student & Exchange Visitor System
(SEVIS), and the Gramm-Leach Bliley Act (GLBA). Failure to adhere to privacy regulations can
result in disciplinary action up to and including termination.

FERPA: The Office of the Registrar administers FERPA for the University. General FERPA
information inquiries should be referred to:

       Office of the Registrar
       Ground Floor, Administration Office
       Phone: (412) 396-6212
       Fax: (412) 396-5622
       www.registrar.duq.edu


HIPAA: The HIPAA Compliance Officials develop and/or oversee the development of policies
and procedures that are in compliance with federal and state standards for the protection of the
privacy and security of protected health information (PHI).

SEVIS: The Office of International Programs (OIP) and Human Resources Management (HRM)
oversee policies and procedures that are in compliance with the Federal Department of Homeland
Security and its subdivisions including U.S. Immigrations and Customs Enforcement.

GLB: The Gramm-Leach Bliley Act requires protection of personally identifiable financial
information including Social Security Numbers.




DRAFT                                     Page 6 of 53                          Data Standards Manual
C. Data Access

The purpose of this section is to establish guidelines for accessing and using Duquesne University‟s
DU-IT Project, specifically Banner System/Module data and self-service through the DORI Portal
system. This section does not address Cognos security administration.

   a. Definitions:

   DU-IT Banner Module Data Owner: The individual responsible for the administrative oversight
   of a given DU-IT Banner System or specific modules within the DU-IT Banner System - -
   Finance, Advancement, Human Resources, Financial Aid, Student Admissions and Recruiting,
   Student Registration and Student Accounts - - and ultimately responsible for the data within said
   module/system.

   DU-IT Banner Role Level Security Officers: The individual responsible for granting access
   permissions through Oracle‟s concept of role-level privileges, groups job responsibilities into
   “classes,” and grants appropriate access permissions to Banner objects under the guise of
   “classes.”

   DU-IT Banner Finance Security Officers: The individual responsible for granting access
   permissions to Budget Users based on security requirements - - availability, integrity and
   confidentiality - - related to fund and organization.

   DU-IT Banner System Administrators: The individuals responsible for implementing the security
   requirements defined by the Security Officers and Banner servers, Banner and Oracle Database
   Administration (DBA) and Banner Operational support.

   Objects: The term used to collectively identify Oracle and DU-IT Banner forms, reports and
   processes.

   b. DU-IT Banner Access Guidelines

   DU-IT Projects are the property of Duquesne University. The terms Banner, Oracle, Adirondack
   and Cognos will be used in conjunction with DU-IT Projects. Data supporting DU-IT Projects
   will be used for official Duquesne University business. In accordance with TAP 26
   (COMPUTING ETHICS AND GUIDELINES), “University owned computing resources are
   intended for administrative, research, and educational purposes only; they should be used in a
   manner consistent with the administrative, instructional, and research objectives of the
   University. They should not be used for personal profit, commercial development, or frivolous
   activities.” Specific non-institutional business use of DU-IT Projects data may be authorized
   under official policy.

   Access to DU-IT Project data is restricted to authorized personnel. In accordance with TAP 26,
   “Access to computers, programs and files is restricted to authorized users. Respect for the
   privacy of others is maintained by not intentionally seeking information about passwords or files



DRAFT                                    Page 7 of 53                         Data Standards Manual
  belonging to other users unless explicitly authorized to do so by those users.” Unauthorized
  access to DU-IT Project data is prohibited.
  Access to specific data is generally limited by need to know, job responsibilities, supervisor
  approval, and system or data owner approval. Thus, anyone in the service of Duquesne
  University, with a genuine business or educational need, may be authorized to access DU-IT
  Project data necessary to perform their duties. An individual‟s access to DU-IT Project data is a
  privilege and will be removed when the individual leaves the service of Duquesne University or
  during an extended absence. Supervisors are to notify Human Resources immediately when an
  individual, including student employees, leaves their service or begins an extended absence as
  standard practice. Human Resources will immediately engage DU-IT Project System
  Administrator to record and remove security permissions.

  DU-IT Banner Module Data Owners have the sole authority to grant access to the data within the
  modules they administer. DU-IT Banner Module Data Owners are encouraged to use the
  principle of least privilege when granting access to their module data.

  The DU-IT Banner Module Data Owner may serve as (or delegate the duty of) DU-IT Banner
  Role Level Security Officer. The DU-IT Banner Finance System allows security to be
  established by User IDs, rule groups and rule classes, forms and process for rule groups, fund
  and fund types, and organizations. The DU-IT Banner Finance Data Owner may serve as (or
  delegate the duty of) DU-IT Banner Finance Security Officer.

  Additionally, TAP 26 addresses privacy as one of two rights regarding computing ethics.
  Persons, and processes, accessing DU-IT Project data will uphold confidentiality and privacy of
  individuals whose data they access and observe any laws, regulatory requirements, policies and
  ethical restrictions that may apply with respect to their accessing, using or disclosing such
  information. Information in the DU-IT Suite of Systems is considered confidential and must be
  handled accordingly. Information obtained from the DU-IT Suite of Systems should never be
  shared outside the workplace or used for any purpose that is not related to the users assigned job
  responsibilities.

  All data and information not in the public domain must remain confidential at all times.
  Persons, and processes, with access to DU-IT Project data, regardless of its form (e.g., electronic,
  print, etc.), will insure that all reasonable and prudent measures have been taken to protect the
  data from theft and unauthorized or accidental viewing, copying, downloading, modification, or
  destruction. The data must be protected while in use, in transit and in storage.

  To ensure adequate controls over security:
    There must be segregation of duties between DU-IT Banner Module Data Owners,
       specifically those entrusted with the duties of DU-IT Banner Role Level and DU-IT Banner
       Finance Security Officers, and DU-IT Banner System Administrator;
    User access permissions will be annually reviewed by DU-IT Banner Module Owners to
       ensure compatibility with job description;
    The use of generic accounts will be prohibited for any use that could contain protected
       data; and




DRAFT                                   Page 8 of 53                         Data Standards Manual
       Employees should follow good security practices in the selection and use of passwords.
        Passwords are an important aspect of computer security; they provide a means of validating
        an employee‟s identity and establishing access rights to Duquesne University data
        /information. Duquesne University follows a strong password policy. Guidelines can be
        found at www.cts.duq.edu. In regards to passwords, all employees are expected to:
          o Treat passwords as private and highly confidential. Passwords are not to be shared.
          o All passwords must be changed at least every 120 days.
          o Avoid keeping a paper record of passwords.
          o Passwords must not be inserted into email messages or other forms of electronic
              communication.
          o Passwords for Duquesne University accounts should not be used for non-Duquesne
              University access (e.g., personal accounts, option trading, benefits, etc.
          o All passwords must be immediately changed if they are suspected or known to have
              been disclosed to or compromised by anyone other than the authorized user.
          o If a user suspects a password has been disclosed or compromised, the user must
              report the incident to the Help Desk.

       Database logging will be reviewed to determine whether log files are being saved an
        appropriate number of days to reconstruct unauthorized access events.

       The single sign-on via the DORI Portal grants tailored access to DU-IT Suite of Systems
        based on the user‟s job functions. Therefore, users should never leave work stations while
        logged on.

  In the event of a suspected security breach, The Duquesne University Director of Operations and
  Systems is to be notified immediately. Incident response procedures will be immediately
  followed.

       A. Authorization to Use DU-IT Banner data

  There are several levels of security associated with using DU-IT Banner Systems:
   Oracle Security provides database security features and auditing capabilities.
   DU-IT Banner Security provides form, report, and process level security across DU-IT
     Banner Systems/Modules.
   DU-IT Banner Finance System Security allows security to be established by User IDs, rule
     groups and rule classes, forms and process for rule groups, fund and fund types, and
     organizations.
   LDAP Security through the DORI Portal.
   The following level of security will not be implemented for the first Wave: Fine-Grained
     Access Control (FGAC) is an Oracle feature that can be used to provide row-level security
     for Oracle database tables. SunGard HE Banner introduced two optional security features
     that take advantage of the capabilities of Oracle FGAC. These features are:
         o The new Value-Based Security (VBS) and
         o Security for Personally Identifiable Information (PII).
   Cognos Security is not addressed in this document




DRAFT                                  Page 9 of 53                        Data Standards Manual
  All authorized users must have:

         An Oracle ID: The DU-IT Banner Account Request Form / Access Request Form is
         available from CTS. The ID will be the LDAP USER ID. This LDAP User ID will be
         used to gain access to DORI Portal, Internet Native Banner (INB) and Banner Self-
         Service (SSB).

         Authorization for each DU-IT Banner Form required in conjunction with duties
         associated with job function. The set of forms a user needs is determined by the pre-
         approved processing functions authorized by the Director or Department supervisor.
         Forms are available at the CTS will website.

     B. Getting Authorization

             a. Initial Authorization - - Wave One Steps

  The scope of Wave One security administration involves limited numbers of authorized
  personnel, but follows these general steps:
  1. Establish a profile
  2. Verify objects
  3. Set up roles
  4. Combine classes with roles
  5. Assign users to classes:
   DU-IT Banner Advancement (Jody Rieg), Finance (Russ Grunebach) ), Human Resources
  (Kathy Jaczesko), Admissions (Celeste Corsi), and Financial Aid (Jeremy Mayernik). Module
  Data Owners serving as DU-IT Banner Role Level Security Officers have prepared initial
  spreadsheets identifying user roles and classes.
   Identified user roles and classes have been aligned to LDAP User IDs. LDAP serves as
  system of record for identity management.
   Budget users have been identified by Rita Warfield serving as DU-IT Banner Finance
  Security Officer where appropriate fund and organization level security has been identified. This
  is implemented via FOMPROF for DU-IT Banner Finance users. This data is shared with the
  DU-IT Banner System Administrator to implement in the appropriate database instance.
   Access is then given to Single Sign On through DORI by Web Service Center team.
   Access to DU-IT Banner tables for shared data validation, active students and employees via
  objects - - forms, reports and processes - - have been submitted by data grids through the
  Finance, Advancement, Human Resources, Financial Aid, and Admissions CPTs. Registrar and
  Student Accounts ll be completed shortly.
  6. Review security violations - - DU-IT Banner System Administrator must review security
  violation and maintenance window reports and monitor violation table capacity. To avoid
  exceeding the table‟s maximum capacity, the DU-IT Banner System Administrator should
  occasionally truncate this table.

             b. Initial Authorization - - During LIVE DU-IT Operation



DRAFT                                  Page 10 of 53                        Data Standards
Manual
  To obtain access to any of the DU-IT Internet Native Banner modules, an Account Request
  Form/Access Request Form must be submitted to the DU-IT Banner Role Level Security
  Officers. The request must be approved and signed by the Director or Department supervisor
  prior to processing.

             c. Updates to Existing User ID

  Users are required to identify themselves to the DU-IT Banner Systems by supplying a User ID
  and password on the DORI Portal prompt.

  If an existing User ID needs to be modified to grant access for additional forms, the update must
  be approved, in writing, by the supervisor/ CPTs following the same procedure as initiating an
  account.

  Call the CTS Help Desk or send an electronic message to CTS Help Desk at Help@duq.edu with
  questions or comments regarding these procedures.

     C. Choosing Passwords

  Strong passwords, based on policy, have the following characteristics at Duquesne University:

        Are at least seven characters in length but not more than twenty.
        Passwords must meet lat least three of the following four criteria:
             o Contain English uppercase character/s
             o Contain English lowercase character/s
             o Contain Base 10 digit/s (i.e. 0 -9)
             o Contain one or more of these acceptable non-alphanumeric characters:
                      !&+/.
        Are not the user ID, user name or nickname in any form.
        Are not found in any language, slang, dialect, jargon, etc.
        Are not based on personal information, names of family, social security number, phone
         number, address, birth date, anniversary, pet name, etc.
        Passwords should never be written down or stored on-line. Try to create passwords that
         can be easily remembered. One way to do this is create a password based on a song title,
         affirmation, or other phrase.

  Poor, weak passwords have the following characteristics:

        The password contains less than six characters.
        The password is a word found in a dictionary (English or foreign)
        The password is a common usage word such as:




DRAFT                                  Page 11 of 53                         Data Standards
Manual
         a. Names of family, pets, friends, co-workers, fantasy characters, etc.

         b. Computer terms and names, commands, sites, companies, hardware, software.

         c. The words "Duquesne" or any deviation.

         d. Birthdays and other personal information such as addresses and phone numbers.

         e. Word or number patterns like aaabbb, qwerty, zyxwvuts, 123321, etc.

         f. Any of the above spelled backwards.

         g. Any of the above preceded or followed by a digit (e.g., secret1, 1secret)

  Additional guidelines can be found at www.cts.duq.edu

     D. Changing Passwords

  For security purposes, passwords should be changed frequently. Duquesne will require a
  password change every 120 days. Passwords will need to be changed for each applicable DU-IT
  database instance (e.g., PROD) and managed through the DORI password manager system.

            a. How to Change the Password in DORI

         1. Password Initialization / Retrieval
            This application exists for users who do not know their new DORI credentials to set
            them up for the first time. The account initialization process works as follows:

                User clicks on password initialization link
                User is prompted for the following info:
                     o Username
                     o Birthday
                     o Permanent Zip
                     o Default Password (first,last,‟&‟,last 4 SS#)
                If user enters these items correctly, they are prompted to choose and answer 2 of
                5 secret questions (for password reset later if needed).
               User then selects a new password. Passwords are checked against the
                complexity standards currently detailed at before they are accepted and the
                account initialized.
               Once the user has initialized their account they are no longer able to run through
                the initialization process and must use another secured application for future
                password changes.

            This application also allows for users that have forgotten their passwords to reset
            them to the default value for a short time so that they may login to the password
            change application and supply a new password that adheres to complexity standards.


DRAFT                                  Page 12 of 53                         Data Standards
Manual
             To accomplish this, the user would click on the MultiPass Help link and perform the
             following steps:

                Click „MultiPass password‟
                Enter their username, birthday and permanent zipcode
                Password is reset to default value
                Answer their secret questions correctly
                Users are directed to logon to the password change application and change it
                 immediately.

         2. Initialized Password Changes

         The DORI Password manager application exists for users who have initialized their
         passwords to logon, view password information, and change their passwords. It also
         allows admin users (i.e. help desk staff) to look up users and reset their passwords if
         necessary.

             b. Changing the Password in Banner

         Banner password changes occur through the DORI Password manager system. Password
         complexity follows the same rules.

             c. Forgotten Passwords

         As previously mentioned, users will be requested to change their passwords periodically.
         When users forget their passwords, a “request for password reset” must come from the
         user.

      E. Reporting Violations:

  Any suspected violations of these policies, or unauthorized access to computing resources, or
  any other condition which could compromise the security of DU-IT Banner data or other
  Duquesne University computing resources must be reported to Director of Systems and
  Operations or Human Resources.

      F. Remedies for Non Compliance:

  As suggested in TAP 27, failure to adhere to these guidelines can result in the suspension of
  computing privileges, charges being brought according to the appropriate University policy
  and/or procedures based on one‟s status in the University, and prosecution under state and
  federal laws, where applicable.

      G. Other Useful Policies and Procedures:
     CTS Computer Use Policy and Computer Use Violations
     Family Education Rights and Privacy Act (FERPA-Buckley Amendment)
     Administrative Procedures Manual

DRAFT                                   Page 13 of 53                         Data Standards
Manual
     TAP 26 – Computing Ethics and Guidelines
     Account Tracking and Access Termination
     Security Awareness Program
     Password Policies
     Secure Screen Savers & DU-IT Banner Logoff Policy
     Policy for identity verification when receiving Banner General Navigation and other end user
      training.

      H. Version Control:

      See Release Management Policy and Procedures




DRAFT                                  Page 14 of 53                        Data Standards
Manual
2. Common Matching

Introduction to General Person (SPAIDEN) and the use of Common Matching (GOAMTCH)

The General Person Identification Form (SPAIDEN) is used to capture biographic/demographic
information for all persons associated with Duquesne University. Persons can belong to any or all of
the installed Banner Modules (i.e. Student, Financial Aid, Finance, HR/Payroll). All persons created
in the Student module of Banner are initially entered into the database using this form. The
information maintained in this form is specific to the person and does not relate to the person's
involvement at Duquesne. Other areas of the Student module are dependent on the information
captured and maintained in this form. Any changes or additions to a person's
biographic/demographic information can be made in this form or the individual forms where the data
may also be maintained.

Common Matching is used to avoid duplicate record creation when entering a person or a non-
person record into the Banner system. Common matching uses a rules-based algorithm to check for
possible database matches before a new person or non-person record is created. Common Matching
is used for processing batch data loads and for online forms that are used to create new person or
non-person records (e.g., SPAIDEN). The Common Matching form (GOAMTCH) can be called
from the key block of person or non-person data entry forms when generating an ID or entering an
ID that does not exist in Banner.

Using Common Matching:

You may execute the Common Matching process at any time during data entry of person
information by calling the Common Matching Entry form (GOAMTCH). If a matching record
exists, you have the option of enhancing existing data by inserting new information. Existing data
will not be overwritten.

Matching status
There are three possible results of running the Common Matching algorithm:
• New
• Match
• Potential Match

New: If no records are found that match the rules, a status of New is returned. You may then create a
new person or non-person record or exit and return to the calling form.

Match: If one and only one exact record matches all of the rules, a status of Match is returned and
the Match tab will be highlighted. Data for the matched ID will be returned for review. (This
functionality may be a “bug” as the exact match form will not display. All matches must be chosen
from the potential match area).




DRAFT                                    Page 15 of 53                         Data Standards
Manual
Potential Match: A status of Potential Match occurs if some fields match but not all, or if multiple
records match exactly. For example, a potential match would occur if first name and last name match
but DOB does not match. When potential matches exist, the Potential Matches tab will be
highlighted with the number of potential matches. The identified potential match records will be
listed for review.




Common Matching Summary

IF the result is…THEN follow these steps*

Result                        Steps
NEW                           Click the Create New icon to create a new PIDM (ID).
                              Result: A new Banner PIDM is created; data from the
                              top block is inserted into the SPAIDEN form.
MATCH                         To match the person in the top half of the form to the
                              person found by the match, choose either: Select ID to
                              select the record and carry it back to the key block of
                              SPAIDEN. Update ID to update the record with
                              additional data from the top block.
POTENTIAL MATCH               Click the Potential Match tab. Review the data for each
                              potential match. Click the Details button to review data
                              about the potential match on other forms (defined on
                              GORCMSC). Determine if person is new or a match and
                              select the appropriate icon (Create New or Select ID or
                              Update ID).




DRAFT                                   Page 16 of 53                        Data Standards
Manual
3. General Person and Non-Person Maintenance and View Processes
General Person and Non-Person view processes include:
    Retrieval of information prior to maintenance;
    Retrieval of information to gain access to related information (e.g., student schedules, etc.);
    Retrieval of information associated with inquiry functions within Banner Systems and
       Modules; and
    Retrieval of information performed by ancillary tools, such as Cognos 8 Business
       Intelligence, PL*SQL programs, and other “tools.”

Our business processes are supported through the execution of Internet Native Banner (INB) forms,
processes and reports and Self-Service Banner (SSB) web pages. Our challenge is to ensure the
proper controls are in place to address threats to General Person, specifically attacks on availability,
integrity and confidentiality.1

General Person INB processes are batch processing functions that access General Person
information. These processing functions are invoked via INB forms or scheduled via Global ECS, a
processing job scheduling tool. General Person reports may be processed via INB, Cognos 8
Business Intelligence or other “tools” to present General Person information.

SSB functionality is provided to the following self-service user constituents (See Exhibit A under
separate cover) using the following SunGard HE classifications:
    Advancement Officers;
    Alumni and Friends;
    Students;
    Faculty and Advisors;
    Employees; and
    Finance organization.

Although we have multiple Points-of-Entry and do not have mutually exclusive and all inclusive
categories of General Person and Non-Person, we have identified Data Stewards of General Person
data for all Point-of-Entry, Maintenance and View processes.

General Person                   DU Unit      Data Steward
Prospects and Applicants         OUA          Celeste Corsi
Students                         Reg.         Kim Hoeritz
Employees                        HRM          Kathy Jaczesko
Alumni and Donors                ADV          Jody Rieg
1
  Availability – an attack on availability is when a General Person record is destroyed, rendered unavailable, or caused
to be unusable.
  Integrity – an attack on integrity occurs when an unauthorized entity gains access and tampers with a General Person
record. Another type of integrity attack occurs when an unauthorized entity inserts data values into the General Person
record or performs an unauthorized modification.
  Confidentiality – an attack on confidentiality is when an entity, such as a person, program, or computer, gains
unauthorized access to sensitive information.

DRAFT                                            Page 17 of 53                                 Data Standards
Manual
Non-Person Data Stewards are as follows:

General Non-Person DU Unit Data Steward
Vendors            UC      Debbie Novak
                           Linda Roos

Since certain vendors are individuals, it is anticipated that our vendor General Non-Person data
steward will be involved in certain General Person discussions to agree standards and participate in
Working Groups. Similarly, there are ADV Organizations where our ADV data steward will be
involved with certain General Non-Person discussions to agree standards and participate in Working
Groups.

General Person and Non-Person Maintenance Processes
Our challenge is to determine who is authorized to perform maintenance on what specific categories
of General Person for specific types of General Person information. Maintenance via SSB will be
evaluated in Phase 2 or subsequent phases.

Assuming a PIDM exists, it needs to be found before performing data maintenance. Our Data
Standards Manual needs to provide guidance on the use of Common Matching, Banner baseline
Forms (e.g., SOAIDEN, SOAIDNS, etc.) and other methods to perform the necessary lookup.
Forms, such as GUITINH, allow access to any PIDM. Particular attention needs to be paid to the
use of Quick Flows since they may “bundle” General Person forms. Our challenge is to ensure only
authorized access to General Person information using the “least privilege” policy.2

Identity fraud, FERPA and other regulations mandate Duquesne University to protect General
Person information. Banner security allows authorized personnel to maintain - - create, update, and
delete - - or query - - view - - General Person information. Only these permissions grant access to
General Person information. A separate Banner Role and Class will be established for General
Person forms.

Using Banner security we will establish Banner Role/Class categories in PROD that include only
General Person forms for respective maintenance or query permissions.

Identifying the Appropriate Data Steward to Perform Changes

Changes to identifying information can affect more than one Banner System/Module. Thus, the
appropriate Data Steward must be determined before making such changes to Banner General
Person records.

2
  Least privilege is a policy that limits both the system‟s users and processes to access only those resources necessary to
perform assigned functions. Ensuring least privilege requires identifying what each user‟s job is, outlining the minimum
set of privileges required to perform that job, and restricting the user to only those privileges on the system/network.
Users only get access to those resources necessary to do their job - no more and no less. By restricting access to only
those privileges necessary for performing job duties, access is denied to privileges that might be used to circumvent
security. In some organizations, this is also referred to as “need to know.”

DRAFT                                             Page 18 of 53                                 Data Standards
Manual
The appropriate Data Steward can be determined using the Banner System Identification
(GUASYST) form. When presented with a completed “Student, Employee, Alumni and Donor or
Vendor „Person‟ Change Request form or a “‟Non-Person‟ Vendor or Alumni and Donor Change
Request” form, authorized Banner users will enter the ID into the key block on GUASYST. The
current name associated with the ID will be presented. The next block of GUASYST will identify
the various roles the „person‟ or „non-person‟ may have. One or more of the following boxes under
one or more of the following Banner Systems will be checked to denote Banner System
Identification roles:
     STUDENT
              Recruiting
              Admissions
              Transfer Work
              General Student
              Registration
              Housing
              Faculty
     HUMAN RESOURCE
              Applicant
              Employee
              Beneficiary
              Cobra Person
     ADVANCEMENT
              Individual
              Organization
     FINANCIAL AID
              Applicant
     FINANCE
              Agency
              Bank
              Customer
              Employee
              Financial Manager
              Vendor
     Accounts Receivable
              Accounts Receivable

The check mark in a box denotes the presence of a row occurrence in a specific Banner table. For
instance, the presence of a data table supporting the SFAREGS form will cause the Registration box
to be checked for a „person.‟ This box will remain checked (unless the record occurrence is removed
from the database). Similarly, a check mark in any box will not disappear. Consequently, many
„person‟ or „non-person‟ records will have multiple boxes checked.

As identified by GUAINST, the „person‟ or „non-person‟ should be directed to submit a completed
Change Request form and original, required documentation to the appropriate Data Steward as
follows:

DRAFT                                   Page 19 of 53                        Data Standards
Manual
Students before enrollment:
   1. Undergraduate students before enrollment: Undergraduate students who have been
      admitted but have not yet registered will have Recruiting and/or Admissions role on
      “GUASYST.” Changes for these students should be made by the applicable Office of
      Undergraduate Admissions (OUA) or SLAPA and do not require separate
      documentation. If the student has any other role noted on “GUASYST”, the change
      should be made by the appropriate Data Steward and appropriate documentation is
      required.
   2. Graduate students before enrollment: Graduate students who have been admitted but
      have not yet registered will have Recruiting and/or Admissions role on “GUASYST.”
      Changes for these students should be made by the Office of Graduate Admissions (or
      Graduate School Office), SLAPA or the Law School and do not require separate
      documentation. If the student has any other role noted on GUASYST, the change should
      be made by the appropriate Data Steward and appropriate documentation is required.
   3. International Students before enrollment: International students who have been admitted
      but have not yet registered will have Recruiting and/or Admissions role on “GUASYST.”
      Changes for these students should be made by the Office of International Programs
      (OIP) and do not require separate documentation. If the student has any other role
      noted in “GUASYST”, the change should be made by the appropriate Data Steward and
      appropriate documentation is required.

Students after enrollment:
   4. All students and student employees after enrollment: Students who have enrolled in the
      University will have an Admissions and General Student role on “GUASYST.” These
      students could also have additional roles (e.g., Employee, Advancement Individual,
      Vendor, etc.) on “GUASYST.” The student role, however, takes precedence and changes
      for (except Law School) students are made by the Registrar‟s Office. Changes for
      Law School students are made by the Law School Registrar‟s Office. Appropriate
      documentation is required.

Non-student employees:
  5. Non-student employees: Non-student employees will have an employee role in
      “GUASYST.” These individuals may also have other roles (e.g., Advancement Individual,
      Financial Manager, Vendor, etc.) on “GUASYST.” The employee role, however, takes
      precedence and changes for these individuals are made by the Human Resource
      Management (HRM) Office. Appropriate documentation is required.

Vendors:
   6. “Person” vendors who have never been a student, friend and/or employee of the
      University: These individuals will only have a Vendor role on “GUASYST.” Changes for
      these individuals are made by University Controller Accounts Payable (UCAP). A
      valid revised W-9 form is required for documentation.
   7. “Non-person” vendors: “Non-person” vendors will have a vendor role in “GUASYST.”
      It is possible for a “non-person” to be an Advancement Organization. If so, UCAP must
      engage ADV to agree on who will make the change. If only a Vendor role, changes for

DRAFT                                 Page 20 of 53                      Data Standards
Manual
       these entities are made by University Controller Accounts Payable. A valid revised
       W-9 form is required for documentation.

Alumni and Donors:
   8. Alumni or Donors with no other role: When only the Advancement Individual or
      Organization role is presented on “GUASYST,” changes for these entities are made by
      Advancement Services (ADV). Appropriate documentation is required.

Persons and Non-Persons with multiple GUASYST roles:
   9. “Person” vendors who have previously been and/or currently are a student and/or
       employee of the University: These individuals will have multiple roles such as
       Admissions, General Student, Financial Aid Applicant, Advancement Individual and/or
       Employee in “GUASYST” that are in addition to their Banner vendor role.
       Representatives of the General Person Maintenance Working Group should agree on who
       will make these changes. Information changes for these individuals should be made by
       the Registrar‟s Office, Advancement Services, or the Human Resources Office.
       Appropriate documentation is required.
   10. Students and employees with multiple roles: Individuals may have multiple roles on
       “GUASYST” (General Student, Financial Aid Applicant, Advancement Individual,
       Employee, Vendor, and/or other roles). The person‟s student and/or employee role takes
       precedence over the Advancement or vendor role. Changes for these individuals can be
       made by either the Registrar‟s Office or Human Resource Management. Appropriate
       documentation is required.

Banner Forms for Completing and Identifying Information Change

As determined by the Data Steward, any one of the following Banner General Person forms can be
used to make identifying information changes:
    Students:                      “SPAIDEN”
    Employees:                     “PPAIDEN”
    Vendors:                       “FOAIDEN”
    Alumni and Donors:             “APAIDEN”

Before creating a new record for a „Person‟ or „Non-Person,‟ the user must conduct a thorough
search using multiple search engines to make sure that the „Person‟ or „Non-Person‟ has not already
been entered as a Banner General Person. This procedure will reduce the risk of entering a duplicate
PIDM record.

DO NOT CREATE A NEW STUDENT, EMPLOYEE, ADVANCEMENT or VENDOR
RECORD WHEN MAKING A LEGAL NAME, MARITAL STATUS, SSN and/or TIN
CHANGE.

Search by using GUIALTI (Alternate ID search) if the SS/EIN/TIN# of the „Person‟ or „Non-
Person‟ is available. If SS/EIN/TIN# is not available use the %IDEN form available to you
(SPAIDEN, PPAIDEN, FOAIDEN, APAIDEN). From the %IDEN form you would choose the
„Person‟ or „Non-Person‟ search where the user would enter the name using the wildcard (%) as

DRAFT                                    Page 21 of 53                        Data Standards
Manual
appropriate. As the last search engine, GOAMTCH is used to choose a „Person‟ or „Non-Person‟
matching source. Enter the full name according to the prescribed DU-IT Data Standards,
SS#/EIN/TIN, and the address using QAS. If the „Person‟ or „Non-Person‟ is not found and you
have exhausted contacts with other Data Stewards, a new PIDM can be generated.

Using the appropriate Banner General Person form, the authorized Banner user making the
identifying information change should enter the ID or complete a name search. Upon retrieval of
the correct student, employee, alumni, donor or vendor, the incorrect information should be
corrected by typing over it. The spelling of the name and/or the numbers in the SSN and/or TIN
should be verified. Once verification is complete and the correct information has been entered, the
record should be saved to the Banner System.

DO NOT CHANGE A LEGAL NAME, MARITAL STATUS, SSN and/or TIN RECORD
WITHOUT PROPER LEGAL, ORIGINAL DOCUMENTING PROOF

Changes to Legal Name, Marital Status, Social Security Number and/or Taxpayer
Identification Number


A. Change Process for “Person” and “Non-Person” Identifying Information

Changes required to correct initial input errors related to identifying information (name, marital
status, SSN and/or TIN) are based upon the original, correct documentation provided to the
University, and therefore, do not require additional documentation.

When adjustments to identifying information are required due to errors and/or changes to the
original documentation supplied to the University by „Person‟ Students, Employees, Advancement
Individuals and/or Vendors, the „Person‟s‟ Banner roles must first be identified using the Banner
form “GUASYST.” If the „Person‟ has only Recruiting and/or Admissions role in “GUASYST,”
the OUA, OGA (and Graduate Schools), SLAPA, Law School and Registrar‟s Office may make
the necessary changes to “SPAIDEN” without additional documentation.

If a „Person‟ has other roles identified in “GUASYST” (e.g., Registration, Employee,
Advancement Individual, Vendor, Financial Aid Applicant, etc.), valid documentation is required
to make changes to „Person‟ or „Non-Person‟ legal name, marital status, and/or SSN. A “Student,
Employee, Advancement Individual or Vendor „Person‟ Change Request” form must also be
completed. To make legal name or TIN changes to „Non-Person‟ Advancement Organizations or
Vendors, complete a “Vendor or Advancement Organization „Non-Person‟ Change Request” form,
along with a revised W-9 form.

The completed change form (TBD), along with original documentation, is then submitted to the
appropriate office as determined in the section titled Identifying the Appropriate Data Steward to
Perform Changes.

B. Acceptable documentation for changes to „Person‟ - - Student, Employee, Advancement
   Individual or Vendor - - Identifying Information
DRAFT                                     Page 22 of 53                         Data Standards
Manual
Documents supplied may be originals, copies or faxed copies. Acceptable documentation for
student or employee SSN changes is the:
             Social Security Card
             Documentation from Social Security Administration

Acceptable documentation for a student or employee legal name change includes the following
documents:
             Birth Certificate
             Social Security Card
             Marriage Certificate
             Passport
             Citizenship Papers
             Court Document

Acceptable documentation for a student or employee marital status change includes the following
documents:
             Marriage Certificate
             Court Document

C. Acceptable documentation for changes for „Person‟ Vendor Identifying Information

A “person” vendor is an individual using an SSN for identification purposes. Person “vendors”
include sole proprietorships, independent contractors, and employees and students receiving
expense reimbursement checks.

A revised W-9 form is acceptable documentation for a change to legal name, SSN and/or marital
status for a “person” vendor who is not currently and has not previously been a student and/or
employee at the University. University Controller Accounts Payable and/or Purchasing
personnel must check Banner “GUASYST” to determine if a “person” vendor is currently or has
been previously been a student, an employee, and/or an alumnus/donor.

„Person‟ vendors who have previously been or currently are students and/or employees must
provide the same documentation for name, SSN, and marital status changes as students or
employees as described above.

D. Acceptable documentation for changes for „Non-Person‟ Identifying Information

A “non-person” vendor is a corporation, partnership, and/or LLC that uses a TIN for identification
purposes. A revised W-9 form is acceptable documentation for a change to legal name and/or TIN
for a “non-person” Vendor.

General Person and Non-Person View Processes



DRAFT                                    Page 23 of 53                        Data Standards
Manual
General Person view processes include retrieval of information to gain access to related information
(e.g., student schedules, etc.) and retrieval of information associated with inquiry functions within
Banner Systems and Modules. This includes reports and self-service functions, too.

Users of General Person and Non-Person view processes must complete a Duquesne University
Confidentiality Agreement. Authorized users and processes will be granted Banner View privileges.

Proposal: Social Security Numbers will be masked and reveal only the last four digits. Similarly,
date of birth will mask the birth year. This is a subsequent phase task.

Users accessing General Person and Non-Person identifying information must honor the message
that denotes the “confidential” box was checked during Point-of-Entry processing. Identifying
information must not be intentionally or unintentionally disclosed to other parties.

The “confidential” box is triggered by the document used by Student Affairs where the student
completes a “Request Non-Release of Directory Information.”

General Person and Non-Person Point-of-Entry Processes
Point-of-Entry (origination of data) Processing

The purpose of this schedule is to present a proposed framework for categories of General Person
and Non-Person with no prior relationship with Duquesne University. Each category must align to a
single Duquesne University processing unit (DU Unit) which is accountable for ensuring the General
Person or Non-Person does not exist, generating (as applicable) a new General Person or Non-
Person identifier (PIDM), and entering applicable information. The objective of this exercise is to
define mutually exclusive and all inclusive categories of Point-of-Entry Processing.

                          Category                            Primary      Person     Non-      DU
                 (with no prior relationship)                  Form                  Person    Unit
Traditional Domestic Undergraduate Student Prospect          SPAIDEN         X                 OUA
Traditional Domestic Undergraduate Student Applicant         SPAIDEN         X                 OUA
Traditional Domestic Graduate Student Prospect               SPAIDEN         X                 OGA
Traditional Domestic Graduate Student Applicant              SPAIDEN         X                 OGA
Law School Student Prospect                                  SPAIDEN         X                 Law
Law School Student Applicant                                 SPAIDEN         X                 Law
Non-Traditional Domestic Undergraduate Student Prospect      SPAIDEN         X                SLAPA
Non-Traditional Domestic Undergraduate Student Applicant     SPAIDEN         X                SLAPA
Non-Traditional Domestic Graduate Student Prospect           SPAIDEN         X                SLAPA
Non-Traditional Domestic Graduate Student Applicant          SPAIDEN         X                SLAPA
International Student Prospect (UG and Grad)                 SPAIDEN         X                 OIP
International Student Applicant (UG and Grad)                SPAIDEN         X                 OIP
Ireland Institute                                            SPAIDEN         X                 OIP
Pittsburgh Council on Higher Education (PCHE)                SPAIDEN         X                 Reg.
High School Student                                          SPAIDEN         X                 Reg.
Employment Applicant, including current/prior student,         Prior         X
employee, vendor (third-party) individual, or advancement   Relationship

DRAFT                                     Page 24 of 53                          Data Standards
Manual
individual
Employment Applicant with no prior relationship to DU                  PPAIDEN                X                    HRM
Employee, Spouse and/or Dependents with no prior                       PPAIDEN                X                    HRM
relationship to DU (including part-time faculty) and no
Employment Applicant record
Vendor (Third-Party) Individual                                         FOAIDEN               X                    UC
Vendor (Third-Party) Organization                                       FOAIDEN                          X         UC
Vendor Reimbursement (to employment applicant,                            Prior               X          X
employee, student, vendor, advancement individual, or                  Relationship
advancement organization)
Lender Institution (source of funds)                                    SPAIDEN                         X          FAO
                          Category                                       Primary            Person     Non-        DU
                (with no prior relationship)                              Form                        Person       Unit
Research Agency (source of funds)                                       FOAIDEN                         X           OR
Advancement Individual, including current/prior student,                  Prior               X
employee, or vendor (third-party) individual.                          Relationship
Advancement (Third-Party) Individual                                    APAIDEN               X                    ADV
Advancement Organization, including vendor (third-party)                  Prior                          X
organization and Lender Institution                                    Relationship
Advancement Organization                                                APAIDEN                          X         ADV


General Person Point-of-Entry Processes

General          ID    Alternate   Address –   Address –   Telephone   Biographical      E-mail      Emergency
                          ID        U.S.A.      Foreign    Inform‟n.   Information    Information     Contact
Person Data
by Category:
Traditional     OU    OUA          OUA         OUA         OUA         OUA            OUA
                A
Domestic
Undergraduate
Student
Prospect
Traditional     OU    OUA          OUA         OUA         OUA         OUA            OUA
                A
Domestic
Undergraduate
Student
Applicant
Traditional     OG    OGA          OGA         OGA         OGA         OGA            OGA
                A
Domestic
Graduate
Student
Prospect
Traditional     OG    OGA          OGA         OGA         OGA         OGA            OGA
                A
Domestic
Graduate
Student
Applicant
Law School      Law   Law          Law         Law         Law         Law            Law
Student
Prospect

DRAFT                                          Page 25 of 53                                      Data Standards
Manual
Law School      Law   Law     Law     Law     Law     Law     Law
Student
Applicant
Non-            SLA   SLAPA   SLAPA   SLAPA   SLAPA   SLAPA   SLAPA
                PA
Traditional
Domestic
Undergraduate
Student
Prospect
Non-            SLA   SLAPA   SLAPA   SLAPA   SLAPA   SLAPA   SLAPA
                PA
Traditional
Domestic
Undergraduate
Student
Applicant
Non-            SLA   SLAPA   SLAPA   SLAPA   SLAPA   SLAPA   SLAPA
                PA
Traditional
Domestic
Graduate
Student
Prospect




DRAFT                                 Page 26 of 53                   Data Standards
Manual
General            ID    Alternate   Address –     Address –   Telephone   Biographical      E-mail     Emergency
                            ID        U.S.A.        Foreign    Inform‟n.   Information    Information    Contact
Person Data
by Category:
Non-              SLA    SLAPA       SLAPA         SLAPA       SLAPA       SLAPA          SLAPA
                  PA
Traditional
Domestic
Graduate
Student
Applicant
International     OIP    OIP         OIP           OIP         OIP         OIP            OIP
Student
Prospect
International     OIP    OIP         OIP           OIP         OIP         OIP            OIP
Student
Applicant
Ireland Inst.     OIP    OIP         OIP           OIP         OIP         OIP            OIP
PCHE Student      Reg.   Reg.        Reg.          Reg.        Reg.        Reg.           Reg.
High School       Reg.   Reg.        Reg.          Reg.        Reg.        Reg.           Reg.
Student
Employment
Applicant,
including
current/prior
student,
employee,                                        Prior relationship with DU
vendor (third-
party)
individual, or
advancement
individual)
Employment        HR     HRM         HRM           HRM         HRM         HRM            HRM           HRM
                  M
Applicant with
no prior
relationship to
DU
Employee,         HR     HRM         HRM           HRM         HRM         HRM            HRM           HRM
                  M
Spouse and/or
Dependents
with no prior
relationship to
DU (including
part-time
faculty) and no
Employment
Applicant
record
Vendor            UC     UC          UC            UC
(Third-Party)
Individual

DRAFT                                               Page 27 of 53                                   Data Standards
Manual
General          ID   Alternate   Address –    Address –   Telephone   Biographical      E-mail     Emergency
                         ID        U.S.A.       Foreign    Inform‟n.   Information    Information    Contact
Person Data
by Category:
Vendor           UC   UC          UC           UC
(Third-Party)
Organization
Vendor
Reimbursem‟t.
(to
employment
applicant,
employee,                                     Prior relationship with DU
student,
vendor,
advancement
individual, or
advancement
organization)
?Lender
Institution
(source of
funds)
Research         OR   OR          OR           OR          OR          OR
Agency
(source of
funds)
Advancement
Individual,
including
current/prior
student,                                      Prior relationship with DU
employee, or
vendor (third-
party)
individual.
Advancement      AS   AS          AS           AS          AS          AS             AS
(Third-Party)
Individual
Advancement
Organization,
including
vendor (third-                                Prior relationship with DU
party)
organization
and Lender
Institution
Advancement      AS   AS          AS           AS          AS          AS             AS
Organization




DRAFT                                          Page 28 of 53                                    Data Standards
Manual
      General Person and Non-Person (GP) Point-of-Entry (Data Origination) Stewards

      DU Unit                        Description                    Data Origination Steward   GP Type
      ADV       Advancement Services                                Jody Rieg                  Both
      FAO       Financial Aid Office                                Jeremy Mayernik            Non-
      HRM       Human Resource Management                           Kathy Jaczesko             Person
      Law       School of Law                                       Gloria Malie               Person
      OGA       Office of Graduate Admissions for 8 Schools         Scott Rhodes               Person
      OIP       Office of International Programs                    Joe DeCrosta               Person
      OR        Office of Research                                  Marianne Volk              Non-
      OUA       Office of Undergraduate Admissions                  Celeste Corsi              Person
      Reg.      Registrars Office                                   Kim Hoeritz                Person
      SLAPA     School of Leadership and Professional Advancement   Marianne Leister           Person
      UC        University Controller – Accounts Payable            Debbie Novak               Both



Multiple PIDM

      Duplication of the same record in Banner tables is a serious issue. This phenomenon is generally referred to
      as a “multiple PIDM.” A PIDM (Person Identification Master) is the internally assigned system number.
      An Oracle index is used to generate “one-up” numbers for PIDM creation (unless the PIDM identifies a
      Lender Institution where IDs of six digits are entered manually). SPRIDEN and related tables are joined by
      PIDM. Thus, the PIDM connects all the associated data. When there is more than one PIDM representing
      an individual, we have a serious problem.
      From a General Person perspective, the PIDM must uniquely represent a specific person that may be a
      prospect, applicant, student, employment applicant, employee, employee spouse, employee dependent,
      vendor individual, and/or advancement individual. From a General Non-Person perspective, the PIDM must
      uniquely represent a specific non-person that may be a vendor organization, lender institution, research
      agency, advancement organization, and/or other third party or corporate entity for billing purposes. To
      purge multiple PIDM‟s and contain multiple PIDM‟s that cannot be purged requires a planned and
      continuing coordinated effort across the DU-IT Project suite of Banner systems - - Advancement, Finance,
      Human Resources, Financial Aid, and Student.

      Each Data Steward has assigned a representative to the Multiple PIDM Cleanup Working Group to be the
      key contact involved in multiple/duplicate PIDM issues.

                    Data Steward       Multiple PIDM Cleanup Working Group
                    Celeste Corsi      Linda Roeder
                    Kim Hoeritz        JoAnne Hrehocik
                    Kathy Jaczesko     Kathy Jaczesko
                    Jody Rieg          Natalie Foxwell
                    Debbie Novak       Debbie Novak

      When multiple PIDM records cannot be purged from the database they will be contained so further use of
      the unusable record will be severely limited.



      DRAFT                                        Page 29 of 53                           Data Standards
      Manual
Duplicated records appearing more than once under different PIDM‟s can occur in a variety of ways. The
following activities can result in the creation of duplicate PIDM‟s:
1.        Errors made by end users when performing Point-of-Entry processing of “person” information into the
          Internet Native Banner (INB) systems via SPAIDEN, FOAIDEN, APAIDEN or PPAIDEN and related
          forms. This occurs when the result sets from Common Matching are overlooked or misinterpreted. It is
          critical that we perform due diligence including, as needed, the engagement of other Data Stewards
          before assuming the “person” we are entering has no prior relationship with Duquesne University.
2.        Errors made by student applicants (or other end users) using Self-Service Banner (SSB) functions (or
          Web Entry).

3.        Data interfaces that feed data values to Banner database, such as loading the SAT/ACT tapes for
          student, loading prospects, etc.

4.        Interim General Person data load scripts that keep Banner database in synchronization with Datatel until
          all major modules have been converted, as well as mock (or trial) conversions.



Working Group Procedures
Potential multiple PIDM records are to be identified on a nightly basis by running a series of scripts against
key Banner tables. A “Multiple PIDM” Report of potential duplicated PIDM records, sorted by last name,
then by first name will be created. This “Multiple PIDM” Report will be distributed electronically to the
Multiple PIDM Cleanup Team by posting it to the Data Standards shared site.

Open Action Requests:
    Ryan Sanders is developing this nightly process.
    Determine the shared site for the nightly result set.

Members of the Multiple PIDM Cleanup Working Group then analyze the “Multiple PIDM” Report to
determine which PIDM to maintain and which PIDM to eliminate using the following procedures:

     1.     The Banner Roles (admissions, general student, registration, vendor, financial aid applicant,
            employee, benefactor, etc.) assigned to each PIDM are determined using the Banner form
            “GUASYST.”

     2.     In most cases PIDM‟s with the roles of registered student, financial aid, accounts receivable,
            benefactor and/or employee are more difficult to reclassify than admissions or vendor Roles. PIDM‟s
            with registered student, financial aid, accounts receivable, benefactor and/or employee roles will
            generally have precedence over PIDM‟s with only prospect, admissions or vendor roles.

     3.     As needed, DU-IT Project Banner System Core Process Team (CPT) Leads and Module Owners must
            be involved to resolve multiple PIDM entries before further use of the duplicate record(s) prohibits
            them from being purged from the system.

Within two business days, the Multiple PIDM Cleanup Working Group should reach a disposition. The
next action may require manual intervention (e.g., delete information from one PIDM and add the
information to the “right” PIDM). Once a multiple PIDM is identified for elimination and purging (if
possible), the incorrect PIDM will be restricted from further use by the following procedures:



DRAFT                                              Page 30 of 53                            Data Standards
Manual
 1.   Append the phrase “- - Do Not Use" at the end of the last name in the Last Name field for the PIDM
      that should no longer be used. This change should be made using the appropriate SPAIDEN,
      FOAIDEN, APAIDEN or PPAIDEN form. The idea is to alert end users that they must not use this
      record because it is a duplicate and will be purged from the system.

 2.   Place a Hold on the duplicate General Person PIDM record using the “SOAHOLD” form for
      “students.” This prevents further transactions from occurring against the duplicate PIDM record.
      Holds do not apply to other “persons.”

 3.   Purge the identified multiple PIDM record. This action is performed by an Information Technology
      (IT) Database Administrator (DBA) after being directed to do so by the Multiple PIDM Cleanup
      Team. A record of this activity will be maintained by the IT DBA.

 4.   For situations where there are too many records related to the incorrect PIDM, the incorrect PIDM
      cannot be eliminated without risk to overall data integrity. In these cases, this specific problem should
      be described as a comment using the “SPACMNT” form. When using comments, the text should be
      initialed and dated. Thus, Duquesne University will rely on steps 1 and 2 to contain the incorrect
      PIDM when the record cannot be deleted (or removed).




DRAFT                                         Page 31 of 53                             Data Standards
Manual
4. Current Identification (Names)
The University considers the current name in Banner as a person‟s legal name. A person‟s
legal name appears on official documents such as a birth certificate, court order, social security
card, marriage license, driver‟s license, passport and/or citizenship papers.

The Office of Admissions, , Registrar, and Human Resources consider the name originally
reported on a “Student Application for Admission” to the University as the legal name.

Names for persons and non-persons should have a customer friendly appearance. The objective is
to enter names and addresses with both upper- and lower-case letters so that when a name is
printed on correspondence, it looks contemporary and professional. Name formats have also been
developed to meet United States Postal regulations.

It is recommended that offices that collect person names on applications, or any other types of
forms, designate separate fields on the form for that person to indicate first name, middle name,
last name, and preferred first name (not required). This will facilitate correct entry into the
respective fields in Banner.

Before creating an entity (“person” or “non-person”) in the Banner System, a thorough
name and ID search must be performed to ensure the entity does not already exist in Banner
and to avoid the creation of a multiple PIDM. Use the Banner form “GOAMTCH” to search
for an existing record. See Section 2 on Common Matching.

A. “Person” and “Non-Person” DU-IT Banner Numbers

   a. Person ID

   DU-IT Banner Numbers will be used for all person ID‟s.
   Banner will supply a new DU-IT Banner Number for each newly created person.

   b. Non-Person ID

   DU-IT Banner Numbers will be used for all non-person ID‟s.
   Banner will supply a new DU-IT Banner Number for each newly created non-person.

   c. Changes to DU-IT Banner Numbers

   It is vitally important to maintain the integrity of PIDM‟s and their relationship to DU-IT
   Banner Numbers. DU-IT Banner Numbers, therefore, are only cancelled when duplicate
   numbers are assigned. Only in the rarest of circumstances will a student or employee be
   manually assigned a different DU-IT Banner Number other than the one automatically
   assigned by the Banner System. Requests for such changes may be made by students through
   the Registrar‟s Office and by employees through the Human Resources office.

B. Name Types

DRAFT                                     Page 32 of 53                         Data Standards
Manual
   A person or non-person‟s current name is the legal name and does not require a separate name
   type. Previous legal or other non-legal names do require a separate name type. These name
   types are identified on the “GTVNTYP” validation table as:

Name Types:

Code     Description
CSRT     Corporate Sort Name
FRMR     Former Name
LEGL     Legal Name
MAID     Maiden Name
MAIL     General Mailing Name
NICK     Nickname
PAYC     Payroll Check Name
PREF     Preferred Name
RADM     Research Administration Name


C. Last, First, and Middle Names

   The last, first, and middle names should be entered exactly as the person has indicated. If given
   the full middle name, enter the full middle name. DO NOT change a full name to an initial.
   Always use normal upper- and lower-case letters for names. DO NOT enter leading spaces in
   any fields.

   a. Name Case

   If a person has written all upper-case letters, convert the name to normal upper- and lower-case
   letters. If the person‟s name starts with a lower-case letter, enter the first letter in lower case.

       Example: duBois

   For externally obtained data feeds, names will be converted into an upper- and lower-case
   format based upon these rules.

   b. Name Initials, Abbreviations, and Symbols

   Use periods after initials or abbreviations.

          Pamela A. Humphrey
          Enter as: First Name= Pamela / Middle Name= A. / Last Name= Humphrey

          Leslie M.F. Donner
          Enter as: First Name= Leslie / Middle Name= M.F. / Last Name= Donner


DRAFT                                     Page 33 of 53                          Data Standards
Manual
         James St. Martin
         Enter as: First Name= James / Middle Name= blank / Last Name = St. Martin

         D. Gary Smith
         Enter as: First Name= D. Gary / Middle Name= blank / Last Name= Smith

  The ampersand (&) should never be used in place of “and.”

         The percent symbol (%), the pound sign (#) and double quotations should never be
         used.

  c. Multiple Names

  In cases where a single character is designated as the first name followed by a full middle
  name, place the single character and the middle name in the first name field.

         W. Mark Jones
            Enter as: First Name= W. Mark / Middle Name= blank / Last Name= Jones

         If it is later learned that the “W” stands for William, the name should be changed in
         Banner to:
              First Name= William / Middle Name= Mark / Last Name= Jones

         If a person has more than two given names, and has not specified which are considered
         first vs. middle name(s), enter the first two names into the first name field and any other
         names into the middle name field.

             Abby Marie Susan Smith
             Enter as: First Name= Abby Marie / Middle Name= Susan / Last Name=Smith

             Billy Joe Daryl Thomas Miller
             Enter as: First Name= Billy Joe / Middle Name= Daryl Thomas / Last Name=
             Miller

         Upon request, it is acceptable to enter two names in the first name field.
         Abby Marie Smith
            Enter as: First Name= Abby Marie / Middle Name= blank / Last Name= Smith

  d. Multipart Names

  Maintain spaces in last names (one space maximum) exactly as reported by the person.

             Examples:
             Van Buren      Van der Burg Vander Burg

  e. Long Names

DRAFT                                   Page 34 of 53                         Data Standards
Manual
   If a person‟s first, middle, or last name is longer than the field allows in Banner, enter as much
   possible into the field. The rest should be truncated.

   f. Persons with One Name

   It is common in some countries for persons to just have one name (not a first, middle, and last
   name). If that is the case, enter the person‟s name into the last name field and enter an asterisk
   (*) in the first name field.

   g. Punctuation

   Use hyphens, apostrophes or dashes exactly as the person indicates in writing. Use periods in
   any name field. Do not add punctuation where there is none. In the following examples, any
   could be correct:

               O‟Donnell     Odonnell
               Dell‟Acqua DellAcqua            Dellacqua
               Jones-Smith
               Al-Hassan     AlHassan          al-Hassan       alHassan                 al Hassan
               St. Denis     StDenis           St-Denis        SainteDenis              Saint-Denis
                      Saint Denis

D. Prefixes and Suffixes

Prefix and Suffix fields are only used if the person indicates a prefix or suffix.

Salutations (such as Dr., Rev., etc.) are considered prefixes and if indicated by the person should
be entered in the prefix field on general person forms. Prefixes will be entered in normal upper-
and lower-case.
Professional status indicators (such as M.D., Ph.D., DVN, Esq., etc) and generational indicators
(such as Jr., Sr., II, IV, etc.) are considered suffixes and if indicated by the person should be
entered in the suffix field on the general person forms.

Include punctuation with a prefix or suffix.

   Dr.         M.D.             Ph.D.          Jr.

   DO NOT enter prefixes or suffixes in the name fields (first, last, middle, preferred) of the
   current identification block on the Banner IDEN forms.

   See appendix C.1 for a list of Prefix abbreviations.
   See appendix C.2 for a list of Suffix abbreviations.

E. Preferred First Name


DRAFT                                      Page 35 of 53                             Data Standards
Manual
The preferred first name field is used for variations to the legal name. The use of the preferred first
name field is optional in Banner and is for „informational use‟ only. The preferred first name field
is not used in Banner reports supplied with the system. The information provided by this field,
however, is available for use on any reports or letters generated and maintained by the University.
   Example:
       Current Name:                   James Knight
        Preferred First Name:          Jack

         Current Name:                 D. Mark Williams
         Preferred First Name:         Mark

F. Full Legal Name

The current name field in Banner is considered the legal name (See Section 3.A.1.). The full legal
name field is, therefore, NOT used or maintained by the University.

G. Non-Person Names

All non-person name information is typed in normal upper- and lower-case format (i.e. not all
upper- or lower-case). All words should be spelled out if space allows, except the business suffix
(Corp., Inc., Co., Ltd.) unless it is part of the primary name. Use U.S. Postal Service standard
business word abbreviations to accommodate space constraints. If an article (a, an, or the) is used
as an adjective within the full legal name of a non-person entry, it should be included when
entering the name in Banner. If a non-person name begins with the word “The”, it should be
included when entering the name in Banner (e.g. The Home Depot).

Do not space between initials. Acronyms should be used only if the full name of the vendor is
unknown. Acronyms should be entered as alternate names.

Do not use, commas, apostrophes, or special characters. Use “and” in place of an ampersand (&)
and a space in place of a hyphen (-) or slash (/).
       Example:
       ABC Trucking Corp.                     First National Bank Inc.
       U.S. Department of Defense             The Earle
       University of Portland                 Karens Kitchen
       J.F. Kennedy Company                   AT and T
       Hewlett Packard

H. Validation Tables

See the “Validation Table Dictionary” for additional information regarding the following
validation tables:

FTVVTYP – Vendor Type Codes (Required).
GTVNTYP – Name Type Codes (Required only for previous and non-legal names).

DRAFT                                      Page 36 of 53                          Data Standards
Manual
I. Summary

        Use the Banner form “GOAMTCH” to search for existing records and prevent
         duplicates.
        Banner will automatically generate a DU-IT Banner Number for all entities.
        Use standard upper- and lower-case letters for names.
        Do not use special characters in names (ex. &, %, #, etc.). Use periods for initials or
         abbreviations.
        Enter prefixes and/or suffixes if provided using standard abbreviations.
        Preferred first name is an optional field that can be populated with a name other than
         the current legal name. The current legal name, however, must be also be provided.
        Full legal name field is not used at the University.




DRAFT                                  Page 37 of 53                          Data Standards
Manual
5. Alternate Identification
A. General

For the alternate identification block, follow the same standards as shown in Section 3 (Current
Identification).

With the exception of corrections made due to data entry errors, it is the University‟s policy to
maintain previous information in Banner. Forms used by some University offices ask for a
person‟s previous name or names (for example, admission applicants). The earliest name should be
entered first.

Example:

       Name:                  Lee Livingstone
       Previous Name:         Lee Stanley

Enter previous name (Lee Stanley) and save.
Enter current name (Lee Livingstone) and save.
Previous name will appear in the alternate identification block.

Should something be added here? See what was deleted from NC information at right.

B. Name Type

   Name type is required in the alternate identification block (see Section 3.A.3.).

C. Change Type
   Change type shows whether the alternate record is for a previous/alternate name or a
   previous/alternate ID.

D. Validation Tables

   See the “Validation Table Dictionary” for additional information regarding validation table:
   GTVNTYP – Name Type Codes.




DRAFT                                     Page 38 of 53                         Data Standards
Manual
6. Address Information
University-wide conventions are critical for shared data such as addresses. For example, units with
marketing responsibility (such as Advancement and Admissions) must be able to produce
individualized correspondence conforming to formal addressing rules. Units such as Student
Accounts, Financial Aid and Accounts Payable may have less stringent formatting requirements,
but should still follow the standards set forth here. Advancement Services has personalized
requirements.
The University has selected QAS Address Validation software to help ensure adherence to U.S.
Postal Service guidelines during address data entry and maintenance via INB forms and processes
and SSB functions. However, the Data Standards Team has utilized the following sources to
determine the standards to be utilized in the University‟s DU-IT Suite of Systems:
     Banner System requirements
     Accepted standards for formal communications
     Federal information processing standards
     International address requirements
     U.S. Postal Service guidelines
The Standards outlined in this manual are authoritative for the Banner System AND for all
University Systems that interface with the University‟s Banner System.
All information should be entered into the Banner System using normal upper- and lower-case
format without punctuation. U.S. Postal standards, however, prefer mailing addresses to be in all
upper-case and international postal standard require upper-case. To accommodate these needs,
Banner data can be revised as needed to all upper-case when necessary using the pop-selection
process.

Although our conventions for address suffixes use upper and lower case letters without
punctuation, Advancement Services prefer addresses with punctuation. This exception is
authorized for the roles of Individual and Organization on the Banner System Identification
(GUASYST) form.


All addresses must meet U.S. Postal Service addressing requirements. According to the U.S. Postal
Service postal addressing standards, “A standardized address is one that is fully spelled out,
abbreviated by using the Postal Service standard abbreviations…and uses the proper format
for the address style.”
www.usps.com/publications/pubs/welcome.htm
These guidelines are designed to convey the minimum standard requirements in order to enhance the
processing and delivery of mail, reduce instances of undeliverable mail, and position the University to
obtain the most advantageous postal rates.

A. Address Type

The Banner System standardized list of address types is based on address purposes, rather than University
department

DRAFT                                        Page 39 of 53                            Data Standards
Manual
Address     Address         Applies to:                  Prospect/      Student   Employee    Vendor    Other
Type        Description                                  Applicant                                      ADV
AP          A/P Check       Vendor, Employment               N/A          UC         UC         UC       UC
                            Applicants
B2          Business        Secondary Business               N/A          N/A        N/A       N/A      ADV
            Address 2       Address (ADV)
B3          Business        Tertiary Business Address        N/A          N/A        N/A       N/A      ADV
            Address 3       – Corporate Headquarters,
                            Subsidiary, Matching Gift
                            (ADV)
BU          Business        Primary Business Address         N/A          N/A        N/A        UC      ADV
                            used by Student Accounts
                            for Third-party and
                            Corporate billing, as well
                            as ADV
CA          Campus          Student, Employee                N/A         Reg        HRM        N/A       N/A
CK          Check           Student, Employee                N/A         HRM        HRM        N/A       N/A
            (Payroll)
FO          Foreign         For SEVIS purposes               OIP          OIP       N/A        N/A      N/A
HO          Home            Permanent                       OUA,          Reg       HRM        UC       ADV
                                                            OGA,
                                                            LAW,
                                                           SLAPA,
                                                             OIP
LC          Local           Students living off-campus       N/A          Reg        N/A       N/A      N/A
MA          Mailing         System required for             OUA,          Reg        N/A       N/A      ADV
                            Advancement and Student         OGA,
                            Loading Processes
                                                            LAW,
                                                           SLAPA,
                                                             OIP
P2          Parent          Student (case of living          N/A          Reg        N/A       N/A       N/A
            Address 2       separately)
PA          Parent          Student                          N/A          Reg        N/A       N/A       N/A
            Address
PO          Purchase        Vendor                           N/A          N/A        N/A        UC       N/A
            Order
RA          Research        Vendor                           N/A          N/A        N/A        OR       N/A
            Accounting
SE          Seasonal        Used by ADV                      N/A          N/A        N/A       N/A      ADV



     If avoidable, identical addresses should not be keyed into different address types. For example, if a
     student‟s mailing address (HO) is identical to his/her permanent parent address (PA), the address needs
     to be entered only into the mailing address (HO) type. Exceptions may be made for addresses used for
     purchase requisitions and purchase orders. The BU address type is the primary address for businesses,
     but may be duplicated for “PO” address type use.

DRAFT                                          Page 40 of 53                          Data Standards
Manual
  Each Banner application (e.g. recruitment mail, billing grades) will look for a valid address in a
  prescribed sequence. For example, the billing routine might look for addresses in this order: BI and then
  MA.




DRAFT                                      Page 41 of 53                            Data Standards
Manual
B. Address Data Stewards

       There are two System Required Address Types:
            1. BI is “Billing Address/AR Address” that will be used by Student Accounts for Third
                Party and Corporate billing addresses
            2. XX is “Reserved for TGRFEED Use Only”
       The following Address Types can not be deleted because there are records that should be
        investigated for “clean up” that use these codes:
            1. EM is “Emergency Contact”
            2. HQ is “Corporate Headquarter Address” typically used by Purchasing
            3. PR is “Permanent” address
       Unless a correction is necessary for an initial data entry error, prior addresses should not be
        changed or deleted without authorization.
       Address information can be changed by the Data Stewards identified on the chart.
       When there is more than one Data Steward identified on a row of the chart, please engage
        the other Data Stewards before making a change.

        Example: A department submits a request for reimbursement identifying a name, address
        and amount to Accounts Payable of the University Controller.
            1. A Banner system user in Accounts Payable will search on the system to determine
               whether the name for reimbursement has a prior relationship to Duquesne University,
               a PIDM. Since we only have name and address from the reimbursement request, we
               have limited criteria (without social security number or other identifying
               information) to perform a more accurate search. Further, the address on the request
               may not match the address associated with the name on the PIDM.
            2. From the list of possible matches, the user should view GUASYST to determine
               roles of each possible match.
                    When the role is only “Vendor,” Accounts Payable can update the address.
                    When there are multiple roles, a representative from Accounts Payable must
                       engage Data Stewards for other roles (or the Multiple PIDM Working Group)
                       to determine how to proceed (e.g., who will change the Home/Permanent
                       Address, use of Accounts Payable Check Address, etc.).


C. From/To Dates

    When adding a subsequent address of the same address type, the prior address should be end dated, the
    inactive box checked, and the new address added.

D. Sequence Number

    The sequence number field is automatically populated by Banner.

E. Street Lines 1, 2, and 3

    The main components of a delivery address are:
     Address number including special characters, symbols and punctuation;

DRAFT                                       Page 42 of 53                           Data Standards
Manual
     Street name;
     Street suffix;
     Secondary unit designator;
     Compass directional.

  a. Special Characters, Symbols, and Punctuation

      Special characters should never be used in the street lines of an address unless it is part of the
      punctuation of an address number.

      Punctuation is normally limited to periods, slashes, and hyphens.
                       Periods:                                            39.2 Rd
                       Slashes (fractional addresses):                    101 ½ Main St
                       Hyphens (hyphenated addresses):                     289-01 Montgomery Ave

      Use periods after abbreviations.

      Never use the pound sign (#) or the percent symbol (%) within an address because it causes a
      problem with the Banner printing function.

      The ampersand (&) should never be used in place of “and.”

      The designation for “in care of” should be abbreviated as “c/o” and should be entered on the first
      street address line.

  b. Campus Addresses

      Campus address type (CA) is used for University employees and students who live on campus.

      For employees, the purpose for this address type is to identify each employee‟s home department.
      The campus address for employees working for more than one area should be the primary or
      “home” department for the employee. This is the address to which the employee prefers to receive
      employment related correspondence.

      For University employees‟ campus addresses, street line 1 should provide the home department
      name. Street line 2 should provide the building and room number, and street line 3 should provide
      the campus box number.

              Name:                      Name of Employee
              Street Line 1:             University Department Name
              Street Line 2:             Building and Room Number
              Street Line 3:             Campus Box #
              City:                      Pittsburgh
              State:                     PA
              ZIP:                       15282

      For students living on campus in a Living Learning Center (Residence Hall) except Brottier Hall,
      student addresses should follow the recommended U.S. Postal Service address format shown
      below:
              Name:                      Name of Student

DRAFT                                       Page 43 of 53                              Data Standards
Manual
             Street Line 1:           Duquesne University
             Street Line 2:           1345 Vickroy St
             Street Line 3:           SMC # (box number)
             City:                    Pittsburgh
             State:                   PA
             ZIP:                     15219

     For students living on campus in Brottier Hall, student addresses should follow the recommended
     U.S. Postal Service address format shown below:

             Name:                    Name of Student
             Street Line 1:           Duquesne University
             Street Line 2:           700 Forbes Ave
             Street Line 3:           Apartment nnnn (a four-digit apartment number)
             City:                    Pittsburgh
             State:                   PA
             ZIP:                     15219


  c. Military Addresses

     Overseas military addresses must contain the APO (Army Post Office) or FPO (Fleet Post Office)
     designation along with a two-character state abbreviation of AE, AP or AA and the zip code.

     Enter the zip code in the zip code field. The APO or FPO code will default into the city field.
     The military state code (AA, AE or AP) will also default into the state field.

     Use AA for mail in the Americas other than Canada (340).
     Use AE for mail going to Europe, the Middle East, Africa and Canada (090-098).
     Use AP for mail destined to the Pacific (962-966).

             SSGT Mario Martian       Sgt .Cher Downey
             Unit 2050 Box 4190       PSC 802 Box 2625
             APO AP 96522-1215        APO AE 90777-0010

             Seaman Duane Reeves
             B Division
             USS North Dakota
             FPO AA 34093-2344

     All domestic military mail must have a regular street style address.

             Col. Margaret Henry Capt .Jack Harris
             Lowry Air Force Base 2314 Barracks St.
             8205 E. 6th Ave 405  Minot AFB ND 58705
             Denver CO 80234

  d. International Addresses




DRAFT                                     Page 44 of 53                             Data Standards
Manual
       Use the Nation Validation codes to enter nation or country codes (“STVNATN”). The authoritative
       source for the Banner System is the FIPS - Federal Information Processing Standard. These
       standard codes are provided by the United States Post Office and are periodically updated by
       Information Technology Services into the Banner System.
       http://www.upu.int/post_code/en/addressing.html

       Enter an international address into the address fields exactly as provided, including punctuation.
       Try to avoid commas, however, as much as possible. If space is available, do not abbreviate words
       that are spelled out. Enter postal codes as provided (enter spaces if indicated) in zipcode or postal
       field.

       Care should be taken to enter international addresses as closely as possible to the format required
       by that country. Enter country name from validation table in Nation field. The country name
       appears automatically when a nation code is entered. Enter the City in the City field. Three address
       lines are available. The County field should remain “blank.” Enter non-Canadian state/province in
       “address 3.” Enter Canadian Provinces in State or Province field.

                1501-203 Kunyoung Villa            (address 1)
                Dae-Wha Dong                       (address 2)
                Zi-San Ky Kyungido                 (city)
                South Korea                        (nation)
                In some cases, postal code and city should be inserted in the city field.

                Renee Duval
                27, rue Pasteur                    (address 1)
                14390 Cabourg                      (city)
                France                              (nation)
                In other cases, the city alone should appear in the city field.

                Walter C. Brown
                49 Featherstone Street             (address 1)
                London                             (city)
                EC1Y 8SY                           (zip)
                Great Britain                      (nation)

       See the “Validation Table Dictionary” for additional information regarding validation table:
       STVNATN – Nation Codes.

F. City

   Banner is configured to automatically enter the city name when a zip code is entered (“GTVZIPC”).
   This is the preferred method of entering the city name. If more than one city is listed for the zip
   code entered, the correct city should be selected from the drop-down list. If the city does not appear on
   the list and the zip code has been verified to be correct, the information for the city may be entered by
   typing the correct city in the city field. If the preferred name that defaults is not correct, it is acceptable
   to change the city to the actual city name. If it is necessary to manually type in the city name, use
   normal upper- and lower-case format and spell out the name in its entirety. Do not abbreviate.

                West Stockbridge          Colorado Springs
                Fort Collins              Glenwood Springs

DRAFT                                          Page 45 of 53                               Data Standards
Manual
 G. State or Province

     Banner is configured to automatically enter the state name when a zip code is entered. This is the
     preferred method of entering the state name.

     State codes must be entered for all U.S. and Canadian addresses. The appropriate code may be selected
     using Banner on the state code validation table (“STVSTAT”). The authoritative source for these codes
     is the Postal Service Address Standards publication. Information from this source is periodically
     updated by Information Technology Services into the Banner System.

     Canadian provinces are entered in the state or province field, NOT in the city field. Canadian provinces
     include Alberta, British Columbia, Manitoba, New Brunswick, Newfoundland, Northwest Territories,
     Nova Scotia, Ontario, Prince Edward Island, Quebec, Saskatchewan and Yukon. Canadian provinces
     have their own code for entry into the state field. Note: Canadian addresses must include the city in the
     city field and the province in the state or province field.

     International state and provinces (excluding Canada) are entered in the city field, NOT in the state or
     province field. This field should be blank for all international addresses.

     See the “Validation Table Dictionary” for additional information regarding validation table:
     STVSTAT: State or Province Codes.

H. Zip or Postal Code
     Zip or postal codes MUST be entered for all U.S. and Canadian addresses. If available, it should also be
     entered for other international addresses.
     The authoritative source for these codes is the Postal Service Address Standards publication.
     Information from this source is periodically updated by Information Technology Services into the
     Banner System validation table “GTVZIPC.”
     A hyphen must be entered when the entire 9-digit zip code is available. If the last four digits are
     unavailable, enter the first five digits in the first five positions of the field without the hyphen.
                 97203             97203-4798

     For Canadian addresses enter the six-character postal code by keying in three characters, a space and
     the last three characters.
                 T2T 2Y5                   R2L 1N4

     See the “Validation Table Dictionary” for additional information regarding validation table:
     GTVZIPC: Zip Codes.

 I. County

     A county code is required for all State of Colorado addresses. In those cases where it is undesirable to
     have the county code print on correspondence, county information can be suppressed by the various
     letter writing, population selection and check printing software utilized by Banner.




 DRAFT                                          Page 46 of 53                              Data Standards
 Manual
   County codes are listed on the “STVCNTY” validation table. The authoritative source for these codes is
   the Postal Service Address Standards publication. Information from this source is periodically updated
   by Information Technology Services into the Banner System.

   See the “Validation Table Dictionary” for additional information regarding validation table:
   STVCNTY: County codes.


J. Nation

   A nation code from “STVNATN” is required for all non-U.S. addresses.

   DO NOT enter a nation code for U.S. Addresses.

   Use the Nation Validation Codes from “STVNATN” to enter nation or country codes. The authoritative
   source for the Banner System is the FIPS - Federal Information Processing Standard. These standard
   codes are provided by the United States Post Office and are periodically updated by Information
   Technology Services into the Banner System. http://www.upu.int/post_code/en/addressing.html

   See the “Validation Table Dictionary” for additional information regarding validation table:
   STVNATN – Nation Codes.

K. Telephone Type/Telephone

   Telephone type/telephone fields are entered via the telephone form. See Section 6.


L. Inactivate Indicator

   The inactivate indicator should be used when an address is no longer valid. The “to date” field must be
   entered when inactivating an address.


M. Address Source

   See the “Validation Table Dictionary” for additional information regarding validation table: STVASRC
   Address Source Codes.


N. Delivery Point/Corrective Digit/Carrier Route

       The delivery point/corrective digit/carrier route fields are not used by the University.

O. Validation Tables

   See the “Validation Table Dictionary” for additional information regarding the following address
   related validation tables:

   STVATYP – Address Type Codes                          STVSTAT           –State/Province Codes
   GTVZIPC – Zip/Postal Codes                            STVCNTY           – County Codes

DRAFT                                        Page 47 of 53                             Data Standards
Manual
  STVNATN – Nation Codes                               STVTELE          – Telephone Type Code
  STVASRC – Address Source Codes

P. Summary

     All address information should be entered in normal upper- and lower-case format.
     Do not use special characters (ex. &, %, #, etc.) in any address fields.
     Only use periods, slashes, and hyphens in the street number (ex. 39.2 Rd).
     Use st, nd, rd, and th on numbered street names. (ex. 23rd Ave).
     Abbreviate street suffixes, unit designators, and compass directionals using standard abbreviations
      (ex. St., Ave., Rd., Ct., etc.).
     Only University employees should have a campus address (CA).
     City, state, county, and nation codes are populated automatically when entering a zip code.
     If necessary to manually enter a city name, spell it out in its entirety.
     Enter international addresses exactly as shown (three address lines available for use).
     International state and provinces (excluding Canada) are entered into the city field.




DRAFT                                      Page 48 of 53                            Data Standards
Manual
7. Telephone Information

  A. General

  An entity (person or non-person) may have multiple telephone numbers within the Banner system.
  Telephone numbers should be accurate and reflect the most recent data received. Supplemental
  information for international phone numbers may be added in the international access code field.

  Telephone numbers are added and/or changed on the Banner Telephone information form: SPATELE.

  All regional and local telephone numbers, including on-campus phone numbers, are entered using the
  ten-digit format. This ten-digit number is entered into the Area Code, Phone number and Extension
  fields as noted in 6.A.3. below.

  When adding a subsequent telephone number of the same type, the prior telephone number should be
  end dated, marked inactive, and the new telephone number added. Unless making a correction due to an
  initial data entry, do not change or delete the prior telephone number.

  Telephone numbers are displayed on Address forms, but are not stored with the address in the Banner
  tables.

  B. Telephone Type

     See the “Validation Table Dictionary” for additional information regarding validation table:
     STVTELE: Telephone Type Codes.

  C. Telephone Numbers

     The telephone number is entered into “SPATELE” using three separate entry fields as noted below:

     a. Area Code

         The three-digit area code must be entered for all phone numbers including the local (970) area.

     b. Phone Number
         Enter the seven-digit number without inserting a hyphen.
                     3341756

     c. Extension
         If an extension number is provided, enter only the digits of the extension. DO NOT enter EXT
         or X into the extension field.
                     5961             1764

  D. Primary/Unlisted/Inactive Indicators

     The primary indicator is set for a telephone number that is the primary contact for the entity.
     The unlisted indicator is set for a telephone number that is designated as unlisted.
     The inactive indicator is set for a telephone number that is no longer valid.


DRAFT                                     Page 49 of 53                              Data Standards
Manual
  E. International Access

     a. International Telephone Numbers

         International telephone numbers consist of four to seven digits

         International telephone numbers should include the country and city codes as part of the
         international access code field.

         The country code consists of one to four digits and is required (e.g. 876).

         The city code consists of one to three digits. Not all countries utilize city codes. The city code is
         often reported with a leading zero (0). DO NOT enter the zero.

         “011” must be dialed when making international calls from the United States unless dialing to
         any country included in the North American Numbering Plan.
             Example:
             Student Supplied                           Banner Entry
             Country Code: 3741                         City Code: 3741 (international access code)
             Number:       55-3984                      553984 (phone number)

             Country Code: 886
             City Code:    7                            8867 (international access code)
             Number:       236-2315                     2362315 (phone number)

     b. North American Numbering Plan (NANP)
         The North American Numbering Plan (NANP) agreement held among many North American
         countries establishes a procedure for dialing international numbers similar to traditional United
         States dialing procedures. The country code for all NANP countries is 1. Countries that are
         members of the NANP can be dialed using 1 plus the three digit area code. Any phone numbers
         from NANP countries can be entered in the domestic phone number field in the Banner system.

         Mexico is not a member of NANP. See Appendix C.4. for the listing of countries and area
         codes in the NANP.

  F. Comment

     The comment field is available for use for any comments about the associated telephone
     information.

  G. Address Type

     Telephone type codes may be associated with a specific address type code.
  H. Sequence

     The sequence field is automatically populated by Banner.



DRAFT                                      Page 50 of 53                               Data Standards
Manual
  I. Validation Tables
     See the “Validation Table Dictionary” for additional information regarding the following validation
     tables:
     STVTELE         – Telephone Type Codes.
     STVATYP         – Address Type Codes




DRAFT                                    Page 51 of 53                            Data Standards
Manual
8. Biographical Information

  A. Gender
         A Gender Code is required for all University employees and students. This information is
         maintained for federal and state reporting purposes.
  B. Birth Date
     A date of birth is required for all University employees and students.
     A copy of the birth certificate, passport, or driver‟s license must be provided with all birth date
     change requests.
     The Human Resources Office may enter and/or change faculty and staff birth date information.
     The Registrar‟s Office may enter and/or change student birth date information.
     See Appendix D.1. for standards for entering calendar dates.

  C. Age

     The age field is automatically calculated by Banner.

  D. Social Security Numbers (SSN) and Taxpayer Identification Numbers (TIN)
     A U.S. SSN should be entered into the SSN/TIN field for “persons” and a TIN should be entered
     into the SSN/TIN field for “non-persons.”
     The entire 9-digit SSN or TIN number should be entered into this field. Dashes and spaces between
     numbers should be omitted (e.g. 123456789).
     A SSN is required for all University employees and independent contractors.
     While it is preferable that students disclose their SSN, a SSN is required only for students applying
     for financial aid, employment, or the College Opportunity Fund. A SSN is an optional data element
     for all other constituents of the University.
     A person must present a copy of his or her Social Security card in order to have his/her SSN or
     legal name changed within Banner.

     The Human Resources Office may enter and/or change faculty and staff SSN information.

     The Registrar‟s Office may enter and/or change student SSN information.

     The Purchasing Office may enter and/or change TIN information.

  E. Confidential Indicator

     The confidential indicator field is used for students who do not want directory information released.

  F. Deceased Indicator/Date

     Due to the sensitivity of this issue, prompt attention is important so future mailings from University
     offices are discontinued. The deceased status indicator and date may only be changed upon receipt
     of documented and verified information, not just perceived information.

DRAFT                                      Page 52 of 53                              Data Standards
Manual
     All population selections for communication purposes must search for and exclude deceased
     persons.

     The Dean of Students Office is responsible for maintenance of this field for students.

     Human Resources is responsible for maintenance of this field for employees.

     An annual review and end dating of addresses for deceased persons will be conducted.

  G. Citizenship

     A citizenship code is required for students and employees. For all other “person” entries into the
     Banner system, this field may be populated or left blank to indicate that U.S. citizenship is not
     known.
     Citizenship information is used in IPEDS ethnic reporting for institutional research.

     See the “Validation Table Dictionary” for additional information regarding validation table:
     STVCITZ -Citizenship Codes.

  H. Ethnicity

     An ethnic code is required for all University employees and students. “Does not wish to
     provide” is an acceptable code.

     Ethnicity is tracked for purposes of federal and state reporting requirements for United States
     citizens only.

     One of the six IPED‟s required ethnicity codes MUST be entered for students and employees who
     are U.S. citizens or U.S. permanent residents:

     African American                 Native American                 Asian American
     Hispanic                         Caucasian                “Does Not Wish to Provide”
     The University does not track the ethnicity status of international students and employees who are
     not U.S. citizens or U.S. permanent residents. The status of “non-resident alien” is available for
     these persons; however, this field is NOT required for international students or employees.

     To accommodate persons with multiple ethnic classifications, a primary ethnic code should be
     entered in the ethnicity field. Any additional ethnicities should be entered as a separate comment on
     the “Banner Comment” form.

     See the “Validation Table Dictionary” for additional information regarding the following validation
     tables:

     STVETHN          - Ethnic Codes
     STVETEC          - IPEDS Ethnic Codes

  I. Marital Status

     A marital status code is required for all University employees.

DRAFT                                     Page 53 of 53                             Data Standards
Manual
      A copy of a marriage license or a divorce decree must be provided with all marital status change
      requests.

      The Human Resources Office may enter and/or change employee marital status information.

      See the “Validation Table Dictionary” for additional information regarding validation table:
      STVMRTL - Marital Codes.

  J. Religion

      The University will maintain religion data in the Banner system.

  K. Legacy

      The University will maintain legacy data in the Banner system.

  L. Veteran Information

      a. Veteran File Number

          Veteran information is only collected and maintained for regular employees by Human
          Resources.

      b. Veteran Category

          See the “Validation Table Dictionary” for additional information regarding validation table:
          STVVETC - Veteran Category Codes.

      c. Active Duty Separation Date

          The active duty separation date field is used to enter the date that students and/or employees
          separate from the University because they are called to active duty in the military.

          The Human Resources Office may enter and/or change employee active duty separation dates.

          The Dean of Students Office may enter and/or change student active duty separation dates.

      d. Special Disabled Veteran Indicator

          The special disabled veteran indicator is used by Human Resources only.

          The Human Resources Office may enter and/or change the employee special disabled veteran
          indicator.

  M. Validation Tables

  See the “Validation Table Dictionary” for additional information regarding the following miscellaneous
  general person validation tables:

  STVCITZ – Citizen Type Codes                         STVETHN           – Ethnic Codes

DRAFT                                      Page 54 of 53                             Data Standards
Manual
  STVETEC – IPEDS Ethnic Codes             STVMRTL   – Marital Status Codes
  STVRELG – Religion Codes                 STVLGCY   – Legacy Codes
  STVVETC – Veteran Category Codes




DRAFT                            Page 55 of 53                 Data Standards
Manual
9. E-mail Information
  “Persons” or “non-persons” may have multiple e-mail addresses within the Banner system. E-
  mail addresses should be accurate and reflect the most recent data received.

  University e-mail correspondence to students and employees will be sent only to University
  assigned e-mail addresses.

  Unless making a correction due to an initial entry error, do not change or delete the prior e-mail
  address.
  When adding a new e-mail address, inactivate the current e-mail record by clicking the
  Inactive checkbox and then click to the next e-mail type field to enter the new e-mail
  address. To save the history, do not change the original e-mail – Always create a new e-
  mail address record.


  A. E-mail Addresses

      E-mail addresses follow a standard format. E-mail addresses consist of a log-in name
      followed by the “@” sign, followed by the domain name.

      A domain name contains between two and four elements separated by periods. For example
      admissions.help@unco.edu is the address where University admissions questions can be sent.

      Please refer to the University‟s e-mail policy for details regarding University e-mail accounts.

  B. Comment

      The comment field is available for any comments about the associated e-mail address
      information.

  C. Validation Tables

      See the “Validation Table Dictionary” for additional information regarding validation table:
      GTVEMAL – Email Address Type Codes.




DRAFT                                      Page 56 of 53                             Data Standards
Manual
10. Emergency Contact Information

    The general form is used to enter emergency contact information for persons.

  A. Priority

      A priority number is a number assigned for persons with more than one emergency contact.

  B. Contact Name

      See Section 4C – Last, First, and Middle Names

  C. Relationship

      The relationship field reflects the relationship of the emergency contact to the person.

  D. Address
      See Section 6 - Address Information.
  E. Telephone
      See Section 7 - Telephone Information
  F. Validation Tables
      See the “Validation Table Dictionary” for additional information regarding the emergency contact
      validation table: STVRELT – Relation Code




DRAFT                                        Page 57 of 53                            Data Standards
Manual
                                 Appendix A.1.
           Student, Employee or Vendor “Person” Change Request Form
           Please PRINT legibly AND attach appropriate DOCUMENTATION*
                     Complete only the sections that require changes




DRAFT                                Page 58 of 53                      Data
Standards Manual
                                 Appendix A.2.
 Student, Employee or Vendor “Person” Social Security Number Change Request Form
              Please PRINT legibly AND attach Copy of Social Security Card




DRAFT                                 Page 59 of 53                          Data
Standards Manual
                          Appendix A.3.
                 Vendor “Non-Person” Change Form
         Please PRINT legibly and Attach to W-9 form for processing




DRAFT                       Page 60 of 53                             Data Standards
Manual
                        Appendix A.4.
         “Person” and “Non-Person” Vendor Create Form
          Please PRINT legibly and Attach to W-9 form for processing




DRAFT                        Page 61 of 53                             Data Standards
Manual
                        Appendix A.5.
         BANNER Oracle USER_NAME ID CHANGE FORM




DRAFT                 Page 62 of 53               Data Standards
Manual
                                Appendix B
         SCT Banner Validation Table/Data Standard Change Request




DRAFT                        Page 63 of 53                  Data Standards
Manual
C.1 Prefixes
   Doctor                   Dr                  Professor                  Prof
   Father                   Fr                  Rabbi                      Rabbi
   Governor                 Gov                 Representative             Rep
   Honorable                Hon                 Reverend                   Rev
                                                                                            C.2 Suffixes
   Judge                    Judge               Senator                    Sen

   Chief Executive Officer                CEO               Doctor of Medicine        DMV             Doctor of Laws           LLD
   Chief Financial Officer                CFO               Doctor of Education       EdD             Doctor of Medicine       MD
   Certified Public Accountant            CPA               Esquire                   Esq             Doctor of Optometry      OD
   Doctor of Chiropractic                 DC                The Second                II              Doctor of Philosophy     PhD
   Dean                                   Dean              The Third                 III             Retired                  Ret    C.3
   Dentist                                DDS               The Fourth                IV              Registered Nurse         RN     North
   Doctor of Dental Medicine              DMD               Juris Doctor              JD              Senior                   Sr     Americ
   Doctor of Osteopathy                   DO                Junior                    Jr
                                                                                                                                      an
Numbering Plan (NANP)

   Country                        Area Code             Country                                              Area Code
   Alberta                        403/780               Montserrat                                           664
   Anguilla                       264                   New Brunswick                                        506
   Antigua                        268                   Newfoundland                                         709
   Bahamas                        242                   Northern Marianas Islands (Saipan, Rota & Tinian)    671
   Barbados                       246                   Nova Scotia                                          902
   Barbuda                        268                   Ontario                                              416/519/47/705/807/905
   Bermuda                        441                   Puerto Rico                                          787/939
   British Columbia               250/604/778           Quebec                                               418/450/514/613/819
   British Virgin Islands         284                   Saskatchewan                                         306
   Cayman Islands                 345                   St. Ktts/Nevis                                       869
   Dominica                       767                   St. Lucia                                            758
   Dominican Republic             809                   St. Vincent and Grenadines                           784
   Grenada                        473                   Trinidad and Tobago                                  868
   Guam                           671                   Turks and Caicos Islands                             649
   Jamaica                        876                   U.S. Virgin Islands                                  340
   Manitoba                       204                   Yukon, NW Territory, Nunavut                         867




   DRAFT                                                           Page 64 of 53                                      Data Standards Manual
Appendix D–Miscellaneous

D.1. Calendar Dates
      Date fields appear on forms throughout the Banner system.

      Banner is set up to accept dates in the format month, day, and year.

      Banner determines which parts of a date entry are the month, day and year, and automatically
      converts and stores the date in the format DD-MON-CCYY.

      Always enter all three parts of calendar dates (month, day, and year).

      Always enter two digits for the month and day.

              Enter January as 01
                         th
              Enter the 5 day of the month as 05

      The default method for entering dates is DD-MON-CCYY (ex. 05-MAR-2002). Use this method if
      desired or if the shortcut methods do not work.

      A date may be entered without separators (no spaces or special characters) or using a dash (-) or
      slash (/) as separators.

      The date March 5, 2006 can be entered in any of the following ways:

              03052006           03/05/2006       03-05-2006        05-MAR-2006

      In all cases, the date will be stored as: 05-MAR-2006

      If only part of the current date is entered, the rest of the current date will default.

      Entering a “T” in a date field and pressing “enter”, will enter today‟s date as a default.

      All four digits are required when completing a query on the date field. For example, enter 26-JUN-
      2006, not 26-JUN-06. Zeros are entered for the century if the century is omitted. In this example,
      entering 26-JUN-06, results in the date of 26-JUN-0000, not 26-JUN-2006.

D.2. Driver‟s License Information
      Human Resources maintains driver‟s license information only if it is required for the position.

      Financial Aid also collects driver‟s license numbers from the filing of FAFSA, but these do not
      become a part of the student record.

      Enter the driver‟s license number as it appears on the license. Do not include the state which issued
      the license in the license number field. Do enter the state which issued the license in the state field.
D.3. Letter and Paragraph Names                              The names of letters created within any module of Banner a
                                                             “GTVLETR.” Paragraph names are stored in “GTVPARA.”



DRAFT                                         Page 65 of 53                               Data Standards
Manual
In order to avoid confusion as to the owner of a letter defined within Banner, the following convention must be
                                                              FA         Financial Aid Office
                                                                          form “GTVLETR:”
used by offices and schools when defining a letter name on the BannerFood Services
                                                              FS

        1. Letter Names cannot exceed 15 characters in length. A Letter Name must have a Letter Prefix and
                                                                 HR          Human Resource Management
             a Letter Identifier separated by an underscore. A Letter Sub-prefix is optional.
                                                                 HRB         Benefits Office
                   Letter Prefix - - This will be used to identify offices and schools. A prefix is mandatory from
                                                                 HS          Health Service
                      the list of office prefixes (see below).
                                                                 HS          School of Health Sciences
                   Letter Sub-prefix - - This is optional, but can be used to further define audience, groups or
                                                                 IA          Internal Audit
                      departments within the higher order prefix. This is free-form
                                                                             Institute This can be Transformation
                                                                 IET type of letter. for Economicfree-form using
                   Letter Identifier - - This is used to identify the
                                                                             International Programs
                                                                 IP characters within the overall length constraint.
                      alphabetic letters, numbers and valid special
        2. Paragraph Names should use prefixes, as applicable.   IRP         Institutional Research and Planning
                                                                 JA          Judicial Affairs
Office Prefixes:                                                 LA          School of Law
                                                                 LIB         Library Bayer School of Natural & Environmenta
 AA          Academic Affairs                                                         Science
                                                                 LSC NE Learning Skills Center
 ADM         Admissions Office                                   MU      NU School School of Nursing
                                                                                      of Music
             McAnulty College and Graduate School of Liberal
 AR          Arts                                                        OMI          Office of Mission & Identity
 ATHL        Athletics                                                   OR           Office of Research
                                                               The following are examples of Names using both a
 AUX         Auxiliary Services                                          PA           Public Affairs
                                                               mandatory prefix and optional sub-prefix:
 BU          School of Business Administration                           PH
                                                               REC_GRED_FALTR         School of Pharmacy
                                                                                             Grad Ed Financial Aid Letter
 BUD         Financial Affairs                                           POL
                                                               REC_UGSL_INPAFL               Safety
                                                                                      Public UG SLPA Inquiry Packet Foll-Up
 CA          Commuter Affairs                                            PRS
                                                               ADM_GRBU_INF_LT        President's Office Request Letter
                                                                                             Grad Bus Info
 CM          Campus Ministry                                             PRV          Provost
                                                               ADM_UGNU_ABSNPK UG Nsg Accept BSN Packet
 CSC         Career Services Center                                      PTM          Parking & Traffic Management
 CTE         Center for Teaching Excellence                    Submit Change Requests in accordance with Change Mana
                                                                         PUR          Purchasing
 CTS         Computing and Technology Services                 the list of prefixes. Recruiting
                                                                         REC
 ED          School of Education                                         REG          Registrar's Office

D.4. Quick-flow Names
There is a capability in the Banner Systems to “package” a set of forms into what is called a Quick-Flow. The
names of Quick-Flows created within any module of Banner are stored in a common validation table called
“GTVQUIK.”

Quick-Flow names can be up to four characters in length.

In order to avoid confusion as to the owner of a Quick-flow defined within Banner, the following prefixes will
be used by offices when defining a Quick-flow name on the Banner form “GTVQUIK.”

ADM        Admissions                                 REC         Recruiting
ADV        Advancement Services                       REG         Registrar's Office
FA         Financial Aid Office                       UCAP        Accounts Payable
HR         Human Resource Management                  UCAR        Accounts Receivable
PUR        Purchasing                                 UCP         Payroll

If your office is not listed, please submit a Change Request form to DU-IT Data Standards.

Any Quick-Flow using any General Person or Non-Person form, specifically SPAIDEN (and APAIDEN,
PPAIDEN, or FOAIDEN), SPAPERS, SPATELE and GOAEMAL, must adhere to General Person and Non-
Person Procedures for Point-of-Entry, Maintenance and View Processing (under separate cover).



DRAFT                                         Page 66 of 53                             Data Standards
Manual
DRAFT    Page 67 of 53   Data Standards
Manual
                  Appendix E –Shared Validation Tables
         List of Validation and Rule Tables in Alpha Order




DRAFT                       Page 68 of 53                Data Standards
Manual

				
DOCUMENT INFO
Description: Cognos 8 Business Intelligence the Official Guide document sample