Administrative Systems Data Standards

DSG Home

DSG Members

Data Standards

Links

1College Project

Institutional Research

Banner General V7.5

Data Standards Group

The Administrative Systems Power Users Group is charged with designing, maintaining, coordinating, and supervising the manner in which we enter and code institutional data. Our goal is to standardize processes across computer systems and across departments so that the institution can accurately report out information and analyze data. The group includes representatives from key administrative and technical offices involved in data collection at Dickinson. These include Admissions, Development, Financial Aid, Financial Operations, Global Education, Human Resources, Institutional Research, Institutional Systems, Public Safety, Registrar's Office, and Residence Life. The group is chaired by the Director of Institutional Research because that office is ultimately responsible for external reporting and analyzing institutional data. The group reports to and advises the Director of Institutional Systems.
The Administrative Systems Power Users Group reviews the policies and standards for data entry in Banner a minimum of twice a year.  Questions or concerns regarding these standards or how these standards might affect existing jobs, workload or data entry, should be reported to the Data Standards Group member associated with your department as soon as possible. These issues, especially those that affect multiple departments, will be brought to the Data Standards Group for immediate discussion.
The Data Standards Group makes its decisions using the following guiding principles in line with Dickinson's goal to be a unified and integrated college:

Data Coding Standards

The Dickinson College Data Standards Guide is a document to aid continuing and new employees in performing their data maintenance functions.  Data standards are vitally important in protecting the data assets of the institution and the College takes seriously upholding those standards.  The college’s ability to report and use the data in our enterprise systems and data warehouse are dependent on the adherence to the standards outlined in this guide.
It is the intent for this guide to be a living document with the review of each standard occurring on a regular basis.
This document will be maintained electronically and will be available to anyone interested. Coordinating data entry standards training for persons granted modify access to Banner is the responsibility of each department manager and should include directions on access to and the contents of this document.

• To differentiate from a data configuration or coding standard and data entry standards, data entry standards are italicized.

• Most recents changes adopted by the adminsitrative Power Users Group will appear in a red font.

About Forms
Banner uses forms for data entry and viewing. A form is what a user sees on his/her computer screen when using the Banner system; although a form can have multiple windows. Each form is assigned a 7-character code. The first character indicates the primary module/owner of the form such as "G" for General (shared across modules), "S" for Student (many of which are also shared across modules), "A" for Advancement, "F" for Finance, "P" for HR/Payroll, "R" for Financial Aid, etc. See Banner documentation for more information on form/table naming conventions.

About Validation Tables
Banner uses validation tables to store codes for certain valued fields. A downward arrow appears next to these fields on the Banner screens. If a user clicks on the downward arrow, the list of values (LOV) for that field appears. The LOV includes the validation code and validation description. This document includes the common validation tables used across Banner modules. Like forms, Banner uses naming conventions for corresponding validation tables. Tables beginning with "G" are general tables shared across modules. Some common tables begin with "S" because they were originally in the Student module in early versions of Banner but are now shared across modules. Tables specific to one module (Student, Advancement, etc.) are not included in this document unless the Power Users Group has been asked to review them by the department.

In a validation table there is a column with a check box labeled "system required." The system required value is delivered by SunGardHE because it is used in some delivered process and cannot be changed by the user (for example, IPEDS reporting). DO NOT CHECK THE SYSTEM REQUIRED BOX BY MISTAKE BECAUSE ONLY A SYSTEM ADMINISTRATOR CAN UNCHECK IT.

About Coding
In developing codes for the validation tables, it's important to keep several things in mind. First, each table differs in how many characters can be used for its validation code. They can vary from 1 to 30. Second, decide whether it makes more sense to use numbers, letter codes, or a combination of numbers and letters. Third, remember that Banner automatically sorts the codes in ascending order (numbers first, then alphabetically). Since data entry staff will need to go through the list of values for a coded field, try to make the most common codes appear at the top of this list, or make the codes simple enough that they can be easily memorized.

Null Values
This document assumes that null values in Colleague/Benefactor will be imported as null values unless otherwise specified in the validation table.

Identification Numbers

Banner ID Number
Each person and non-person record in Banner has a unique identification number. Banner uses a one-up numbering sequence of up to 9 character spaces. The first character can be either a number or letter. It will remain constant for all ids. After the first character, the system uses a one-up numbering sequence in which Banner generates an 8-digit number sequentially.

The Data Standards Group reviewed many options for defining ID numbers. The group was concerned, at first, with using a number as the constant first character because it might coincide with an existing social security number which certain third-party systems use. Initially it was decided to use the letter "D" for Dickinson, followed by the 8-digit number. However, concern was later raised that this would cause an unnecessary burden for data entry staff who used the number pad to enter ids into the system. Consequently, the group opted to use the number "9" followed by the 8-digit number. Since the Social Security Administration currently does not use the 900 sequence and the third-party system in question (CBORD) is phasing out the use of social security numbers as the primary ID, it was decided that this was the best long-range option. The first ID number generated by Banner was 900000001.

For  lenders  used in the Financial Aid Office, Banner ID numbers are created using the six-digit Commonline  lender code. For guarantors,  the Commonline three-digit guarantor code is used. For both, the letters "FA ONLY" are added to the end of the non-person name.

Alternate ID Numbers
Banner stores alternate ID numbers for persons and non-persons. The Data Standards Group decided that these fields will store the Colleague, Benefactor, and Recruitment Plus identifiers and any others that come up during conversion. The Alternate ID field also captures the history of changes to a person/non-person's name or ID with an action date. We can choose to remove alternate IDs but we need to establish a procedure for doing so. Alternate IDs uses the same validation table as name types and are viewed from the Name and Address Information Form. Entering data here allows users to search on fields that other data fields holding the same information may not permit.

ID numbers are preceded by the letters "RP" when the records are added to Banner through the Recruitment Plus (R+) interface system.

Social Security Number
The Data Standards Group decided that the social security number will not be used as the primary ID number for any person record due to privacy issues and complications with non-resident aliens. Dummy social security numbers will not be used in Banner. During the data conversion process, dummy social security numbers were identified and not carried over into Banner.

Data Entry Standard: All social security numbers are to be entered in the SSN field as a full number (without any spaces or hyphens). If we do not have a social security number for a person, we will leave the field blank. Never enter dummy social security numbers into Banner.

The Financial Aid Office uses a dummy social security number of 999-99-9999 when determining aid. These dummy numbers are added to and viewed only on Banner tables, they are not visible via a Banner form.

Confidentiality Flags
There are multiple confidentiality flag fields in Banner because they are module-specific. The Data Standards Group is primarily concerned about the use of the confidentiality flag in the student module since it affects so many departments.

The student confidentiality indicator is used to remove students from all publicly released listings, including Commencement Program, directory, etc.  Confidential students still appear on advisee and class listings on Self-Service and on CLIQ, but are marked with the word "Confidential."

HR uses the confidentiality flag to indicate exclusion of an employee's home address/phone from the campus roster.

Names and Titles

Names
In the General Person module, name information is entered and viewed in the General Person Identification Form (SPAIDEN). Similar forms exist in the Advancement module (APAIDEN), the Human Resources module (PPAIDEN) and the Finance module (FOAIDEN). This is the same form you would use to view ID, Alternate ID, and name information. The data fields on this form are:

• ID (9-digit generated by Banner for new records)
• Name Type (coded field using validation table GTVNTYP)
• Last Name (up to 60 characters)
• First Name (up to 15 characters)
• Middle Name (up to 15 characters)
• Prefix (up to 20 characters)
• Suffix (up to 20 characters)
• Pref. First Name (up to 30 characters)
• Non-Person Name (up to 60 characters)

The ID is automatically generated by Banner when a new person or non-person record is created. The name and title fields are free form fields. Only the name type field is a coded field on this form. It uses the GTVNTYP validation table.

The Banner System allows for multiple names and name types per person or non-person record. For each record, we can create specific name types based on contact, function, or service. Names types are also associated with address types and telephone types (see section V).

The "Current Name" fields are used to store a person or non-person's legal or primary name (last, first, middle, etc.). If the name type field is blank, then the name is the current name. The current name fields are the primary names associated with the ID of that person/non-person record. It's what you first see when you look in the system but it may not be the primary one used for departmental or operating purposes. For this reason, you can create additional versions of a person or non-person's name which are associated with a specific name type. You can only have one name per name type.

About Name Types
Name types were first developed for the Advancement module in Banner but it was so useful that Banner expanded it to be used by other modules. Since some name types are module-specific, the table below includes the primary department responsible for developing the code for that name type. The overall list, however, is the responsibility of the Power Users Group to define and maintain. Name types can be used to conduct searches, to print letters or processes for a specific group, etc. Name type is used for both person and non-person records. Name types are not required for every record. The name information that is entered first is the current name but can be updated continually. The name type field can be used to store alternate names. It is optional and does not need to be used for every record. It can store history of name changes or it can store alternate names or naming conventions. Examples include birth name, previous name, maiden name, alpha name (sort order for non-person), graduation/diploma name, also known as/nickname/alias. The benefit of the name type is that it is searchable and can facilitate finding a person or non-person who may have been known by different names over time or for different purposes. Even though some of these names are stored elsewhere (like under "preferred name"), those fields are not searchable so creating a separate name type could facilitate searches). Alternate ID numbers are similarly constructed and used.

GTVNTYP: NAME TYPE is used for both the alternate ID type and the name type. We decided that we will use the current name field to store the legal name when we have it or the primary name. For employees and financial aid applicants, use the legal name as shown on their social security cards.

Example for "The Henry L. Luce Foundation"
1. The Current Name field would have "The Henry L. Luce Foundation"
2. You could create a name type of alias/also known as of "Luce Foundation" and "Henry R. Luce Foundation."
3. You could also create a name type of alpha of "Henry L. Luce Foundation/The"

Data Entry Standard: Names are to be entered as the person has specified or using title case format (see glossary for details on title case format). Do not enter titles, prefixes, or suffixes in the name field. Use those fields instead. Do not use special characters such as the pound sign (#) or the tilde (~) because these have special meaning in SQL. Other punctuation may be used as specified by the person or non-person including commas, apostrophes, and hyphens. Do not enter foreign language symbols such as accents because they are not recognized by Banner.

For non-person records, enter the full name as specified by that non-person including any article that may appear in the first field (such as "The Henry R. Luce Foundation"). Then use name types to add different versions of that name without the first article--"A," "An," or "The"-(such as "Henry R. Luce Foundation" and "Luce Foundation."

Unusual Circumstance: If a person has only one name (not a last and a first), enter that name in the last name field and the preferred first name field but enter only a "space" in the first name field.

Name Change Policy

The following chart is to be used to show office responsibility when making name changes:

Duplicate Policy

When duplicates are identified in Banner, the spriden record is updated by an Applications Support Analyst to mark the record as a duplicate. If the duplicate identified is a person, the word DUPLICATE is entered into the middle name field. If the duplicate is a non-person, the word DUPLICATE in parenthesis is added to the end of the non-person name. The word DUPLICATE is always capitalized and always inside parenthesis for non-persons.

After DUPLICATE is added to the person or non-person name, an email is generated by the Applications Support Analyst to the dup_pidm email list, alerting other offices on campus that the duplicate was identified and reported.

Preferred First Name
This field is used to store a person's nickname or other name that he/she prefers to be addressed by other his/her first name.

Data Entry Standard: Only enter a preferred first name if it differs from the first name. Otherwise, leave it blank. Enter it as the person has provided it or using title case format.

Middle Name
In Banner this field stores either a middle initial or a middle name if there is one.

Data Entry Standard: If a person has supplied either a middle initial or a middle name, enter it in this field. For initials, do not enter a period. Leave this field blank if no middle name is provided. If more than one middle name or initials are provided, enter them as space allows (up to 15 characters) but do not enter a period after either initial.

Titles
In additions to storing names, the SPAIDEN form allows you to store titles in the prefix and suffix fields. These fields are free form fields in Banner so multiple prefixes and/or suffixes are permitted. Use the abbreviated form of prefixes/suffixes unless otherwise specified by the person. Include periods and commas as needed. If no prefix or suffix is provided, leave these fields blank. For any one title, enter only one corresponding prefix or suffix. Do not enter duplicate prefixes and suffixes. For example if she says her name is Dr. Mary Smith enter "Dr." in the prefix field but nothing in the suffix field but if she says her name is Mary Smith, MD, leave the prefix field blank but enter "M.D." in the suffix field. Although we want to personalize the use of prefixes and suffixes as much as possible, we would also like to have some shared formats to allow for maximum comparison across modules. Below are links to tables that should be used as a guideline for abbreviating prefixes and suffixes for departments' convenience. These are taken from an external standard, The Chicago Manual of Style.

Data Entry Standard: Enter general salutations into the prefix field (Mr., Miss, Mrs., Ms.). Enter only special prefixes (such as Dr., etc.). If no prefix or suffix is provided, leave the field(s) blank.

Abbreviate prefixes and suffixes unless the person has specified not to. Use tables below for all prefix and suffix abbreviations unless the person has specified another preference. Please note spacing and punctuation in tables. Sometimes there is a space and sometimes not.

Do not use corresponding prefixes and suffixes. Choose one or the other for each title (whenever possible based on the person's preference). For example, either Dr. Margaret Jones or Margaret Jones, M.D. but never Dr. Margaret Jones, M.D.

Do not use Esq. with other titles (except Jr., Sr. II, III, etc.). For example, if someone is both Esq. and M.A., drop the Esq.

Multiple prefixes should be entered in the order provided by the person but with no commas between them. For example: Rev. Dr. Margaret Jones

Multiple suffixes should also be entered in the order provided by the person but with a comma and space between each one. For example: Margaret Jones, M.D., M.Div.

• List of standard prefix abbreviations

• List of standard suffix abbreviations

Contact Information

Address
Address information is entered and viewed in the Address Information Window (part of the SPAIDEN form). The data fields in this window are:

• Address Type (coded field using validation table STVATYP)
• From Date
• To Date
• Street Address (3 lines up to 30 characters each)
• City (up to 20 characters)
• State/Prov. (coded field using validation table STVSTAT)
• Zip/PC (coded field using validation table GTVZIPC)
• County (coded field using validation table STVCNTY)
• Nation (coded field using validation table STVNATN)
• Phone (up to 14 digits: 3-digit area code, 7-digit number, and 4-digit extension)
• Phone Type (coded field using validation table STVTELE)
• Address Source (coded field using validation table STVASRC)

All addresses must have an address type associated with it. Each module can select the type of address that they want to use as the default address on their screens or processes.

Address types are connected to telephone types but are distinct validation tables. However, you can associate an address type with a telephone type in the address type code validation table so that it appears on the address information window. It would be the primary number for that address type that would show up on that window. You can store multiple numbers for each telephone type which can be viewed in the telephone window. If you enter the telephone number on the address type window, there will be an assumed association with that address. You can have multiple addresses for person and non-person records using address types. You can store historical information as well as future information. You can use a hierarchy to select addresses. For example, for billing you may first look for a billing address, if there is none, then send it to the campus address, if there is none, then send it to the permanent address. Typically you don't repeat the same address in each address type. Each address type is a unique address for that person/non-person record. Instead, you use a hierarchy as described above to select the appropriate address for your purpose. You can only have one active address per address type at any one time.

Don't delete addresses, just put in an end date before entering the new address. We want to keep the history of addresses in the system. Use the inactive flag to render an old address inactive. If you do this, you can never use the address again. Instead, use the start and end dates on the address to render it inactive.

The most current PR address should be the highest sequence number for the PR type.

An address change report is created daily and emailed to appropriate personnel to communicate address changes.

Zip codes should be entered without hyphens.

Ask group - There are three types not listed here, but are on the STVATYP table (users can see if they click the drop down box): BU Business (5 rec), PA Parent (191 rec) and BI Billing (28 rec). Should we add these 3 to this table for clarification? Perhaps if code is no longer used we can add "No Longer Used" under Note column?

STVATYP: ADDRESS TYPE is used to designate specific types of addresses per person/non-person record.

Here are some examples of how we would code different address types for four typical Dickinson scenarios:

Scenario 1: A visiting scholar, whose permanent residence is Cameroon, is living in an apartment on Louther Street for the semester he is at Dickinson. As a member of the sociology department, he also has an office in Denny.

• His address in Cameroon would be coded "PR"
• His address on Louther Street would be coded as "CR"
• His office number and building would be coded as "CA"

Scenario 2: A Dickinson junior and her family live in Baltimore, MD. As a Dickinson matriculant she has been assigned a HUB Box as her on campus address. A French major, she's spending her junior year in Toulouse, France. She's living in an apartment in Toulouse but receives her Dickinson mail at the Dickinson Center.

• Her address in Baltimore would be coded as "PR"
• Her HUB Box number would be coded as "HB"
• Her Toulouse apartment address would be coded as "CR"
• The Dickinson Toulouse Center address would be coded as "MA"

Scenario 3: A Dickinson first-year student lives with his mother and stepfather in Great Neck, NY. His parents are divorced. His father and stepmother live in New York, NY. As part of the divorce settlement, both parents are paying his college expenses. In addition, his grandfather set up a trust fund for his education. He passed away recently but an executor controls the trust.

• His address in Great Neck would be coded as "PR"
• His HUB Box number would be coded as "HB"
• His father's address would be coded as "B1"
• The executor's address would be coded as "B2"

Scenario 4: An admitted applicant has sent in a deposit to hold a place in the entering first-year class. She and her family live in Santa Fe, New Mexico. She is currently in boarding school in Andover, Massachusetts and will graduate on June 15th. She has notified us that she and her family will be at their summer house in Hilton Head, South Carolina for the month of July.

• Her address in Santa Fe would be coded as "PR"
• Her address at boarding school in Andover would be coded "ML" and have an end date of "June 15"
• Her address in Hilton Head would be "SL" and have a start date of "July 1" and an end date of "July 31"

STVASRC: ADDRESS SOURCE CODE
Banner can also store an address source-where the address came from. These use the Address Source Code validation table (STVASRC). The Data Standards Group decided not to develop this list since some departments don't plan to use this feature. Instead, each department will utilize this in their module as appropriate to their needs.

Data Entry Standards for Entering Address Information
The Data Standards Group decided that we will use data entry standards for US addresses that conform with the US Postal Service recommendations. For international addresses, we will use what the person/non-person has provided us with. Although the US Post Office would prefer us to use all uppercase, some offices may still prefer to use "proper" or title case. Therefore, we will enter address data into Banner using title case. Anyone who wants to conform to USPS recommendations can reformat the address information into uppercase. (It's trickier to reformat uppercase information into title case and requires manual proofing.) We will, however, use uppercase for the name of the country in an international address. This will be built into the STVNATN validation table. Here are key instructions for formatting address information provided by the US Postal Service. More information is available on its website: https://www.usps.com.

Domestic Addresses should be formatted in this order:

1. "Name and/or "Attention:" line. Print or type address clearly in center of envelope (Use 10, 12, 14 pts for best readability)

2. Always use directionals in address (e.g., "N" for north and "S" for south)

3. Use abbreviated locators in address (e.g., APT, ST, AVE)

We will use the abbreviations for street suffixes available at this web site: http://www.usps.com/ncsc/lookups/abbreviations.html#suffix

4. Include RM (Room), FL (Floor), STE (Suite), or APT (Apartment) # on same line as (and after) street address

The list is available at this web site: http://www.usps.com/ncsc/lookups/abbreviations.html#secunitdesig

5. Use two letter state abbreviations in address block

6. Use ZIP+4 (if known) on last line following city and state. Do not enter hyphen's between zip and zip+4.


International Addresses should be formatted the same way but include the nation/country in all capital letters on the last line.

Click here for examples of address formatting provided by the US Postal Service.

After purchasing software from https://www.greatdata.com, city and state data was linked to zip code for US addresses. Data entry staff will first enter the US zip code and then the other fields will be automatically populated. All of these fields will need to be entered manually for international addresses.

STVCNTY: COUNTY CODE
These will be downloaded from the software we purchase from https://www.greatdata.com. Banner county codes will populate automatically when you enter in the zip code if the county code you are entering is on the zip code table. The zip code table was originally populated from the software purchases from www.greatdata.com. Missing or new zip codes can be added to table by contacting an Applications Support Analyst in the Institutional Systems Department.

STVSTAT: STATE CODE
The Data Standard Group decided to use US Postal Codes. This will include Canadian provinces as state codes at the request of Advancement. The US Postal Codes are the same as the FIPS alpha codes used by IPEDS with one exception (the US Minor Outlying Islands). The full list of postal codes is available at this web site: http://www.usps.com/ncsc/lookups/abbreviations.html#states

GTVZIPC: ZIP/POSTAL CODE
These will be downloaded from the software we purchased from https://www.greatdata.com. The zip code table was originally populated from the software purchased from www.greatdata.com. Missing or new zip codes can be added to table by contacting an Applications Support Analyst in the Institutional Systems Department.

STVNATN: NATION CODE
The Data Standard Group decided to use EDI Codes. They decided not to use SEVIS Codes because we have too few. There may be a need to revisit this later if reporting requirements for international students and visitors change. (A list of all EDI Codes can be found at this web site: www.pesc.org/info/docs/130appb.pdf). There is a slight overlap with state codes (Puerto Rico, US Virgin Islands, and the US Minor Outlying Islands). The US Postal Service prefers us to code these as states, not nations. The US Postal Service requests that the nation name be in uppercase.

Please note that if a nation code is added into the Recruitment Plus Interface, that same nation code will need to be added to the STVNATN Banner table.

Telephone Number
Telephone numbers can be viewed and entered using the General Person Telephone Form (SPATELE). The data fields on this form are:

• Phone Type (coded field using STVTELE validation table)
• Area Code
• Phone Number
• Phone Extension
• Address Type
• Prime flag
• Unlisted flag
• Inactive flag
• International Phone Number
• Comment

You can also enter telephone number directly from the address form but those numbers will consequently be associated with that address and address type. Do not use hyphens when entering phone numbers.

International phone numbers are entered into Banner by entering the International Access Code (011) in the area code field. Next enter Country Code followed by telephone number using up all available spaces.

(14 spaces available? How does this work? Some international telephone numbers can be up to 15 digits like our Bremen program 011-49-421-218-3187. Remember: Banner V8 will fix issue with international telephone numbers.)

Ask group - There is a type listed here, but not on the STVTELE table: BL Billing (0 recs). Should we remove from this list?

E-Mail Address
E-Mail Addresses are entered and viewed on the E-mail Address form (GOAEMAL). A person or non-person's web site would also be stored here. The data fields on this form are:

• E-mail Type (coded field using the GTVEMAL validation table)
• E-mail Address (free form field up to 90 characters)
• Preferred flag (check to denote this as the preferred e-mail address)
• Inactive flag
• Display on web flag
• URL flag (check to distinguish a web page from an e-mail address)

You can have multiple e-mail addresses (and web pages) per e-mail type. Use the preferred flag to indicate the one that should be used most often.

Emergency Contact Information
Users can enter and view information on a person's emergency contact information in the Emergency Contact Form (SPAEMRG). (In the HR Module, this information is viewed from the PPAIDEN form.) The data fields on this form are:

• Priority
• Contact Name
• Relationship (coded field using the STVRELT validation table)
• Address Type (coded field using the STVATYP validation table)
• Address (3 lines)
• City
• State/Prov
• Zip/PC
• Nation (coded field using the STVNATN validation table)
• Phone

A person record can have multiple emergency contacts. Use the priority field to rank order them. NOTE: You cannot use the phone number field on this form to enter or store international phone numbers.

The Data Standards Group decided upon the following codes to identify the relationship of the emergency contact to the person. The Health Center was consulted as well and they agreed with these codes.

The above mentioned Emergency Contact Information is not the same information as the Dickinson Red Alert System.

Demographic Information

Demographic (or biographic) information on persons is entered and viewed in the General Person Information form (SPAPERS). (For the Human Resources Product, this is not a separate form but a window on the PPAIDEN form.) The data fields on this form are:

• ID (with associated current name)
• Gender (select from three radio button choices)
• Date of Birth
• SSN/SIN/TFN
• Age (calculated field from Date of Birth)
• Confidentiality flag
• Citizen (coded field using STVCITZ validation table)
• Ethnic (coded field using STVETHN validation table)
• Marital (coded field using STVMRTL validation table)
• Religion (coded field using STVRELG validation table)
• Legacy (coded field using STVLGCY validation table)
• Vet. File No.
• Veteran Category
• Active Duty Separation Date
• Deceased flag (check to indicate that this person is deceased)
• Deceased date

Gender
The fields defining gender are in Banner. Data entry staff can select one of the following:

The default is "Not Available" until a gender is indicated.

Race/Ethnicity
There are two code tables in Banner for race/ethnicity. One is for our institutional purposes and the other is for IPEDS reporting. For the institutional definition, use the codes in Recruitment Plus which come from the Common Application. We will use the Common Application race/ethnicity codes for this field since this is the first way this data is captured for students. While the Common Application allows applicants to select multiple race/ethnicities, the Admissions Office only enters one into Recruitment Plus. Currently, the Admissions Office uses the following hierarchy to select which race/ethnicity is entered if multiple are reported:

Af-am > any other min category > white or other
Also Af-am or hispanic/PR/Mex-am > asian or nat-am

Citizenship
All person records include a citizenship status code on the General Person Information Form. These codes are located in the STVCITZ validation table. We use the codes from the Common Application.

Ask group: Add UN Unknown as like on the STVCITZ table - UN added 9/21/05.

International Information
Information on international persons is entered and viewed on the International Information Form (GOAINTL). The data fields on this form are:

• Visa Type Code (coded field using STVVTYP validation table)
• Visa Number
• Nation of Issue
• Issuing Authority (coded field using STVVISS validation table)
• Port of Entry (coded field using STVPENT validation table)
• Entry flag
• Number of Entries
• Date Requested
• Date Issued
• Start Date
• End Date
• Document Code
• Document Description
• Document Source Code
• Document Source Description

Use the following visa codes in Banner. The full list of ICE (Immigration and Customs Enforcement, formerly INS) visa codes are available at this web site: http://uscis.gov/graphics/services/visas.htm) Since Banner only allows two characters for the validation code, legacy codes with three characters were abbreviated and noted the actual visa number in the validation description.

For conversion, please note that the DataStu:Visa_Num field in Recruitment Plus corresponds with (STVCITZ) Citizen Type in Banner, not visa type. Global Education will enter visa information for students (and others) directly into Banner. HR will enter visa information for employees directly into Banner.

Ask group: STVVTYP table shows B1 and B2 separately, no B. STVVTYP does not show VW VisaWaiverProgram. Remove from list?

STVPENT: PORT OF ENTRY
It was decided not enter this data in Banner. It will be automatically generated by SEVIS but it may not be available for all international students/visitors.

Another window associated with the GOAINTL form is the Nationality/Family Information window. This window has the following data fields on it:

• Nation of Birth (coded field using STVNATN validation table)
• Nation of Citizen (coded field using STVNATN validation table)
• Native Language (coded field using STVLANG validation table)
• Sponsor
• Employment Type
• Foreign Tax ID
• Spouse Accompany Person To Country (drop down box)
• Number of Children Accompanying Person
• Signature for Availability of Funds (drop down box)

STVLANG: NATIVE LANGUAGE
It was decided to enter this information into Banner. For a list of language codes from the Library of Congress, use this link http://www.loc.gov/marc/languages/lang_pt2.html

Marital Status
We will use the codes in the table below to collect information on a person's marital status. This will be used mostly by HR and Advancement but will be shared across modules.

Religion
Use the table below when entering Banner religion codes.