I. Introduction
II. Data Integrity

   A. Purpose
   B. Administrative Responsibility 
   C. Access to Official Records
   D. Data Custodians 
   E. Informational Users
   F. Information Access
   G. Confidential Flag
   H. Confidential Information Indicator

III. Record Creation Guidelines

   A. Overview
   B. Before Creating Records In INB
   C. Before Creating Records From Off Line Sources

IV. General Person Criteria

   A.  GENERAL STANDARDS 
   B.  DATE STANDARDS
   C.  GENDER CODE 
   D.  PERSON IDENTIFICATION NUMBER 
   E.  ALTERNATE  IDENTIFICATION NUMBERS 
   F.  VENDOR (NONPERSON) IDENTIFICATION NUMBER
   G.  IDENTIFICATION NUMBER CORRECTIONS:  SEE “HOW TO” APPENDIX

V. Name Standards

     A.  INTRODUCTION
   B.  LAST NAME
   C.  FIRST NAME
   D.  PREFERRED FIRST NAME
   E.  MIDDLE NAME
   F.  PREFIX
   G.  SUFFIX
   H.  NON-PERSON NAME/VENDOR
   I.  NAME TYPE/ALTERNATE NAME
   J.  NAME AND ID CHANGES
   K.  DATE OF BIRTH
   L.  CITIZEN TYPE
   M.  MARITAL CODES
   N.  LEGACY CODE
   O.  ETHNIC CODES
   P.  VETERAN FILE NUMBER
   Q.  DECEASED INFORMATION CHECKLIST

VI. Address Standards

   A.  INTRODUCTION
   B.  ADDRESS TYPES
   C.  STREET STANDARDS
   D.  CITY STANDARDS
   E.  STATE & PROVINCE STANDARDS
   F.  ZIP CODE STANDARDS
   G.  NATION CODE STANDARDS
   H.  MILITARY STANDARDSj
    I.  ADDRESS CHANGE SOURCE TYPES

VII. Telephone Types

   A.  INTRODUCTION
   B.  E-MAIL TYPES

VIII. Appendices 

APPENDIX A – ABBREVIATIONS FOR STREET DESIGNATOR 
APPENDIX B – CITY ABBREVIATIONS
APPENDIX C – TWO-LETTER STATE & POSSESSION ABBREVIATIONS
APPENDIX D – FOREIGN NATION CODES 
APPENDIX E – CONFIDENTIAL FLAG 
APPENDIX F – COMMON FORMS  
APPENDIX G – DUPLICATE RECORDS 
APPENDIX H – CONFIDENTIALITY AGREEMENT  
APPENDIX I -- DECEASED INFORMATION CHECKLIST
"HOW TO" APPENDIX

---

I.  INTRODUCTION

Weber State University is providing the campus with an integrated software package that will increase the quantity and quality of information it maintains.  This package, named Lynx (Banner) will also provide increased accessibility to that information, enhanced data security, and compatibility across functional areas of responsibility. 

Lynx is modular, meaning that there are modules for different functional areas, including   Financial Aid, Finance, Human Resources/Payroll, Alumni/Development, and Student.  There also is a General module that ties all of the functional modules together.  Shared information is called GENERAL PERSON and includes the following: ID(s), name(s), address(es), phone(s), email(s), gender, birth date, marital status, deceased flag, and confidential flag.

Lynx is a collection of forms (screens) with embedded instructions used to enter data, modify data, delete data, and query data.  Lynx simply provides the screens and programs necessary to manipulate data.  The data itself is stored in tables residing in an Oracle database.  It is a relational database, meaning that tables are linked together by means of some internal identification number, which limits data redundancy.  One table might have a student ID number and the course numbers in which he/she is enrolled.  A separate table has the course numbers and the course descriptions.  The course numbers would link the two tables together providing a course description for the courses in which a student is enrolled.  There are over 2,000 tables in the Lynx system. 

At Weber State University, the Summer term represents the first semester of each academic year.  The Fall term is the second semester and Spring term is the third semester.

---

II. Data Integrity

PURPOSE

These guidelines are established to provide quality and consistency for data entry and conversion.  They also define the responsibilities of everyone accessing and managing the data and equipment.  Offices are permitted to establish individual guidelines that supplement, but do not supplant or contradict, these guidelines.  Data entrusted to Weber State University by other organizations (e.g., Foundations and Governmental agencies) is governed by terms and conditions agreed upon with those organizations.  Specific issues not governed by such agreed terms shall be governed by the guidelines set forth in this document.

With the goal of ensuring database integrity and easy, professional, cost-effective communication University wide, these guidelines will direct users to: 

Avoid creation of duplicate records for a single entity;

Provide complete name/address information in a timely manner, with an audit trail of changes;

Use standard entry to facilitate consistent reports and searches;

Share effective processing discoveries and problem-resolution tasks with other team members;

Use Postal Services recommended mailing address setup and procedures;

Take advantage of  database capabilities, data integration and workflow analysis.

ADMINISTRATIVE RESPONSIBILITY

In accordance with the Family Education Rights and Privacy Act (FERPA), 1974, as amended, and to ensure maximum safeguards against indiscriminate distribution of information contained in a student’s personal records at Weber State University, only authorized Weber State University personnel will disclose information of a confidential nature.  That is, information not normally available to the general public will be provided only to the students themselves, or to a third party upon receipt of an original written release signed by the student concerned.

Certain exceptions to FERPA include authorized University personnel acting within the student's legitimate interest; organizations conducting studies for educational and governmental agencies; accrediting agencies; appropriate persons in case of health or safety emergencies; agencies or office in connection with a student's applications for financial aid; governmental officials as identified by Public Law 93-380; and an appropriate official in response to a court order or subpoena.

Without a signed release, the University can make only "directory information" available for public use in campus directories, publicity of events, honors, and the like.  The following constitutes directory information: Name, Address, Phone, Date of Birth, Dates and Terms of Attendance, Full/Part Time, Major Field of Study, Degrees and/or Certificates Earned, and Academic Honors Received.

All levels of management shall ensure their areas of accountability so that each information system user knows his/her responsibilities.  Employees must adhere to any applicable Federal and State laws covering storage, retention, use, release, and destruction of data.

Electronic data is owned by Weber State University and is a vital asset.  All institutional data, whether maintained in the central database or copied into other data systems, including microcomputers, remains the property of Weber State University.  Access to data is not approved for use outside an individual’s official Weber State University responsibility.  Computerized, institutional data shall be used only for the legitimate business of  Weber State University.  Institutional computing services and facilities shall be used only as required in the performance of job functions.

Supervising administrators shall ensure a secure office environment with regard to all institutional information systems.  Administrators shall validate the access requirements of their staff according to job functions, before submitting requests for the provision of access.  Under no circumstances shall anyone use institutional electronic data (in detail or summary) in any publication, seminar, or professional presentation, or otherwise release data in any form outside Weber State University, without prior written approval from the appropriate data custodian (see page 7.)  Data should never be left on any system to which access is not controlled.

As a general principle of access, Weber State University data (regardless of who collects or maintains it) shall be shared among those employees whose work can be done more effectively by knowledge of such information.  Although the University must protect the security and confidentiality of data, the procedures to allow access to data must not unduly interfere with the efficient conduct of University business.

All information systems owned by Weber State University shall be constructed to assure that:

1.      Accuracy and completeness of all system contents are maintained during storage and processing.

2.      System capabilities can be re-established within an appropriate time after loss or damage by accident, malfunction, breach of security, or natural disaster.

3.      Actual or attempted breaches of security can be detected promptly and controlled.

4.      All who use institutional data have the right to expect the data to be accurate.

ACCESS TO OFFICIAL WEBER STATE UNIVERSITY RECORDS

University departments/divisions will observe the following requirements and limitations when obtaining permission for inquiry and update access to Weber State University’s official records.  The need to maintain data security is everyone’s responsibility and must be impressed upon all employees.

Access will be awarded only after appropriate tailored training is received and the University’s Confidentiality Agreement has been signed.  Entries to Lynx general entity (person or non-person) tables affect the overall integrity of the database used by all Lynx modules.  Failure to abide by the guidelines outlined in this manual for creating and maintaining general entity records will result in loss of access.  (Cherrie Nelson’s Team – How is this being handled now?)

Employees must not loan or share their login codes or passwords with anyone.  If it is found that login codes are being loaned or shared, employees who are assigned access to records are subject to disciplinary action.

Departments/divisions should take steps to ensure that they have an alternate person assigned as backup for each office function, and that this individual has access to the system functions required to provide backup support.  Every department/division will maintain a current list of primary and secondary users for the various module functions.

Departments/divisions may request access authorization for an employee by completing and submitting a System Access Authorization Request to the appropriate data custodian.  If a request is questioned or denied, the data custodian will contact the requesting department/division. If a request is approved, the data custodian will forward the request electronically to Information Technology Database Administration. Once access is granted by Database Administration, appropriate tailored training must be conducted and acknowledged by the data custodian’s signature before access is granted to the production database.  Under no circumstances will access authorization be granted without approval of the department/division head, the module data custodian, and Data Administration. The Lynx Access Request Form may be obtained from the Information Technology division or its manager or at http://www.weber.edu/accounting >>> LYNX Request From). 

Workflow will be used to notify the appropriate person of forms to view, approve, or disapprove.  The notification process is done through GroupWise.

Update access provides both inquiry and update capability.  Update capability is generally limited to the offices directly responsible for the collection and management of the data.  Update access is available to administrators and users who have an authorized need to change institutional data in the routine performance of their job duties.

Each user of administrative information is assigned the appropriate combinations of inquiry-only and update access to specific parts of the Lynx administrative information system.  The types of access are determined by the data custodians.

DATA CUSTODIANS

A data custodian, usually an administrator of a Weber State University office or department, may make data available to others within his or her department for use and support of the unit’s functions.

Before granting access to data, the data custodian shall be satisfied that the protection requirements have been implemented and a “need to know” is clearly demonstrated.  By approving end-user access to institutional data, the data custodian consents to the use of this data within the normal business functions of administrative and academic offices.  Query (inquiry) access to institutional data will be broadly available throughout the institution.

Data custodians (or designees) are responsible for the accuracy and completeness of data files in their areas.  Misuse or inappropriate use by individuals will result in revocation of access privileges.  Data custodians are also responsible for coordinating maintenance and control of the Lynx administrative information system’s validation and rule tables and for conferring with other data custodians on impending changes. The validation and approval of software releases is the responsibility of Information Technology.  These tables and processes define how business is conducted at Weber State University and all satellite locations.

Data Custodians

General Person Record Custodians

A general record (person or non-person) may have more than one active/current association with the University (i.e., employee, student, vendor and donor).  When general record data needs to be updated or corrected, refer to the “Order of Precedence” column to determine the association with the highest precedence (lowest number).  Notify the appropriate offices to make the needed change.  GUASYST will display general record associations.  (Need to define what this process will be and get it into a training manual/appendix)

INFORMATION USERS

Users are responsible for understanding all data elements that are part of the General Person record.  If a person does not understand the meaning of a data element, he/she should consult online help or the appropriate training manual.  (A data dictionary is being generated.)  Users will exercise due care in using the institution’s information systems, both the central institutional database and all departmental systems, to protect data files from unauthorized use, disclosure, alteration, or destruction.  Each user is responsible for security, privacy, and control of his/her own data.  Each user is responsible for all transactions occurring during the use of his/her login and password.

The department/division must have all employees, temporary employees, or student workers sign the Confidentiality Agreement (See Appendix H).  All employees who require access to online records must use a system login code defined specifically for that employee.  This will allow updates to be tracked to a specific user login code and a specific person.

Any exceptions to the above guidelines must be requested in writing with justification and be approved by the data custodians.

INFORMATION ACCESS

Query (Inquiry) only access enables the user to view, analyze, and download, but not to change institutional data.  However, once information is downloaded, data can be (but should not be) altered in word processing documents or spreadsheets.  Downloaded information should be used and represented responsibly and accurately.  Any reports generated from downloaded data must be labeled “unofficial.”

CONFIDENTIAL FLAG 

Because of FERPA regulations regarding the confidentiality of student records, this flag is critical. 

The Confidential Flag, which is set on the XXXPERS screen, will be added by the Registrar’s Office or Human Resources and may be used by other offices, such as Alumni/Development.  A warning message box will appear the first time the record is viewed, and the confidential information will be visible on every form related to the individual.

This Flag indicates that a person wants all or part of his/her record kept confidential, some or all of personal information blocked from the Campus Directory, and/or some or all information NOT to be published in other documents.  (See Below)

CONFIDENTIAL INFORMATION INDICATOR

(Is there something higher than FERPA that can be added so this becomes a statement for General Person as well as General Student records?)

In accordance with FERPA, if a person wishes to have his/her information marked “confidential”, this field is checked.  When information is marked confidential, no directory information is to be released.  A person’s confidential request is entered on the Person Form XXXAPERS. The following constitutes directory information: Name, Address, Phone, Date of Birth, Dates and Terms of Attendance, Full/Part time, Major Field of Study, and Degrees and/or Certificates Earned, and Academic Honors Received.  If the Confidentiality indicator is not  (or is ‘null’), the directory information that will be released is limited to Name, Address, Phone, Date of Birth, Dates and Terms of Attendance, Full/Part time, Major Field of Study, and Degrees and/or Certificates Earned, and Academic Honors Received.  For Alumni/Development, this means that the person should not be included in any published alumni directory. A person’s confidential request is entered on the Person Form XXAPERS.(from version 1/12/04)

---

III.  Record Creation Guidelines

OVERVIEW

Lynx “entity” records can be created online through several forms or can result from batch electronic processes such as tape loads. It is critical to follow procedure to ensure that new records are not created for an existing person or organization.  This is critical because merging duplicate persons or  organizations requires labor-intensive procedures to maintain or discard the appropriate parts of the underlying records. Adherence to these procedures by users authorized to create new General Person records in the database can and will be monitored.  Users who repeatedly fail to follow these procedures may have their privileges revoked.

BEFORE CREATING RECORDS IN INB:

SEARCHES: 

Careful searching will prevent the creation of duplicate General Person records.  Searches should be conducted using the following guideline:

First – Search by Lynx ID (Wxxxxxxxx), then by Legacy ID (STAARS, HRS, TRE, etc.)

If not found – Search by name using XXXIDEN name search or extended search.

See training manual for applicable “How to”.

See “How To” Appendix (ADD PRINT SCREEN & INSTRUCTIONS

BEFORE CREATING RECORDS FROM OFF LINE SOURCES: 

Transactions creating new person and organization records in the database from 
external sources, such as tape loads, FTP imports, and World Wide Web, must be reviewed before they can be loaded into the production environment.  Chapter 11 of theBanner Bookshelf Student System User’s Manual outlines the setting up of rules and edits that control these processes and gives specific procedures for the importing of new applications established by Lynx Web for Students. These rules and procedures must be carefully reviewed in order to prevent the inadvertent creation of duplicate entity records in the system.

---

 

IV. General Person Criteria

General Standards

1. The pound sign (#), asterisk (*), and percent sign (%) are NOT to be used in any data field.  These characters are reserved for technical purposes.
    

2. Commas (,), apostrophes (’), ampersands (&), and periods (.) are NOT to be used in any General Person data field.  (Alumni has created a duplicate address type designated by “A” in order to utilize punctuation for mailing only.)
    

3. Data is entered using mixed case format (uppercase and lowercase letters) following standard capitalization rules. 
    

4. Abbreviations are often used when entering data.  If you are in doubt about an abbreviation, check the approved list first.  For example, Post Office Box should be entered as: PO Box. The approved lists can be found in Appendices A - C of this document. Weber State University requires that USPS standards be used. If you do not locate an abbreviation, spell the word.  See also http://USPS.com.  
    

5. Search first, before creating a new record for a person or organization.  Conduct an ID and name search as specified in Section III, Record Creation Guidelines, to make sure the person or organization has not already been entered into the Lynx database.  All offices must conduct a thorough search to prevent entering a duplicate record.
    

6. Changes to an employee, student, or vendor record will not be made without the proper documentation.

DATE STANDARDS

1.      Date fields appear on forms throughout the Lynx system.

2.      Lynx is set up to accept dates in the format MDY (Month, Day, Year).

3.      All dates should be entered as
MM/DD/YYYY or MM-DD-YYYY or MMDDYYYY
 (e.g., 08/21/2003 or 08-21-2003 or 08212003)

4.      For today’s date, enter a “t”.

5.      For dates within the current month, type just the day and press the Enter key.  Lynx will fill in the month and year.

6.      Lynx will always display the date as DD-MMM-YY no matter how it is entered. 

7.      When a Date is Not Available:  leave the field blank. 

GENDER CODE

A gender code is entered as male, female or not available.

Code	Description	Explanation
M	Male	A male person
F	Female	A female person
N	Unknown/ Non-Responsive	Use when the gender information is not available or if the gender cannot be determined by the name (i.e., Chris, Pat, Terry, etc.)

Note:  All employees MUST be classified as male or female.  ‘N’ is not an allowed entry in Lynx for an employee.  The use of ‘N’ must be minimized in student records as well. Additional research must be made to determine the gender code.

PERSON IDENTIFICATION NUMBER

1. A nine-character identifier (ID) is used to access a person’s information in Lynx.
    

2. All new-person records will be assigned a system generated identification number.  Procedures for adding new person records to the system are outlined in Section 3.
    

3. System generated identifiers (ID) are in the form of W99999999 where 9 represents any digit.  The W sign is a Weber State University-wide defined value.

ALTERNATE  IDENTIFICATION NUMBERS

1. Social security numbers should NOT be added via the ALTERNATE NAME/ID window on the XXXIDEN form.  This creates a confidentiality breach of security.  To search on Social Security Number, use GUIALTI.
    

2. For employees, Human Resources has the sole responsibility for changing or adding social security numbers.  For Students SSN can be updated or changed by providing a SSN card at Admissions.  Financial Aid may also change or update a Student SSN when they have been provided with the SSN card.  Please use GUASYST to determine ownership of the person’s record.

Alternate Identification Number Types

Type	Description	Definition of Use
LGCY	LEGACY Identification Number	Used to store the student ID’s from any Legacy System

 

VENDOR (NONPERSON) IDENTIFICATION NUMBER

 

Vendors will be assigned a system generated ID.  Alternate search criteria will be the Federal Identification Number (FIN) or lacking that, the SSN.  The FIN or SSN will be entered on the XXIDEN form.  These fields should not be left blank, nor should they be zero filled or filled with repeating characters.

IDENTIFICATION NUMBER CORRECTIONS:  SEE “HOW TO” APPENDIX

---

V. Name Standards

INTRODUCTION

Every “W” ID number has a key name associated with it.  The KEY name is either the legal name of the person or the name of a non-person.  KEY names are entered on XXXIDEN.  The name for a person has six (6) separate parts.  These are:

• Last Name

• First Name

• Middle Name

• Prefix

• Suffix

• Preferred First Name (shown on SPAIDEN, APANAME, PPAIDEN, WHERE IN FINANCE, WHERE IN FINANCIAL AID?)

 

LAST NAME
 

1. Use mixed case (i.e., upper and lowercase letters)
    

2. Use the legal spelling and format of the last name
    

3. Enter as presented, adhering to the following guidelines.

a.       Hyphens may be used to separate double last names (i.e., Cooper-Smith).

b.      Spaces are used for two last names not hyphenated (e.g., Monica Lou Creton Quinton…last name is entered as Creton Quinton, with no hyphen)

c.       Apostrophes may be used (e.g.,  O’Leary, O’Connor) as an Alternate Name.  The Alternate Name Type should be SPEC.    

d.      Do NOT use prefixes and suffixes in the last name field.  (i.e., Dr, Mr, Ms, III, Jr, MD).  There are data fields for prefixes and suffixes.

FIRST NAME
 

1. Use mixed case (i.e., upper and lowercase letters)
    

2. Use the legal spelling and format of their first name even if they use the initial of their first name and prefer their middle name
    

3. Enter as presented, adhering to the following guidelines.

a.   Hyphens may be used

b.   Spaces are permitted for double names (e.g., Mary Ann, Bobby Joe).

c.   Single Character First Names should be entered with no period. 

d.   Apostrophes may be used as an Alternate Name.  The Alternate Name Type should be SPEC.   

e.       Do NOT use titles, prefixes, and suffixes in the first name field (e.g., Dr., Mr., Mrs.).

PREFERRED FIRST NAME

Do NOT use the Preferred First Name Field – it is not a searchable field.  Instead, utilize the Alternate Name type of NICK in the following instances:

1.      First Name: Used when a person prefers to be addressed as something other than their legal first name.
Used when the first name starts with an initial (e.g., S. Paul Smith who prefers the first name of Paul would have an Alternate Name type of NICK as Paul Smith)

2.      Last Name: If the person prefers to use a derivative of their last name, enter it as an Alternate Name type of NICK (e.g. Susan Smith-Jones who prefers the last name of Smith would have an Alternate Name type of NICK going by Susan Smith).

3.      In instances where an individual has both a preferred first and last name, combine the preferences into only one NICK alternate name type.

4.      Use the same standards as above in instances where there is a preferred Middle Name.

5.      Use mixed case format (uppercase/lowercase).

6.      Spaces, apostrophes, and hyphens are permitted.

MIDDLE NAME

1.      Use mixed case (i.e., upper and lowercase letters).

2.      Enter the entire middle name if available for identification purposes.

3.   Enter as presented following the following guidelines.

a.   Hyphens may be used to separate double names.

b.   Spaces are permitted for multiple names (e.g., Mary Ann, Bobby Joe).

c.   Single Character Middle Names should be entered without a period.  

d.   Apostrophes may be used as an Alternate Name.  The Alternate Name Type should be SPEC.           

e.       Do NOT use titles, prefixes, and suffixes in the first name field (e.g., Dr., Mr., Mrs.).

PREFIX  
  The KEY BLOCK will show the Prefix and the Suffix.  DO NOT USE PUNCTUATION IN THE PREFIX OR SUFFIX FIELDS.               

       Example:   Mr William H Smith Jr                                        Dr Jean M Smith PhD  

 Both prefix and suffix should be entered when known, using the lists below.

1.      Prefixes are entered in the Prefix title field, NOT in any of the name fields.  This is a hand typed field no drop down box is provided, PLEASE use the abbreviations listed below.

2.      Use mixed-case format (uppercase/lowercase letters)

3.      If no prefix is provided, the default is Mr or Ms.

4.      In situations where both a prefix and a suffix could be used ie. Dr. and , MD the value should be added in the Prefix field which would leave the Suffix field blank.  Unless otherwise noted by the individual.

5.      Most Lynx reports and processes do not pull the prefix.

6.      Requests for adding a Prefix to the approved list should be directed to the General Person Team Leader, see the referred appendix.

Code	Description
1st Lt	First Lieutenant
Adm	Admiral
Atty	Attorney
Brother	Brother (religious)
Capt	Captain
Chief	Chief
Cmdr	Commander
Col	Colonel
Dean	University Dean (includes Assistant and Associate)
Dr	Doctor (Medical or Educator)
Elder	Elder (religious)
Father	Father (religious)
Gen	General
Gov	Governor
Hon	Honorable (Cabinet Officer, Commissioner, Congressman, Judge, Supreme Court, United Nations US Delegate, Major, Senator, and Representative)
Lt Col	Lieutenant Colonel
Maj	Major
MSgt	Major/Master Sergeant
Mr	Mister
Mrs	Married Woman
Ms	Single or Married Woman
Prince	Prince
Prof	Professor (includes Assistant and Associate
Rabbi	Rabbi (religious)
Rev	Reverend (religious)
Sister	Sister

SUFFIX

1. Suffixes are entered in the Suffix title field, not in any of the name fields.  This is a hand typed field; no drop down box is provided, PLEASE use the abbreviations listed below.
    

2. The suffix should reflect the person’s wishes, if known.
    

3. Do not use a suffix for Doctor, Attorney, etc.  These should be entered in the Prefix title field.
    

4. Use mixed-case format (uppercase/lowercase letters).
    

5. Most Lynx reports and processes do not pull the suffix.
    

6. In situations where both a prefix and a suffix could be used (i.e., Dr. and MD) the value should be added in the Prefix field which would leave the Suffix field blank, unless otherwise noted by the individual.
    

7. Requests for adding a Suffix to the approved list should be directed to the General Person Team Leader.  See the referred appendix.

Code	Description
II	The Second
III	The Third
IV	The Fourth
CPA	Certified Public Accountant
DDS	Doctor of Dental Medicine
Esq	Esquire
JD	Jurist Doctor
Jr	Junior
LLD	Doctor of Laws
MD	Doctor of Medicine
PhD	Doctorate
Ret	Retired from Armed Forces
RN	Registered Nurse
Sr	Senior
DO	Doctor of Osteopathy

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

NON-PERSON NAME/VENDOR

1.   Use mixed case (upper and lowercase letters).  Acronyms are an exception.  See the acronym section that follows. 

2.   Enter the vendor’s name as supplied to you by the vendor.

3.      Enter as presented following these guidelines:

a.   Hyphens may be used to separate double names (i.e., Chase-Brook).  However, add an SPEC alternate name without the hyphen to aid in searches and to avoid duplication.  (Do we even need to deal w/SPEC since a hyphen would be part of the name?)

b.  Spaces are permitted if the legal spelling and format of the name includes spaces.

c.  Apostrophes may be used (e.g., Jack’s Taxi) as an Alternate Name.  The Alternate Name Type should be SPEC.

d.   The Ampersand (&) may be used ONLY when part of a formal name if found on written documentation from the non-person/vendor (e.g., Baltimore & Ohio Railroad.)  Use “and” in all other cases.  (Note: The ampersand (&) is used extensively in data extraction; Use sparingly) 

e.  Only Abbreviate if space is limited (e.g., Co, Corp, Ltd, or Inc) or the official Vendor/non-person name is abbreviated.

Name	Abbreviation
Association	Assn
Company	Co
Corporation	Corp
Department	Dept
Incorporated	Inc
Limited	Ltd
Limited Liability Corporation	LLC
Saint	St
United States	US
University	Univ

4.      Acronyms – Companies that are recognized by an acronym should be entered in the key block using its acronym, e.g., IBM, AT&T.   The whole name of the company should be entered in the SPEC alternate name (e.g., WSU  in Key name…Weber State University in alternate name) to aid in searches and to avoid duplication.

5.      Government Offices – State and County departments and agencies should be entered with the State or County as the vendor.  Each department or agency should be listed as a separate address sequence.

Example 1:                       Utah System of Higher Education
Alternate names of:           USHE
                                        Board of Regents

            Example 2:                       Utah State University
            Alternate names of:           USU

**Various departments within Utah State University, i.e. Library, Controller’s Office, etc., should   be distinguished using the address sequence feature in Banner.  Do not create individual vendors for each department within a University.

            Example 3:                       Utah Department of Employment Security
            Alternate names of:           UDES

            Example 4:                       United States Postal Service
            Alternate names of:           USPS
                                                    US Postal Service

            Example 5:                       Utah Correctional Industries
            Alternate names of:           UCI

            Example 6:                       Association of Schools of Allied Health Professions
            Alternate names of:           ASAHP

Example 7:                       State of Utah
            Alternate names of:           Utah Dept of Revenue
                                                    Department of Revenue

**Agency, i.e. Dept of Revenue, should be listed as a separate address sequence, using one of the address lines for “Dept of Revenue.” 

NAME TYPE/ALTERNATE NAME:

Used to enter all variations of the name such as nickname, maiden name, previous married name, AKA (also known as). 

Code	Description	Definition of Use
AKA	Alias/DBA	Used for Vendors with other names; Doing Business As
MAID	Maiden Name	Used to follow the person’s name changes by marriage.
PREV	Previous Name	Used to follow the person’s name changes, i.e.: marriages, divorces, or legal changes.
SPEC	Name Contains Special Symbols	Used as an alert that the legal name contains symbols that cannot be entered in the Lynx field.  Example: accent over a letter
TAX	Name for payroll & tax forms	Used for W-2, 1098T and other federal/payroll forms
DIR	Directory	Used for campus directory
NICK	Nickname	Displays a nickname to use in searches.
LGCY	Legacy ID	Used to reflect Legacy system ID converted to Banner
ALT	Alternate or Preferred	Used mainly by Alumni Development to store preferred or alternate variations of a person’s name
SPS	Spouse	Used by Alumni Development to aid in searching for constituents
DNC	DO NOT CONTACT	This individual or organization has requested that their name be removed from all WSU contact.  See the comment form for more info.

Alternate Name Examples:

1.      If the person prefers to use his initials, then enter it as an Alternate Name type NICK = Nickname.

Example:          
Herman Isaac Jones would be the KEY Name entered in the Key Block.  Then in the alternate Name block, the name type NICK would be entered as:

First Name:  H
Middle Name:  I
Last Name:  Jones

2.      If the person uses their middle name more frequently than their first name, then enter the middle name version in alternate name.

Example:
Herman Isaac Jones in KEY name
The Alternate name block with the name type NICK would be entered as:

First Name:  Isaac
Middle name:  (Blank or Null)
Last Name:  Jones

3.      If the person has an initial for their first name, enter their middle name as a first name in alternate block.

Example:
H Isaac Jones in KEY name
The Alternate name block with the name type NIC would be entered as:

First Name:  Isaac
Middle Name:  (Blank or Null)
Last Name:  Jones

NAME AND ID CHANGES

For non-legal name changes, utilize the alternate name block to change a person or vendor ID or Name. 

Legal Name Changes

Before making any name change, refer to the form GUASYST to determine the roles of that General Person record.  Name or ID changes are not permitted without documentation

1.        For students this could include social security card, marriage license, passport, driver’s license, and/or other legal documentation.

2.        All persons employed by Weber State University must change their name at Payroll or the Office of Human Resources.  Name or ID changes will not be permitted via the Internet. 

3.        Alumni/Development may change donor and alumni records as needed through individual request, gift processing, or public news resources.

DATE OF BIRTH

The Date of Birth (DOB) is required for all employees and students.  It is entered on the Person form XXXPERS.  See Date Standards.  Reminder: If a DOB is not available, leave the field blank (null).

CITIZEN TYPE (USHE Element S-09, Citizenship Status)

 

Citizen type is required for all students and employees. Citizenship Type requires appropriate documentation. A person’s citizenship is entered on the Person form XXXPERS.  Valid values are found in the validation table STVCITZ.

 

Code	Description	Explanation
1	U.S. Citizen	An individual who is a citizen of the United States only, regardless of how his/her status was acquired.
2	Non-Resident Alien	An individual who is not a citizen or national of the United States and who is in this country on a Visa or temporary basis and does not have the right to remain indefinitely.
3	Resident Alien or Other Eligible Non-citizens	A person who is not a citizen or national of the United States and who has been admitted to the United States as a legal immigrant for the purpose of obtaining permanent resident alien status (who holds either an alien registration card (Form 1-511 or I-151), a Temporary Resident Card (Form I-688), or an Arrival-Departure Record (Form I094) with a notation conveying legal immigrant status.  This category includes those with Refugee, Asylee, Conditional Entrant Parolee, or Cuban-Haitian Entrant status.
4	Undocumented	An individual who is not a citizen and who has not yet obtained permanent resident alien status.  However, he/she is exempt from paying the non-resident portion of tuition pursuant to Board of Regents policy R512-12 and Legislative Bill S3B-8-106.
9	Other	Student is currently defined as Other

 

MARITAL CODES

Valid values are found in the validation table STVMRTL. Note:  when marital status changes, a name change may also be needed. 

Code	Description	Explanation
D	Divorced	Once married but now legally divorced
M	Married	Legally married
X	Separated	Legally married but living apart
S	Single	Never legally married
W	Widowed	Legally married and spouse is deceased
N	Not known	Information not available
L	Life Time Partner	Not legally married

 

LEGACY CODE

This field is not being used at present.  Do not populate.

 

ETHNIC CODES (USHE Element S-14, Ethnic Origin)

(These codes used for U.S. citizens only and not for non-U.S. citizens.)

Weber State University’s procedures require the ethnic code be entered for all students and employees.  A person’s ethnicity is entered on the Person form XXXPERS.  Valid values are found in the validation table STVETHN.

 

	Description	Explanation
I	American Indian or Alaskan Native	A person having origins in any of the original peoples of North America and South America (including Central America) and who maintains cultural identification through tribal affiliation or community recognition.
A	Asian or Pacific Islander	A person having origins in any of the original peoples of the Far East, Southeast Asian, or the Indian subcontinent including for example Cambodia, China, India, Japan, Korea, Malaysia, Pakistan, the Philippine Islands, Thailand, and Vietnam.
P	Native Hawaiian or Pacific Islander	A person having origins in the original peoples of the Hawaii, Guam, Samoa, or other Pacific Islands.  The term does not include individuals who are native to the state of Hawaii by virtue of birth.  The category also includes the following Pacific Islander groups:  Carolinian, Fijian, Kosraen, Melanesian, North Mariana Islander, Palauan, Papua New Guineas, Ponapean (Pohnpelan), Polynesian, Solomon Islander, Tahitian, Tarawa Islander, Tokelauan, Tongan, Trukese (chuukese), Yapese.
B	Black, Non-Hispanic	A person having origins in any of the Black racial groups of Africa.  Terms of Haitian or Negro are acceptable response options.
H	Hispanic	A person having origins of Mexican, Puerto Rican, Cuban, Central or South American, or other Spanish culture.
W	White Non-Hispanic	A person having origins in any of the original peoples of Europe, the Middle East, or North Africa.
U	Unspecified
N	Non-Resident Alien	?? current in PROD – Why??

 

VETERAN FILE NUMBER

This field in the General Person Record is not being utilized.  Do not populate.

DECEASED INFORMATION CHECKLIST
 

1. Check GUASYST to see what other areas have transactions posted. 
    

2. If the person exists in the HUMAN RESOURCES module, then ONLY HR should mark the deceased flag in the system.  Other areas should contact Marilyn Ryan, extension 7012 or mryan@weber.edu, to inform Alumni Development of the deceased alumni.
    

3. NOTE:  www.ancestry.com can be used to verify the date of death by checking the SSN Deceased Database.

SEE “HOW TO” APPENDIX FOR ALLUMNI/DEVELOPMENT DECEASED CHECKLIST

---

VI. Address Standards

INTRODUCTION

LYNX permits multiple address types to be entered for a person or vendor.  Each address can have different effective dates. Note:  BI address type can have more than one active address at a time.  All other address types can only have one active address.

The use of each address type must be strictly defined so that conflicts do not arise among the various functional areas. As a user having permission to update address data, one can update all address data.  Lynx does not restrict address updates by functional area.  Therefore, it is critical for the user to ensure that the most current appropriate address is available for all areas.  Procedures must be in place to ensure areas making address changes are done correctly.  User must follow the procedures as defined by the owner of that address database.  GOAADDR can be used to review recently updated addresses to ensure that the data entry standards are being applied. 

If using one or more of the “Web For” products, there is a rule form to identify which address types can be viewed and/or updated for each system.

NOTE: For reports GTVSDAX should be updated.

ADDRESS TYPES

Addresses are entered in the Address Information Block on XXAIDEN or in FTMVEND.  For additional information on address standards required by the U.S. Postal Service, check their web site at https://www.usps.gov.ncsc/pubs/.  You will find the web site to be a valuable resource.  Multiple addresses can be entered for a person or vendor by using different address types. Address standards have been established cooperatively so that address types are used consistently.  Use the appropriate address type code from the STVATYP table as recreated below.

PERSON & NON-PERSON ADDRESS TYPES

NOTE: there are certain address types that are system required:  BI, BU, MA.

CODE	DESCRIPTION	EXPLANATION
AB	Alumni Business	Maintained by Alumni/Development.  This address is the Business/ Organization’s permanent address.  If the mailing address is a PO Box, AM should be used.
AM	Alumni Mailing	Maintained by Alumni/Development. Mailing address (e.g. PO Box).  Created if a Constituent or Organization has a PO Box or another address where they would like to receive mail.
AP	Alumni Permanent	Maintained by Alumni/Development. Primary residence for a constituent, this should not be a PO Box.
AW	Alumni Work	Maintained by Alumni/Development.  Used to store an address where a constituent works.  It may be a PO Box when it applies.
AS	Alumni Seasonal	Maintained by Alumni/Development.  Used to store seasonal (recurring) address for individuals who spend part of year at a different address
PR	Permanent	Primary residence address for individual/constituent; can NOT be a PO Box.  Exception granted on a case-by-case basis for WSU Employee only and for safety/security concern.
MA	Mailing	Mailing address (e.g. PO Box).  Created if different from Permanent.
MC	Mail Code	Campus mail code address
PC	Paycheck	Maintained by Payroll Office.  Created if payroll check is mailed to address different from Permanent, Campus, and Mailing.
BI	Billing	Maintained by AP and Purchasing.  Created if billing address is different from Permanent.  Used to mail invoices, statements and vendor checks.
BU	Business	Maintained by Purchasing. This address is the Vendor/Business/ Organization’s permanent address.  If the mailing address is a PO Box, MA should be used.
VC	Vendor Check	Maintained by AP.  Used to mail vendor checks if different from billing address.
EM	Emergency	Address used for emergency contact
MG	Matching Gift	Maintained by Alumni to store address for Matching Gift Office of Corporation.
PA	Parents	Used by Student system
GR	Grants and Contracts	Used to identify the addresses needed to submit invoices to granting agencies
XX	Reserved for TGRFEED	Used by Student A/R system only

STREET STANDARDS

All information is typed in upper/lower case format, i.e., not all caps or all lower.

Special Characters.   The period (.) cannot be used when entering the number portion of an address.  The following is an example:  

39.2 Rd            use       39-2 Rd

Symbols:

Ampersand – Only use the symbol "&" rather than spelling out "and" when it is appears in an official document. 

Percent -  “%” (in care of) should not be used.  Use “c/o” or "In Care Of". 

 Secondary Address Unit Designators - If the address is multi-unit apartment or building, place the room, suite, or apartment number to the right of the street address.  If the secondary unit designator is not provided and only a pound sign (#) along with the number is provided, i.e., 3454 N. Jones #4, then remove the (#) and replace it with the abbreviation for number (NO).  NEVER use the # sign. 

 

If the apartment number or suite number make the address line too long please follow the below example.  The post office reads an address from the bottom up.

Dr John F Smith
Apt 305
1379 Del Monte Ave
Lancaster, CA 93536

UNIT DESIGNATORS ABBREVIATIONS

Code	Description	Example
Apt	Apartment	102 Main St Apt 101
Bldg	Building	1600 Central Pl Bldg 14
Dept	Department	Florida Tech Accounting Dept
Fl	Floor	2700 College Blvd 4th Fl
Rm	Room	55 Sylvan Blvd Rm 18
Sp	Space	454 N Jones Rd Sp 6
Ste	Suite	1356 Executive Dr Ste 202
No	Number	4170 Cherry La No 26

DIRECTIONS ABBREVIATIONS

Compass directions used to identify the geographic area of a city are always abbreviated.

Code	Description
E	East
W	West
N	North
S	South
NE	Northeast
NW	Northwest
SE	Southeast
SW	Southwest

Street Address and PO Box - Non-person LYNX address format allows three lines of street address information.  Three address lines cause a problem when printing one-inch labels.  If both the street address and PO Box number need to be maintained, enter the street address as the Permanent Address (PR) and the PO Box number as the Mailing Address (MA).

Do not enter data into the second address line until data has been entered into the first address line.  Only use the first two lines.

Example:
When the following information is given

Dr John F Smith
Evergreen Bldg
1379 Del Monte Ave
PO Box 2351
Lancaster, CA 93536

Add it into the appropriate boxes as shown below

Permanent Address (PR)	Mailing Address (MA)
Dr. John F Smith Evergreen Bldg 1379 Del Monte Ave Lancaster, CA 93536	Dr. John F Smith PO Box 2351 Lancaster, CA  93536

Note:   Mail is delivered to the address immediately above the City, State and Zip Code line.

For additional information, please refer to Street Address Abbreviations in Appendix A.

Numeric Street Names - When the street name is a number, add an abbreviated ending in lower case letters.

            Example:          2 nd, 23 rd, and 40 th

Rural Routes - The following addressing format is used for rural routes address: RR____, BOX____.  Do not use the words ‘RURAL,’ ‘RUTA RURAL,’ ‘RFD,’ ‘BUZON,’ OR ‘BZN.’  A leading zero before the route number is not necessary.

            Examples:         Incorrect                                              Correct

                                    Ruta Rural 3 Buzon 12000                    RR 3 BOX 12000
                                    RR02 Box 9800                                   RR 2 BOX 9800
                                    RFD 1 Bzn 17-A                                  RR 1 BOX 17A

There should be no additional designations, such as sector names, on the delivery address line of rural addresses.  Using sector names with rout and box numbers can create potential matching difficulty.  Mailers are required to use only one style of addressing.  Eliminate unnecessary information.

            Examples:         Incorrect                                              Correct
                                    RR 2 Box 1980                                    RR 2 BOX 1980
                                    SECTOR EL BRINCO
                                    RR 3 BOX 3415                                  RR 3 BOX 3415
                                    BARRIO VISTA ALEGRE

CITY STANDARDS
 

City will be populated by using the Zip Code talbe GTVZIPC so that consistency and accuracy can be maintained.   

Do NOT enter Canadian Provinces into the City Field.  Canadian Provinces are Alberta, British Columbia, Labrador, Manitoba, New Brunswick, Newfoundland, Northwest Territories, Nova Scotia, Ontario, Prince Edward Island, Quebec, Saskatchewan and Yukon and they will 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 Field.  Enter the code (Canada) into the Nation field.  For additional information please refer to Appendix C.

 

All other international addresses should NOT populate the City field.  The second address line will hold City and PIN (Postal Identification Number). See Zip Code Standards for more information.

STATE & PROVINCE STANDARDS

State codes MUST be entered for all U.S. and Canadian addresses using GTVZIPC to pull the appropriate STATE or PROVINCE code. (As of June 2004, Provinces are not loading from GTVZIPC.)  Refer to Appendix C for the appropriate U.S. states and Canadian province codes from the USPS.

All other international addresses should NOT populate the State field.  There is no State in international addresses, use the Nation field. See Zip Code Standards for more information.

ZIP CODE STANDARDS

GTVZIPC is maintained by Data Administration.  Please contact the Data Base Administrator when a new zip code needs to be added.

Zip codes MUST be entered for all U.S. and Canadian addresses using GTVZIPC to pull the appropriate zip code.

United States

Enter the five (5)-digit zip code.     Example:      97203

WSU has employed a program that utilizes the 5-digit zip code to update the City and State fields.  This will help with data integrity and consistency.  The Plus-4 digits of the zip code should be entered after the City and State have been uploaded to the address.  Adding the Plus-4 saves WSU money and time.  It is recommended to add the Plus-4 digits whenever possible.  To research the Plus-4, go to https://usps.com/zip4/.  Remember to insert the hyphen when adding the Plus-4 to the zip code.

Canadian

Enter the six-character zip code.  Do not add spaces or hyphens in Canadian zip codes.                        Example:            T2T2Y5
                          R2L1N4

International Pin Numbers

Enter the international postal identification number (PIN), which ranges from four to six digits (without hyphens) in the second address line.  The second address line should have both the city and the PIN.  Do NOT enter the PIN number in the zip code field.  In the event the PIN number will not fit to the right of the city because of space, enter the city on the second address line and enter the PIN number on the third address line.

 

Example:          Petko Metodiev Kitano
                        PO Box 140
                        Balgoevgrad Hyderab
                        2700
                        Bulgaria
 

Below is an example of correct layout and punctuation for a US address.

Example Address

Sample Address                                               Data Entry Format

            Larry R. Adams                                                Larry R Adams
            123 East Fir Street, Apartment #6                    123 E Fir St Apt 6
            Lancaster, CA  93536-1234                            Lancaster, CA  93536-1234

NATION CODE STANDARDS

Do NOT enter a NATION code for U.S. addresses. A NATION code is required for all non-U.S. addresses.  A complete listing of Nations can be found in Appendix D.

MILITARY STANDARDS

 

Foreign Military Address

            Enter the APO or AFO code into the  CITY field.

            In the State Field enter:
                        AE - Europe, Middle East, Africa, Canada                   [ZIP=09nnn]
                        AP - Pacific                                                                  [ZIP=96nnn]
                        AA - The Americas (excluding Canada)                        [ZIP=34nnn]

            Example:          Alice VanFrogulemen
                                    HHB 6th Batallion 43rd Box 72
                                    Air Defense Artillary CMR 417
                                    APO AE 09602-8802

United States Military Address

            Enter the APO or AFO code into the CITY field.

            Enter the normal state code into the State field.

             Example:         APO (AA, AE, AP) Nine Digit ZIP code
                                    FPO (AA, AE, AP) Nine-Digit Zip code

                                    AE for mail going to EUROPE, the MIDDLE EAST, AFRICA and CANADA (090 thru 098)
                                    AP for mail destined to the Pacific (962 thru 966)
                                    AA for units in the AMERICAS other than CANADA (340)

            Example:          APO AE 09815
                                    APO AA 34030
                                    FPO AE 09508
                                    FPO AP 96522

             Air Force Base (AFB)

            Enter the City into the City Field followed by AFB (all CAPS) for Air Force Base. 

            Example:         5 202A 2nd St  
                       Hill AFB
                       UT  84506-1207

ADDRESS CHANGE SOURCE TYPES

All users will use this list to track where an address or address change originated.  When a campus individual informs you of an address change, when possible please find out how they received the information.  Example: If you are told by the president’s office of an address change, try to find out how they were notified and use that as the source, rather than “president’s office.”

Abbreviation	Description	Banner Local Help	Who Should Use in Banner
INDV	Individual	Person/Constituent informs WSU of address change, by phone, mail, e-mail or web.  Alumni/Development: If you are informed of address update from someone other than the individual, ask where they obtained the information & mark address change appropriately.  Ex: Development officer informs you a constituent has new address.  Find out where they obtained their information.  If individual told them, this address change should be marked INDV, not OTIN.  Ex: Development officer informs you a constituent has new address.  They got the information by writing it down when visiting.  This should be OTIN not INDV.	All modules
BUS	Business	Non-person/vendor/organization informs WSU of address change by phone, mail, e-mail or web. Alumni/Development: Letterhead would fall in this category, but an update from a donation check would fall under ADGP.	All modules
ADGP	Gift Processing	Address change originated from, or a change was confirmed through, the gift processing staff by check, stock information	Alumni/ development Gift Process-ing Staff only
PO	Post Office	Information was received	All modules
PHCO	Phone Company	Information was received by searching phone company records either through the phone book or on the Web.  This also includes messages forwarding you to another number provided by the phone company.	All modules
OBIT	Obituary	Address change was made due to person/constituent being deceased & confirmed through an obituary.	All modules
WIND	Weber Individual	Address Originated from or changed by information received from WSU faculty member, staff or volunteer.	All modules
OTIN	Other Individual	Address originated or changed made from information received from someone other than the individual, such as a family member, employer or employee.  This should be used only if we are unable to confirm where the “Other Individual” received the information.	All modules
ADPH	Alum/Dev Phonathon	Address was changed due to information received from an alumni or development phonathon.  This is separate from Individual for tracking how many changes are made through phonathons.	Alumni/ Development Gift Processing Staff only
ADHD	Harris Directory	An outside vendor used by Alumni/Development	Alumni/ Development Gift Processing Staff only
WEBS	Web Search	Address change found through Web Search using tools other than phone company, including such companies as AnyWho, SearchBug, Lexis-Nexis, etc.	All modules
ADNC	NCOA	An outside vendor used by Alumni/Development	Alumni/ Development Gift Processing Staff only
AD1D	1sr Direct	An outside vendor used by Alumni/Development	Alumni/ Development Gift Processing Staff only
STAA	STAARS	Address originated from or changed due to information in STAARS	All modules
WGRP	Weber Group or organization	Address originated from or changed due to information provided by another WSU campus group, department or organization	All modules
ADMM	Other Group or Organization	Address originated or changed due to information provided by off campus group or organization and could include lists obtained from other “Arts” organizations.	Alumni/ Development Gift Processing Staff only

 

---

VII.        TELEPHONE TYPES

INTRODUCTION

When an address is entered on the XXAIDEN form, the phone number can be entered as well.  The address type and the telephone type should match.  However, additional telephone numbers can also be captured and entered on the XXATELE form.  For example, CELL or FAX may not have an address but are important numbers to be stored.

Code	Description	Explanation
HOME	Home	This number will be used to reach a person or constituent at their current place of residence.
WORK	Work	This number will be used as the primary phone number for a Business/ Vendor/Organization or to reach a person/constituent at their place of employment.
CELL	Cell	This number will reach a person/constituent on their cellular phone.
FAX	Fax	This number will be used for either home or work faxes.  Use comments to clarify where the fax machine is located.
WAST	Work Assistant	This number should be used to reach a person/constituent’s secretary, administrative assistant, receptionist, etc.  Use comments to clarify.
ALT	Alternate	This should be used for any number that does not fall into the other categories.
OSV	Outside Vendor	This number will be used by Alumni/Development to track the source of phone numbers that are provided by outside vendors.  Use comments to clarify what source the phone number came from.
PGR	Pager	This should be used to reach a person/constituent by electronic pager.
PRNT	Parents	This number should be used to reach a person/constituent at their parent’s home(s).  For Student, if the student is living at home, capture this number under the HOME type.  If they move from their parent’s home, change HOME to PARENT and add a new HOME.
TOLL	Toll Free	This will be used to track toll free numbers of persons/constituents or Non-Persons/ Vendors/Organizations
TZ	Time Zone	This is usually from an outside vendor.  Alumni/Development uses this number to determine what time zone a constituent is in and will use comments to capture the information.
INTL	International	This will be used to track international numbers of person/constituents or Non-Persons/Vendors/Organizations.
EMER	Emergency	This number will be used when WSU needs a phone number in “case of emergency”.
CAMP	Campus	This should be used for the campus work extension
GR	Grants and Contracts	Used to identify the addresses needed to submit invoices to granting agencies
BU	Business	This number will be used as the primary phone number for a Business/Vendor/Organization.
BI	Billing	This number will be used to store the phone number for a Vendor Accounts Receivables department.

E-mail Types

 

E-mail addresses are entered in the E-MAIL Information Block on XXAIDEN.  GTVEMAL stores the e-mail types that can be used.

PRE	Alumni Preferred	Used to store e-mail address preferred by person/ constituent to receive WSU e-mails
HOME	Home	Used to store e-mail delivered to person/constituent’s home
WORK	Work	Used to store e-mail delivered to person/constituent’s work/business
GRP	GroupWise	Used to store GroupWise e-mail
STU	Student	Only used to store student’s WildCat e-mail address.  These are system generated and populated e-mail accounts.
BUS	Business	Used to store e-mail address for Business/Vendor/ Organization
OSV	Outside Vendor	Used by Alumni/Development to track e-mail addresses that are obtained by outside companies
WSIT	Web Site/Page	Used to store a web site/page address for individuals or businesses
DDP	Direct Deposit	Used by HR to store e-mail that delivers electronic direct deposit notice to employee

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

---

APPENDIX E -- CONFIDENTIAL FLAG 

Because of FERPA regulations regarding the confidentiality of student records, this flag is very critical. 

The Confidential Flag, which is set on the XXPERS screen, will be added by Student records or Human Resources and may be used by other offices, such as Alumni/Development.  A warning message box will appear the first time the record is viewed and the confidential information will be visible on every form related to the individual.

This Flag indicates that a person wants all or part of their record kept confidential, that they want some or all of their information blocked from the Campus Directory and/or wants some or all of their information to NOT be published in other document.

APPENDIX F -- COMMON FORMS

Maintenance Form Considerations

GUASYST

The General Person System Information form shows all LYNX modules where data is entered on a specific GID.  This is helpful for tracking the progress of student applications or determining quickly what role an individual or entity plays at Weber State University.

Duplicate Records – Use this form when diagnosing possible duplicate records to determine which areas have transactions posted on the record.

GUAIDEN

The General Person Identification form lists all staff members who either update or query the Lynx database.  It is critical to the Alumni/Development system and used in prospect management and events management.

GTVZIPC

This table keeps the city/state/zip and county information and must be kept current.

 
APPENDIX G -- DUPLICATE RECORDS

When duplicate records are found or suspected, forward the W numbers of each record to the assigned person in your area on the multiple PIDM clean up hierarchy shown below.  You might want do a print screen of both records using GUASYST.  This screen lists what transactions are shown for each record.

GUASYST - Multiple PIDM Clean up Contacts
Precedence	Module	Contact for Cleanup
	General Person	Michelle McKenzie, MC1135, x7792 email requests to generalperson@weber.edu
	Human Resource
2	Applicant	NA
1	Employee	Nancy Hadley, MC 1021, x6031
1	Beneficiary	Travis Hampshire, MC 1016, x6648
	Cobra Person	NA
	Finance
	Agency	NA
	Bank	NA
	Customer	NA
	Employee	NA
	Financial Mgr	NA
3	Vendor	Toni Thompson, MC 1014, x6605
	Accounts Receivable
4	AR	Cindy Brewer, MC 1014, x6632
	Financial Aid
5	Applicant	Jayne Mook, MC 1136, x6583
	Student
	Recruiting	Sara Padilla, MC 1137, x6745
8	Admissions
6	Transfer Work
6	General Student	Stella Tarwater, MC  1102, x6755
7	Registration	Alina Meyer, MC 1139, x7585
	Housing	NA
	Faculty	Betty Kuznierz, MC 1004, x7124
	Advancement
9	Constituent	Marilyn Ryan, MC 4018, x7102 Carol Ruden, MC 4018, x7135
9	Organization

Scripts will be processed to determine all tables that are affected.  The record to be kept will need to be identified and the “bad record” will be flagged.  If there are financial transactions, the record cannot be deleted.  The flagged record will be noted as “Bad Record – Do Not Use.”  Each office that has transactions will then be contacted.  The information will need to be moved from the bad record to the good record.

Note:  In Internet Native Banner (INB), the code of MPID is entered into the Prefix field of the Key Name and the Name Type Field for the "bad" record on SPAIDEN when there are duplicate records for a person or entity.  DO NOT CONTINUE TO ADD DATA TO THE BAD RECORD!  Use the alternate name type to find the good record (the W number will be recorded there) and add data to that good record. 

APPENDIX H (Word Document)

 

WEBER STATE UNIVERSITY
Employee Confidentiality Agreement
University Relations

            In consideration of my employment and/or continued employment at Weber State University (the "University"), I agree as follows:

            1.         For purposes of this Agreement, "Confidential Information" is defined as information disclosed to me, accessed by me, or otherwise known by me as a consequence of my employment, and not generally known outside the Alumni Relations, University Development and/or University Communications offices of the University. It includes but is not limited to information accessible through the Raiser’s Edge database, FRS System, HRS System, and STAARS System of the University, or their successors, and specifically includes individual social security numbers.
            2.         During my employment and after the termination of my employment, I will hold the Confidential Information of the University in trust and confidence, and will not use or disclose it or any embodiment thereof, directly or indirectly, except as may be necessary in the performance of my duties for the University. I understand that unauthorized disclosure could be highly damaging to the University, its faculty, staff, students, donors, or others.
            3.         I will not remove materials containing Confidential Information from the Alumni Relations, University Development and/or University Communicationsoffices, unless authorized to do so by my supervisor. Any and all such materials are the property of the University. Upon termination of any assignment or as requested by my supervisor, I will return all such materials and copies thereof to my supervisor.
            4.         I agree to safeguard personally-identifiable data, Confidential Information, the official records in the custody of the University, and the means and conditions of custodial security, and I agree to keep such information and means secure and strictly confidential at all times, whether on or off duty.
            5.         I understand that if I violate this Agreement, I may be subject to disciplinary action, legal action, or both.

            IN WITNESS WHEREOF, and intending to be legally bound, I have executed this Agreement on this ____ day of ______________________, 200___.

EMPLOYEE:                                                             VICE PRESIDENT OF UNIVERSITY RELATIONS:

__________________________________                   ____________________________________
(Signature)                                                                    (Signature)

_______________________________                          ____________________________________
(Typed name)                                                               (Typed name)
 

APPENDIX I -- DECEASED INFORMATION CHECKLIST

1.      The deceased flag stops various processes in the system.  The timing of setting the deceased flag is critical in relationship to these processes.  The hierarchy below, shows the priority of who should set the deceased flag, based upon which module is affected in GUASYST.  ONLY THESE INDIVIDUALS should set the deceased flag!

Priority	Module	Name	e-mail
1	Human Resources/Payroll	Ben Read	bread@weber.edu
2	Finance/AR	Cindy Brewer	cbrewer@weber.edu
3	Financial Aid	Tula Paras	tparas@weber.edu
4	Active Student	Jane Stout	jstout@weber.edu
5	Advancement	Marilyn Ryan	mryan@weber.edu

2.      Upon receiving notification that an individual has died, check GUASYST to determine which modules are affected.  The module with the highest priority should be notified and is responsible for processing the deceased person record as outlined below.

Deceased Person Process

1.      Confirmation of death is required, which may be obtained through a death certificate, obituary, social security death index, etc.

2.      Upon confirmation of death, mark record as confidential on xxxIDEN and place an explanation of confidentiality in the comment form, SPACMNT.

3.      The responsible person for the module then contacts the others from the above list, as checked on GUASYST, for the deceased individual.

4.      Within the modules, clean up and marking of the person’s record and additional campus notification processes should be executed as outlined by internal departmental policy.

5.      Only upon completion of processes required by the Banner system (final payroll, refunding of tuition, etc), should the deceased flag be set on xxxPERS by the responsible person for the module.  Include the date of death.

6.      Once the deceased flag is set, all addresses on xxxIDEN should be in-activated with an end date equivalent to the death date entered.

7.      NOTE:  www.ancestry.com can be used to verify the date of death by checking the SSN Deceased Database.

“HOW TO” APPENDIX

SEARCHES:

ID Search

Select an Identification (i.e., IDEN) or VEND form in your module.

If ID is known, enter in KEY BLOCK to see if a match is found.

Person Name Search

Two search methods are available:

1.      If the ID is not known, TAB to the field to the immediate right of the ID field, which is the NAME field. Here the user may enter as many characters of the last name as desired. If the entire last name is not entered, it must be ended with a percent (%) symbol. Pressing the ENTER key will open a ‘SEARCH RESULTS’ window which will show a pull-down and the number of records found which match the search criteria. If the number of records found is greater than 25, the search should be narrowed by providing additional information in the Reduce Search By panel. Here the user may indicate City, State, Zip, Name Type, SSN (if not used as the record key), Date of Birth and Gender (partial criteria followed by ‘%’ is accepted). After data is entered to reduce the search, the SEARCH icon can be pressed with the left mouse button and the records found should display a lower number. Whether or not additional criteria is provided, pressing the pull-down will display a list of the matching records. The list will display CURRENT names as right justified and PREVIOUS names as indented. Double clicking with the left mouse button will select the desired record and place it in the key block of the IDEN form.

2.      Left clicking on the SEARCH icon of the “SPRIDEN” or “FTMVEND” Form will display an Options List for a Person Search or Non Person Search. Choose one. This will display either the SOAIDEN (Person Search Form) or SOACOMP (Non-Person Search Form)

Search criteria can be entered in any of the fields displayed, with or without “%” wildcards.

Type in the name to be searched using the % (wildcard) to broaden the search. 
Example:  record = John Smith

Query as:  Last Name – Smith
                First Name – J%

1.      Highlight the line that matches and double click the left mouse button to return to the main screen.

2.      Check to be sure the data matches the data you have used.  NEXT BLOCK to display information (if there are multiple entries for address, etc.)

3.      Input new data according to guidelines in this manual and the needs of your particular functional module.

4.      Update/correct any information, such as PERS data that may be missing.

To create a record if no match is found:

1.      Try another version of the query; if still no match---return to main screen (CANCEL QUERY) and go to an IDEN screen to create the record.

2.      Click on  the “Generate ID” icon.  The word “GENERATED” will appear in the ID field.  Click the mouse in name fields and type in name and press COMMIT (create the record.)

3.      Add the name in upper and lower case letters, using punctuation and spacing as appropriate.   If no first name is available (foreign names), put a dash (-) in the first name field.

4.      Enter any alternate names (nickname, AKA etc.)

5.      Create address(es) in appropriate fields---consult Quick Reference Section for recommended abbreviations.

6.      Abbreviate when space limitations require it.

Add information to XXPERS screen for person records.

IDENTIFICATION NUMBER CORRECTIONS

If you’ve made an error in the identification number when adding a person or non-person, the process for correcting is as follows:

1.      Change the ID field in the Current Identification block to read correctly.  Save your change.

2.      Click on the “Alternate Names/IDs”  ‘go to’ option.

3.      Click the Alternate Remove button on the record where the Change field is ‘ID’ and the Activity Date is today’s date.  Save your changes.  Roll Back.

 

If you discover an error in the identification number on a record that already exists, make the changes, but do not remove the previous ID that is in error.  Do a screen print of the record and notify your supervisor of the change.

Supervisors:  Check GUASYST to see if the record belongs to other modules and contact applicable data custodian to verify that the incorrect ID can be deleted.

ENTERING A NAME CHANGE

1.      Name changes are permitted with appropriate documentation (i.e., social security card, other legal documentation from the person).

2.      All employees must change their name at the Payroll or Human Resources office.

3.      Legal name changes are not permitted via Lynx self-service functions except that name changes for alumni are permitted via the internet.

4.      Alumni/Development may change donor and alumni records as needed; however, they will communicate with the other data custodians as needed.

5.      If a name change is merely a spelling correction or changing the middle initial to spell-out the middle name, make the change and save it.

6. Otherwise, the process for making a name change is as follows: 
    

   1. Click on the “Alternate Names/IDs” ‘go to’ option.
       

   2. Locate the incorrect record to be deleted.  Click on the Alternate Remove button.
       

   3. If it is a valid change of name, then make and save the change.
       

7. If you know the Name Type, then click on the “Alternate Names/IDs” option, find the original name and fill in the appropriate Name Type (e.g., MAID …maiden name).

ALUMNI/DEVELOPMENT DECEASED CHECKLIST 

1. Separate the Spouse when linked.

a.       In the Spouse’s record using APACONS, change the xref code to SPL (spouse living.)  The deceased will have a corresponding xref SPD (spouse deceased.)

b.      Change the Marital Status to Widow/Widower.

c.    Using APANAME and APAMAIL, update the Gift Society Name, combined mailing name and salutations where needed.

2. In the Deceased’s record:

a.       Inactivate all addresses.

b.      Using APAPERS, add the DATE and DECEASED FLAG.

c.       Using APACOMT, enter a comment regarding the source of the information (obituary, family member, etc.)

d.      Using APANAME and APAMAIL, update the Gift Society Name, combined mailing name and salutations where needed.

3. Notify the Development Officer if the deceased is their prospect.
    

4. If the Deceased has an alumni membership, notify the Alumni Office.

 

ADDRESS CHANGES

Address changes are entered in the address information block on XXAIDEN.  The source of the change can also be entered.  Sources for valid address change values are found in the table STVASRC.  Do not overtype the existing address, but instead, inactivate the address by entering the TO date (current date), entering a code in Source field and SAVE.  Do record insert to get blank space and type in the new address and phone number.