DATA STANDARDS GROUP

DSG Home

DSG Members

Data Standards

Links

1College Project

Institutional Research

DRAFT VERSION
Last Updated on May 5, 2005

Data Configuration, Entry, and Coding Standards
for the 1College Project

The Data Standards Group has been charged by the 1College Project Steering Committee to review and decide upon the manner in which we will configure, enter, and code general data in the new Banner system. Due to the tight implementation deadline, the Data Standards Group must develop the preliminary standards by the end of February, 2005. After that, the Group will review the validation tables brought to it by the 1College Project teams. This document is a work-in-progress. It reflects the discussions and decisions of the Group on data standards and serves as a guideline for those who will set up the new system and the conversion from Colleague. As time progresses, this document will become the main reference guide for data standards in Banner.

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

• Conversion issues will appear in blue font.

• Action items for the Data Standards group will appear in 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 Data Standards 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 SCT 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 that we keep several things in mind. First, each table differs in how many characters we can use for its validation codes. They vary from 1 to 30. Second, we need to decide whether it makes more sense to use numbers, letter codes, or a combination of numbers and letters. Third, we need to 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, we should 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. The Banner System 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 the system generates an 8-digit number sequentially.

The Data Standards Group reviewed many options for how we would define the number. We were 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 currently use. Initially we 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, we 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 (CBOARD) is phasing out the use of social security numbers as the primary ID, we felt that this was the best long-range option. The first id number to be generated by Banner will be 900000001.

Alternate ID Numbers
Banner allows us to capture alternate ID numbers for persons and non-persons. The Data Standards Group decided that we will use these fields to 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 us to search on fields that other data fields holding the same information may not permit.

Social Security Number
The Data Standards Group decided that we will not use the Social Security Number as the primary ID number for any person record due to privacy issues and complications with non-resident aliens. Unlike Colleague, we will not use any dummy Social Security Numbers in Banner. During the data conversion process, we will have to identify the dummy Social Security Numbers and make sure they are 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.

Confidentiality Flags
There are multiple confidentiality flag fields in the Banner system 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. We need to develop a policy on who checks it, why, and when.

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) and the Human Resources module (PPAIDEN). 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 model 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 Data Standards 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, the legal name is the one 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.

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: Do not enter general salutations into the prefix field (Mr., Miss, Ms., 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 (2 lines up to # characters each)
• City (up to # 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. Do not 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.

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 "CA"
• 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 "CA"
• 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 "00/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 that we will not 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: 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. First and foremost, the endorsement should be clear and legible: use all caps, no punctuation, and left justify the margin

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

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

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

6. Use two letter state abbreviations in address block

7. Use ZIP+4® (if known) on last line following city and state

8. This is the barcode area; if you do not have a program that calculates and prints the correct barcode, then leave this area blank.

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.

Data Entry Standards for Secondary Unit Designators
We will use the US Postal Service abbreviations for all domestic addresses. International addresses will be entered as provided by the person/non-person. The list is available at this web site: http://www.usps.com/ncsc/lookups/abbreviations.html#secunitdesig

Data Entry Standards for Street Addresses
We will utilize the US Postal Service recommendations for all address information, including Street Address data entry conventions. We will use theabbreviations for street suffixes available at this web site: http://www.usps.com/ncsc/lookups/abbreviations.html#suffix

After purchasing software from www.greatdata.com, city and state data will be 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 www.greatdata.com.

STVSTAT: STATE CODE
The Data Standard Group decided that we will the US Postal Codes. We will also include Canadian provinces as state codes at the request of Development. 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 below and also 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 purchase from www.greatdata.com.

STVNATN: NATION CODE
The Data Standard Group decided that we will the EDI Codes. We decided not to use SEVIS Codes because we have to few. We may need to revisit this later if our 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.

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.

STVTELE: TELEPHONE TYPE

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 # 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.

GTVEMAL: E-MAIL ADDRESS

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.

STVRELT: RELATIONSHIP

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 built into Banner. Data entry staff can select one of the following radio buttons:

The default is "Not Available" until a gender is indicated. Conversion issue: Make sure that missing genders are converted into "Not Available."

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, the Data Standards Group decided that we will use the codes in Recruitment Plus (R+) which come from the Common Application. We will use the Common Application race/ethnicity codes for this field since this is the first way we capture this data for students. While the Common Application allows applicants to select multiple race/ethnicities, the Admissions Office only enters one into R+. 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

We will revise employment forms to capture the Common Application race/ethnicity codes in the future for employees but we will ask them to select only one.

For existing records, we will use the equivalents as indicated in the table for data conversion.

STVETHN: ETHNIC CODE

Banner also has an ethnic code table used for IPEDS reporting. See Section VII for more information.

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 will use the codes from the Common Application. These are the same types that we currently use in Colleague.

STVCITZ: CITIZEN TYPE

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

We will use the following visa codes in Banner. (The full list of INS visa codes are available at this web site: http://uscis.gov/graphics/services/visas.htm) Since Banner only allows 2 characters for the validation code, we have abbreviated codes with three characters 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. Human Resources will enter visa information for employees directly into Banner.

STVVTYP: VISA TYPE CODE

STVPENT: PORT OF ENTRY
We will 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
We will not enter this data into Banner so we do not need to create a validation table for this field. Should we decide to collect this information in the future, we may choose to use the EDI codes as we have done for nations.

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.

STVMRTL: MARITAL STATUS

Conversion issues: Colleague also has the code "CO" meaning correction. Do not import this into Banner. Also, please note that the code "P" in Colleague must be changed to "E" in Banner since "P" will be used for domestic partner.

Religion
We will continue to use the religion codes in Colleague since they are sufficient for our institutional purposes and admissions doesn't collect this information in any systematic way.

STVRELG: RELIGION CODE

Converison Note: The value "20" was not used in this field in Colleague.

Legacy
We will only use this field to capture general profile information on our students. Development will not use this to identify relationships. Institutional Research and others will use this field to report out general legacy statistics on our student body. We will condense the codes from R+ to accommodate the 1-digit field space. No data will be entered in Banner, we will convert the data from R+.

STVLGCY: LEGACY CODE

Converison Note: The value "5" is not currently used in thi s field in Recruitment Plus.

Disability
Information on disabilities for person records is entered and viewed on the General Medical Information Form (GOAMEDI). We will not use this form in Banner.

STVSPSR: DISABILITY TYPE
We will not use this field in Banner so we do not need to create a validation table for it.

IPEDS Reporting

IPEDS Ethnic Codes
Although we know that the federal government is currently reviewing plans to change how colleges must report race and ethnicity, we will use the current regulations to plan for the Banner conversion. If any changes are approved, we will work with Banner to reconfigure how we enter, code, and store that data. More information on the IPEDS codes is available at this web site: http://nces.ed.gov/ipeds/glossary/

IPEDS only wants us to provide race/ethnic data on US Citizens and Permanent Residents. Non-Resident Aliens are broken out as a separate category. These codes are listed in the order in which data entry is required for the IPEDS reports.

STVETCT: IPEDS ETHNIC

IPEDS Degree Level
The table below provides codes to group students by degree level for IPEDS reporting. This is delivered by SCT in order to use the automated IPEDS reporting module.

STVDLEV: DEGREE LEVEL

IPEDS Degree Award Category
Banner delivers a validation table for Degree Award Categories used for automated IPEDS Reporting (STVACAT). All of the fields in this table are system required.

STVACAT: DEGREE AWARD CATEGORY

Academic Credentials

Degrees
STVDPLM: DIPLOMA TYPE
We will not use this validation table which provides codes for high school or equivalent diploma types. We will not enter that information into Banner.

Banner allows us to store postsecondary degree information on all person records. This information is shared across modules. This is also the same field used to store degrees earned at Dickinson. Banner allows you to enter multiple degrees and institutions per person record. Currently, development enters alumni degrees in Benefactor and Academic Affairs enters faculty degrees in Colleague (where earned Dickinson degrees are also stored). These are located in the DEGREES and ACAD.CREDENTIALS files, respectively. The data have been entered in a general format but we want to store real and specific information on every degree. During the conversion, we will carry over the information in Benefactor and Colleague. Then as new information is entered into Banner, we will use the more specific formats outlined in the STVDEGC table below. We will also update old records as we work those individual files. Otherwise the data will remain general (for example, "other master's degree" instead of the specific type of degree).

Data Entry Standard: You must enter a degree earned with the institution it was earned at. If the institution is unknown, do not enter any degree data. If you have information on the subject area the degree was earned in, enter it in the major field. If you don't know, leave this field blank. Do not enter any degrees that are not postsecondary degrees. If you encounter a degree not in the degree code list, contact the STCDEGC table owner to have it added.

Since any degree can be awarded as an honorary degree, we will use the major code field to indicate that it is honorary. For honorary degrees, select the specific degree awarded (Ph.D, J.D., etc.), then select "Honorary" under the major code.

STVDEGC: DEGREE CODE

Schools (High School, College, University, etc.)
The table below lists codes for all types of academic institutions including high schools, colleges, and universities. The Data Standards Group decided that we will use the ETS/ACT codes (FICE) so that we can take advantage of tape loads which includes other information about the institutions including address information. Otherwise these will have to be manually entered each time a new institution is added to the system. Recruitment Plus currently uses the tape loads too but have updated some of the information.

The only problem involves non-USA institutions. These do not have FICE numbers and are not included in the tape loads. Currently, admissions creates codes (IN###) for these as they need to. However, if we want to include international universities that faculty and visiting faculty have graduated from, this list will expand significantly. For international institutions, we will use the following coding scheme: Use the 2-digit nation code from STVNATN followed by a sequential number. The Data Standards Group will be responsible for adding new codes. We will convert the codes coming in from Recruitment Plus to fit this coding system.

STVSBGI: SOURCE/BACKGROUND INST
We will use the coding that ETS/ACT uses and will get them from the tape loads.

The College Code validation table (STVCOLL) allows a large institution to list multiple colleges within its organization. Since Dickinson only has one college, we only need to have a code for Dickinson.

STVCOLL: COLLEGE CODE

Student Module-Specific Tables

The tables listed in this section are utilized only by the student module. For this reason, they will be developed by the department, not the Data Standards Group. However, they are included in this document because the department has asked for the DSG's input.

STVACYR: ACADEMIC YEAR CODES are those used at Dickinson.

STVBLDG: BUILDING CODES is used to identify buildings existing at Dickinson College that are used in the student module (not an exhaustive list of buildings).

STVCAMP: CAMPUS CODES is used to define the codes and descriptions for different campuses within Dickinson College. A campus can be assigned to persons at the prospect, application, or student stage; to sections; to degree programs; and to buildings and rooms. Transcripts and grade mailers can be produced by campus and fee assessment rules can be defined by campus. These are just a few examples of the use of campus codes.

STVCIPC: CIP CODES
The Data Standards Group decided that we will use the latest CIP Codes. Deb will supply us with those currently in use at Dickinson. We only need to have CIP Codes that associate with current Dickinson majors. We do not need to apply this to majors of non-Dickinson degrees.

STVDEPT: DEPARTMENT CODES is to identify the existing departments at Dickinson College. This is used to assign departments to courses and faculty. In the Advancement module it is used for gift designations.

The Data Standards Group decided that we will bring over only new departments. We will also separate out departments from majors. For administrative departments, whenever possible, we will use the abbreviation they use for themselves. For example, the Dean of Students goes by DOS, so that's what we'll use.

STVFCNT: FACULTY CONTRACT TYPE is used to determine a Faculty member's contract and course load.

STVLEVL: LEVEL CODES is used to determine the student's level at Dickinson College.

STVSUBJ: SUBJECT CODES is used to identify subjects offered at Dickinson College.

STVTERM: TERM CODES is used to identify terms used at Dickinson College. We have to include old term descriptions because we are carrying over academic history records which correspond to those terms.

For the coding, we will continue to associate the calendar year with the term in question. After the calendar year, a two-digit numeric code would be used to designate the term. Since we will continue to associate specific terms with "subterms" like study abroad locations, there is a numeric gap between the term codes to accommodate for all of the individual subterms falling within that term. Here is an example of how the terms would be coded for the 2006-07 academic year:

200660: Summer Session II 2006
200670: Fall 2006
200710: January 2007
200720: Spring 2007
200750: Summer Session I 2007

STVTESC: TEST CODES is used to score valid test codes for SAT, SAT II, ACT, etc. Dickinson College will also use this form for language placement exam codes.

Advancement Module-Specific Tables

The tables listed in this section are utilized only by the advancement module. For this reason, they will be developed by the department, not the Data Standards Group. However, they are included in this document because the department has asked for the DSG's input.

GTVEXPN: EXPENSE TYPE is used to validate expense types for solicitations and events. Codes and descriptions were created by the Development team.

GTVSUBJ: SUBJECT INDEX is used to validate comment types. Codes and descriptions were created by Development.

STVHONR: HONOR is used to validate institutional (not departmental) honors received from Dickinson. (NOTE: Latin Honors are in STVHONR, departmental honors are in STVHOND, and dean's list is in STVAST-which also has probation, etc.)

STVLEAD: ACTIVITY LEADERSHIP is used to validate activity leadership for student and non-student activities (e.g. Alumnae or community activities) in the advancement module only. Codes and descriptions were obtained from BEN.INTEREST.ROLES.

STVORIG: ORIGINATOR is used to validate department for various purposes. Codes and descriptions were compiled from DICKINSON.COM and BEN.FUND.INTEREST. NOT RELATED TO FOAPAL.

The Data Standards Group will develop the STVDEPT: DEPARTMENT CODE table in April. In the meantime, Development will utilize this for their conversion process. They may try to reconcile it to the department code list later.

Back to the top