Liberty University



BANNER FORMS YOU MAY NEED TO KNOW

Here is a list of all Banner forms that you should become familiar with in order to view and find information. You may or may not have access/security rights to edit these forms but you will need to know where to find the data located and kept on these forms. This is a resource only and does not need to be memorized. Please note the form name and description:

*These forms are in alphabetical order according to Banner form name

|Form name |Description |

|GOAEMAL |PURPOSE OF FORM |

| |The GOEMAL form is used to manage the email addresses that have been reported |

|Title: E-mail Address |and loaded into the system. This form is also accessed in other forms as well.|

|GOAINTL |PURPOSE OF FORM |

| |This form is used to manage international information pertaining to an |

|Title: International Information |individual including visa, passport, certification of eligibility, and |

| |nationality. This form will be most likely not be used for US citizens. |

|GOAMTCH |PURPOSE OF FORM |

| |The purpose of this form is to ensure that duplicate ID’s will not be created.|

|Title: Common Matching Entry |This form is a query form that searches for duplicates in the system. |

|GOAMTCH |PURPOSE OF FORM |

| |This form appears automatically when a user tries to add a new identification |

|Title: Common Matching Entry |record to the Banner database, unless the user has been excluded from the |

| |Common Matching process or the Online Matching Processing Enabled checkbox is |

| |cleared on the Institution Controls Form (GUAINST). Excluded users can still |

| |access GOAMTCH directly, or by selecting it from the Options menu while on an |

| |%IDEN form. |

|GOASEVR |PURPOSE OF FORM |

| |This form is used to display the entire SEVIS record for a student or exchange|

|Title: SEVIS Transmittal History |visitor. After this data is sent to SEVIS and received, the status |

| |information should be updated to reflect the SEVIS approval or denial codes |

| |and messages. Once these updates have been made and the record is saved, the |

| |record cannot be changed. All updates must be done on the populating forms |

| |(SPAIDEN, SPAPERS, and GOASEVS) and a new record must be created. Records are|

| |stored in a sequence number order with the highest sequence number being the |

| |most recently created record. Additionally, all Banner codes are converted to|

| |a SEVIS equivalent code by the Create Record functions. |

|GOASEVS |PURPOSE OF FORM |

| |This form is used to enter and maintain SEVIS required data. It consists of a |

|Title: SEVIS Information |key block, a Common Data block, a Student Data block, an Exchange Visitor Data|

| |block, and a Dependent Data block. In addition, after records are created, the|

| |user can create a complete SEVIS record using the Create Record options. This|

| |form should be used to enter and maintain current SEVIS data only. Historical |

| |records are maintained on the GOASEVR form. It is important to note that all |

| |Banner codes entered on this form must have a SEVIS equivalent value set up in|

| |the appropriate validation form or SEVIS records cannot be created. |

| |Forms with dependencies include: |

| | |

| |Nation Code Validation Form (STVNATN) |

| |Major Code Validation Form (STVMAJR) |

| |Relation Code Validation Form (SVTRELT) |

| |Visa Type Code Validation Form (STVVTYP) |

| | |

| |In addition, you must have either Creation Reason code or a Termination Reason|

| |Code in the Common Data block in order to create a SEVIS record. |

|GORCMDD |PURPOSE OF FORM |

| |This form allows you to review the data elements you want to use in the Common|

|Title: Common Matching Data Dictionary |Matching process. The data dictionary contains all the available data elements|

| |that may be used in Common Matching rules and information about those |

| |elements. |

|GORCMRL |PURPOSE OF FORM |

| |This form allows you to set up the rules that the Common Matching process will|

|Title: Common Matching Rules |use to search the database to see if a person or non-person record already |

| |exists when a new record is being added to the database. |

|GORCMSC |PURPOSE OF FORM |

| |This form is required for Common Matching processing. |

|Title: Common Matching Source Rules | |

|GORCMUS |PURPOSE OF FORM |

| |This form allows an administrative user to assign a default Common Matching |

|Title: Common Matching User Setup |source code to users for online processing. |

|GORNAME |PURPOSE OF FORM |

| |This form allows you to set up rules that the Common Matching process will use|

|Title: Name Translation Rules |when searching to see if a record already exists for the specified person. |

|GORNPNM |PURPOSE OF FORM |

| |This form allows you to set up rules that the Common Matching process will use|

|Title: Non-Person Name Translation Rules |when searching to see if a record already exists for the specified non-person.|

| |This would be helpful if, for example, a company is commonly known by its |

| |initials. The Common Matching process would then recognize records with either|

| |the name or the initials as belonging to the same entity. |

|GTVCMSC |PURPOSE OF FORM |

| |This form allows you to set up a code that represents each source of new |

|Title: Common Matching Source Code Validation |person and non-person records. |

|GUAINST |PURPOSE OF FORM |

| |Use this form to maintain overall system information for the installation. |

|Title: Installation Controls | |

|GUAPMNU |PURPOSE OF FORM |

| |The User Defined Menu Maintenance Form (GUAPMNU) allows the user to build a |

|Title: My Banner Information |personal menu. The personal menu can contain any combination of forms, jobs, |

| |menus, or Quick Flows. The user can create and change a personal menu at any |

| |time. After customizing a menu, the user can access it from the main menu of |

| |Banner2000 by pressing the Personal Menu name in the menu list or by selecting|

| |Personal Menu from the pull down at the top of the left window of the menu |

| |form. NOTE: When working in this form, the customized menu belongs to the |

| |ORACLE user ID currently logged into the Banner2000 system. |

|GUAPSWD |PURPOSE OF FORM |

| |This form is used to change your Oracle Password. |

|Title: Oracle Password Change | |

| |The User ID logged on will be displayed. Enter the current Password, enter |

| |the new password in the New Oracle password field and reenter the new password|

| |in the Verify Password field. |

| | |

| |Press SAVE to changed the Oracle Password. Press EXIT to cancel the change. |

|GUAQFLW |PURPOSE OF FORM |

| |This form lets you enter the identifier and access the first form in the |

|Title: QuickFlow |QuickFlow. When you exit the first form, the next form in the sequence is |

| |automatically accessed. This process continues until all forms in the |

| |QuickFlow have been accessed and exited. At this point, you can execute the |

| |QuickFlow again or exit to the location where you called the QuickFlow. |

|GUAQUIK |PURPOSE OF FORM |

| |The QuickFlow Definition Form allows the user to define a QuickFlow. |

|Title: Quick Flow Definitions |QuickFlow’s can only include forms. Begin by selecting a QuickFlow code. |

| |Click in the menu block. You can add forms by selecting them from list on the|

| |left side of the screen. The order of the forms in the QuickFlow is the same |

| |order that the forms appear in the block. Form names are validated against |

| |the list of forms that appear in the Banner2000 menu system. |

|GUIALTI |PURPOSE OF FORM |

| |The SSN/SIN Alternate ID Search Form is used to search for the BANNER ID, when|

|Title: SSN/SIN Alternate ID Search |the SSN/SIN, Name, Date of Birth, or Change Indicator is known. This form is |

| |accessible from a specified grouping of forms that contain the ID field in the|

| |key block. It also has the ability to return the ID to the form which called |

| |it. |

|GUTPMNU |PURPOSE OF FORM |

| |The GUTPMNU form allows a personal menu of one user to be reviewed, modified, |

|Title: My Banner Maintenance and Copy |and copied to a personal menu of another user or several users. This form |

| |allows you to call a user who already has a personal menu created. You can |

| |view the personal menu, add objects to it, or remove objects from it. Once |

| |you are satisfied that the menu you are viewing is the one you want to copy to|

| |one or multiple other users, press the "users" icon in the center column of |

| |the form. A new window appears in the left column of the form showing the |

| |Oracle user ID's of people on your system. You can select (highlight) one or |

| |multiple users. You select users by highlighting one or more ID's with your |

| |mouse and then pressing the "copy users" icon in the center column of the |

| |form. |

|SAAADMS |PURPOSE OF FORM |

| |This form is use to enter information that pertains to the application of a |

|Title: Admissions Application |student. This form manages and controls all information concerning the |

| |student’s application, curricula choices, admissions checklist, and other |

| |valuable information. |

| |FORM DEPENDENCIES |

| |A general person record must be created prior to keying in an application |

|SAADCRV |PURPOSE OF FORM |

| |This form is used to enter admissions decisions. It may be called from the |

|Title: Admissions Decision |Admissions Application Form or may be selected from the Admissions Menu. The |

| |second page of this form provides a mechanism for the decision to be |

| |calculated automatically based on the rules of the Decision Rules Form |

| |(SAADCSN). The third page of this form is a summary of the student's data used|

| |in the automatic decision calculation. Once the applicant accepts the |

| |Institution's offer of admission, a student record is created by the system |

| |and the student is ready to register. |

| |FORM DEPENDENCIES |

| |An admissions application must exist prior to a decision being entered. An |

| |applicant may accept only one offer of admission per term. |

|SAADCSN |PURPOSE OF FORM |

| |Use this form to enter criteria for system-calculated admission decisions. |

|Title: Admissions Decision Rule |Student information entered in the Key Block is compared to admissions |

| |application data. |

| |The remainder of the form is used to enter high school, high school subject, |

| |prior college, test score, and rating information to be compared to the |

| |student’s data. |

| | |

| |Note: You should enter rules on this form before you calculate any admissions |

| |decisions. |

| | |

| |FORM DEPENDENCIES |

| |When you first access this form it is in query mode. You must perform an |

| |Execute Query function to display data or perform a Cancel Query function to |

| |define new rules. |

|SAAEAPS |PURPOSE OF FORM |

| |The Electronic Application Process Form displays admissions applications |

|Title: Electronic Application Process |received electronically (for example, through the BANNER Web Admissions |

| |Application or via EDI), allows a user to perform required manual |

| |verification, performs system verification of data, and is also used to |

| |request that the information be moved from the holding tables to the permanent|

| |BANNER tables. |

|SAAERUL |PURPOSE OF FORM |

| |The Electronic Application Rules Form is used to define the rules which will |

|Title: Electronic Admissions Application Rules |be used when processing electronic applications. Rules fall into three major |

| |categories: |

| | |

| |- Rules which control processing within the BANNER Web Admissions Application|

| |system. For example, there is a rule which specifies the number of outside |

| |interest slots which will be displayed in Web applications. |

| |- Rules which specify default values for various data elements. These kinds |

| |of rules can apply to both Web and EDI applications. |

| |- Rules which govern how data will be loaded into the permanent BANNER |

| |tables. For example, there is a set of rules which specifies whether |

| |application records will be created if one already exists for the person, |

| |term, level, major, or overall curriculum chosen. |

| | |

| |Rows for this table are not intended to be added locally. Rules which will be|

| |used in system processing will be delivered by SCT, and users will need only |

| |to update the Rule Value to reflect local processing options. |

|SAAQKER |PURPOSE OF FORM |

| |Use this form to enter, build, and maintain values by term and/or level that |

|Title: Quick Entry Rules |will default to the Quick Entry Form (SAAQUIK) in order to speed the process |

| |of admissions and registration. |

|SAAQUIK |PURPOSE OF FORM |

| |The intent of the Quick Entry Form is to provide a way to enter and register |

|Title: Quick Entry |persons on the system with minimal effort. This form is combined with the |

| |General Person Identification Form (SPAIDEN), which allows a person to be |

| |added to the system along with addresses (optional). It can also create |

| |recruiting and admissions records at the user's option, and will automatically|

| |create a student record which is required for registration. |

|SAAWAAD |PURPOSE OF FORM |

| |This form is used for controlling the calendar of applications in the Banner |

|Title: Admissions Web Calendar Rules |production tables. This calendar determines by term when an application can be|

| |viewed, when the status can be viewed, and when the most recent decision can |

| |be viewed. The level, campus, college, and admit type are optional variables |

| |in setting up the calendar. |

|SAAWADF |PURPOSE OF FORM |

| |This form is used to set up rules for the Web page configuration by the Web |

|Title: Electronic Applicant Web Default Rules |application type. The keys to the record are the Web application type and an |

| |effective term. The effective term code in the Default Curriculum block may be|

| |different than the effective term in the key. If the term and curriculum are |

| |entered on this form, the curriculum data will automatically populate the |

| |student’s application when the electronic application is created. The Web data|

| |section for curriculum does not have to be displayed on the Web application. |

| |If the section is displayed, the curriculum entered on SAAWADF will |

| |automatically be filled in. |

|SAAWADP |PURPOSE OF FORM |

| |The Web Application Customized Lists Form (SAAWADP) allows users to customize |

|Title: Web Application Customized Lists |which test codes, requested materials, interests, and credit card waiver |

| |reasons will appear in the appropriate Web pull downs based on application |

| |type. For example, graduate schools can customize their Web application to |

| |show only graduate-related test codes such as GMAT and GRE. |

|SAAWAPP |PURPOSE OF FORM |

| |The Web Application Section Rules Form is used to define the page sections |

|Title: Web Application Section Rules |which will make up each Web Admissions Application and the order in which the |

| |sections will be displayed. Optionally, if a section of an application |

| |includes address information, the address type expected in the address |

| |information should be entered. |

|SAAWATR |PURPOSE OF FORM |

| |SAAWATR can be used to define calendars for the application types that have |

|Title: Electronic Applicant Web Calendar Rules |different schedules. Once this form is used for an application type, it must |

| |always be used. |

|SAAWUDQ |PURPOSE OF FORM |

| |The Web User Defined Questions Form is used to define institution-specific |

|Title: Web User Defined Questions |questions which will be included in the Additional Information section of the |

| |BANNER Web Admissions Application. Institution-specific questions can be |

| |defined for as many Web Application types as an institution requires. |

|SARBDSN |PURPOSE OF FORM |

| |This report is used to calculate automated decisions based on institution |

|Title: Process Submissions Control |rules. The process selects all application records that match the parameter |

| |values. If any of the applications have outstanding checklist items, |

| |regardless of their application status, they will not be processed and will |

| |have a message associated with them on the report. If all checklist items are |

| |received, then the process compares each applicant and/or application against |

| |the rules on SAADCSN. |

|SARDCSN |PURPOSE OF FORM |

| |This report is used to list the automated decision rules set up by the |

|Title: Process Submissions Control |institution on the Admissions Decision Rules Form (SAADCSN). |

|SARETMT |PURPOSE OF FORM |

| |The SARETMT form serves as the form that verifies and loads the information |

|Title: Electronic Application Verify/Load Process |from all electronic applications. |

|SOAATRM |PURPOSE OF FORM |

| |The Web Term Display Control Form is used to specify the terms for which Web |

|Title: Web Term Display Control |Admissions Applications can be submitted, and the calendar periods in which |

| |applications can be submitted for each term. The information on this form |

| |allows each institution to control when admissions applications can be |

| |submitted via the Web. Multiple date ranges are allowed for a specific term |

| |as long as the date ranges for each entry do not overlap. |

|SOABGIY |PURPOSE OF FORM |

| |The Source/Background Institution Year Form is used to capture yearly |

|Title: Source/Background Institution Year |information about a source or background institution. Much of the information|

| |captured is not validated to allow for flexibility. All of the blocks are |

| |dependent on calendar year, providing a historical record of the information. |

| |FORM DEPENDENCIES |

| |The Source/Background Institution Base Form (SOASBGI) must be established |

| |first. |

|SOAEQUI |PURPOSE OF FORM |

| |Used for exception processing, if there are certain combinations of |

|Title: Existing or Incoming Student Data Mapping |student/Web applicant data for which you don’t want to allow a student record |

| |to be inserted. |

|SOAFOLK |PURPOSE OF FORM |

| |The SOAFOLK form manages information that pertains to the legal guardian of |

|Title: Guardian Information |the applicants. This may be the parents information or whoever the legal |

| |guardian happens to be. |

|SOAHOLD |PURPOSE OF FORM |

| |The Hold Form is used to assign holds to a person. The hold information is |

|Title: Hold Information |contained on the Hold Type Code Validation Form (STVHLDD). The Hold Type Code |

| |Validation Form specifies how the person is affected by the hold. Holds may |

| |prevent registration or graduation, or prevent the production of transcripts |

| |and grade mailers. Hold information is created by a particular user and may |

| |only be deleted or changed by that user (unless the user specifies otherwise).|

| |Procedurally, each office should determine a user to create and delete hold |

| |information. Hold information is used in the Registration, Academic History, |

| |and Accounts Receivable Modules. |

|SOAHSCH |PURPOSE OF FORM |

| |This form is used to enter high school information such as school name and |

|Title: High School Information |address, graduation date, subjects taken, course and overall GPA, and class |

| |rank/size. |

| |FORM DEPENDENCIES |

| |The person must be added to the system prior to entering high school data. |

|SOAIDEN |PURPOSE OF FORM |

| |The Person Name/ID Search Form may be accessed from all forms that require an |

|Title: Person Search |ID number in the Key Block. This form may be used to determine the correct ID|

| |number for a person using the query capabilities of the system. The name, ID |

| |number, birth date, and change indicator (an indicator to record name and ID |

| |changes--blank for the current record) are displayed. A second function, the |

| |sounded search, is provided on the bottom of the form. This search allows the|

| |user to enter information (or partial information) for a "sounds like" search.|

| |FORM DEPENDENCIES |

| |All persons available to all other forms will be displayed on this form. The |

| |creation of these persons occurs in the Identification Form (SPAIDEN). |

|SOAPCOL |PURPOSE OF FORM |

| |This form is used to enter information about a person's prior college |

|Title: Prior College |experience. |

| |FORM DEPENDENCIES |

| |A person must be added to the system via the Identification Form (SPAIDEN) |

| |prior to entering this form. |

|SOASBGI |PURPOSE OF FORM |

| |The Source/Background Institution Base Form is used to capture general |

|Title: Source/Background Institution Base |information, such as address, comments and contacts, about a source or |

| |background institution. Most of the information captured is not validated to |

| |allow for flexibility. |

| |FORM DEPENDENCIES |

| |The address information provided on this form is displayed in Academic History|

| |and Admissions. This form is a control form, therefore, the Source/ |

| |Background Institution Validation Form (STVSBGI) must be established first. |

| |The validation form indicates the type of entity (high school or college) |

| |and whether the entity is a source for the institution. |

|SOASRVW |PURPOSE OF FORM |

| |The SOASRVW form managed information that is for the reviewing process for an |

|Title: Student Review Summary |applicant. |

|SOASRVW |PURPOSE OF FORM |

| |The Student Review Summary Form (SOASRVW) is used to display summary |

|Title: Student Review Summary |information about the identification and status of a student in several |

| |modules in the SCT Banner Student System, as well as information about the |

| |existence of data for the student in other SCT Banner systems. |

|SOASUPL |PURPOSE OF FORM |

| |The purpose of this form is to manage all data that may be supplemental to a |

|Title: Application Supplemental Information |prospective application. Much of this information will and can be used for |

| |reporting purposes and other supplemental reporting. |

|SOATEST |PURPOSE OF FORM |

| |The SOATEST form manages the prospective applicant’s test scores and allows |

|Title: Test Score Information |the system to manage multiple scores on one form. |

|SPACMNT |PURPOSE OF FORM |

| |The intent of the Comment Form is to enter comment information on the person. |

|Title: Person Comment | |

|SPAIDEN |PURPOSE OF FORM |

| |The Identification Form is to capture biographic/demographic information for |

|Title: General Person Identification |all persons/non-persons associated with the institution. Persons/non-persons |

| |may belong to any or all of the installed applications (Student, Finance, |

| |etc.). All persons/non-persons are first entered into the database using this |

| |form. The information maintained in this form is specific to the |

| |person/non-person and does not relate to the person's/non-person's involvement|

| |at the institution. All other modules/applications are dependent on the |

| |information captured and maintained in this module. Any changes or additions |

| |to a person's/ non-person's biographic/demographic information must be made in|

| |this form. |

|SPAPERS |PURPOSE OF FORM |

| |The intent of the General Person Form (SPAPERS) is to capture biographic |

|Title: General Person |information for persons. Types of data captured include sex, date of birth, |

| |marital status, legacy information, and whether or not the person is deceased.|

|SPATELE |PURPOSE OF FORM |

| |The purpose of the Telephone Form (SPATELE) is to allow the user to create an |

|Title: General Person Telephone |unlimited number of telephone numbers associated with a person. These |

| |telephone numbers may be associated with an address type and sequence number. |

| |A phone number must be flagged as primary, a "Y" in the primary indicator, |

| |before it is displayed along with the address information. This form is also |

| |accessed from the following forms: |

| |* SPAIDEN - Identification Form |

| |* SRAQUIK - Quick Recruit Form |

| |* SAAQUIK - Quick Entry Form |

| |* SPAEMRG - Emergency Contact Form |

| |* SOAFOLK - Guardian Information Form |

|SRAPRED |PURPOSE OF FORM |

| |Use this form to enter the default recruit values for Web-entered data. You |

|Title: Electronic Prospects Default Options |can designate default values that can be used to populate the recruiting |

| |record (SRBRECR) when it is created via the Migrate Electronic Prospects |

| |Process (SRRPREL) or by using the Create Recruit item in the Options Menu on |

| |the Electronic Prospect Inquiry Form (SRIPREL). This form is also used in the |

| |tape load process. |

|SRAPREL |PURPOSE OF FORM |

| |Use this form to view biographical and search or test score tape data for a |

|Title: Electronic Prospect Detail |person that has been loaded to the temporary tables. The form allows you to |

| |view all search tape records for this ID which are present in the Search Tape |

| |View (SRVPREL). This form is accessed independently or from the Electronic |

| |Prospect Inquiry Form (SRIPREL) using the Detail item in the Options Menu. Use|

| |the Electronic Prospect Detail tab to access the main window from a secondary |

| |window. |

| | |

| |Test Scores and Interests Window |

| |Use this window to view test score and interest information for the record, as|

| |well as how the person learned about the school. Use the Test Scores/Interests|

| |item in the Options Menu or the Test Scores and Interests tab to access this |

| |window. |

|SRAQUIK |PURPOSE OF FORM |

| |The Quick Recruit Form is designed to allow entry of new prospective students.|

|Title: Quick Recruit |Entering GENERATED in the Key Id field will generate a new ID number. This |

| |form allows you to enter address, high school, previous college, and all |

| |necessary recruiting information. A Default Options Block can be accessed to |

| |allow the user to establish |

| |default codes for address type, contact type, recruiter, recruiting status, |

| |and source codes. Once these defaults are established, they will be used each|

| |time a quick recruit is entered. |

|SRAQUIK |PURPOSE OF FORM |

| |The Quick Recruit Form is designed to allow entry of new prospective students.|

|Title: Quick Recruit |Entering GENERATED in the Key Id field will generate a new ID number. This |

| |form allows you to enter address, high school, previous college, and all |

| |necessary recruiting information. |

| | |

| |A Default Options Block can be accessed to allow the user to establish default|

| |codes for address type, contact type, recruiter, recruiting status, and source|

| |codes. Once these defaults are established, they will be used each time a |

| |quick recruit is entered. |

|SRARAPT |PURPOSE OF FORM |

| |The Recruiter Appointments/Visits Form is used to schedule and record daily |

|Title: Recruiters Appointments/Visits |appointments on campus and visits to other sources. Appointments and visits |

| |can be viewed for a given day, a period of days, or an entire term. This form|

| |can be used to reschedule appointments and visits in the case of an emergency |

| |or the absence of a recruiter. |

| |FORM DEPENDENCIES |

| |All appointments and visits entered from this form will appear on the Prospect|

| |Information Form, and likewise all appointments and visits entered on the |

| |Prospect Information Form will appear on this form. In order to add |

| |appointments or visits for a prospect, the prospect must be established on the|

| |Prospect Information Form. |

|SRARECR |PURPOSE OF FORM |

| |The Prospect Information form provides the information necessary for all |

|Title: Recruit Prospect Information |recruitment related activities. This form captures and validates information |

| |on prospective applicants. This information includes sources (high schools, |

| |groups, alumni, and individuals), intended degrees and majors, outside |

| |interests, contacts, materials tracking and cohorts. |

| |FORM DEPENDENCIES |

| |This form is the basis for all related recruiting forms. Much of the |

| |information entered in this form can be viewed (and updated) in other |

| |recruiting forms (e.g. appointments entered are displayed/entered on the |

| |Recruiter Appts/Visits Form (SRARAPT). |

|SRARECR |PURPOSE OF FORM |

| |The Prospect Information form provides the information necessary for all |

|Title: Recruit Prospect Information |recruitment related activities. This form captures and validates information |

| |on prospective applicants. This information includes sources (high schools, |

| |groups, alumni, and individuals), intended degrees and majors, outside |

| |interests, contacts, materials tracking and cohorts. |

| |FORM DEPENDENCIES |

| |This form is the basis for all related recruiting forms. Much of the |

| |information entered in this form can be viewed (and updated) in other |

| |recruiting forms (e.g. appointments entered are displayed/entered on the |

| |Recruiter Appts/Visits Form (SRARAPT). |

|SRARINF |PURPOSE OF FORM |

| |The Recruiter's Prospect Form is a query-only form that displays all of the |

|Title: Recruiters Prospect |prospects that a recruiter is responsible for in a given term. The current |

| |status of the prospect and the prospect's name and ID are provided. The |

| |recruiter may use this form as a starting point by saving the prospect ID see |

| |block help) and transferring to the Prospect Information Form (SRARECR). |

|SRASRCE |PURPOSE OF FORM |

| |The Source Visits/Prospects Form displays the activity in the Recruiter |

|Title: Source Visits/Prospects |Appointments/Visits Form (SRARAPT) and the Prospect Information Form |

| |(SRARECR) from the source point-of-view. The visits that have taken place at |

| |the source, and the prospects identified from the source are displayed. |

| |Additional visits may be entered for the source. |

| |FORM DEPENDENCIES |

| |Visits entered on this form will be displayed on the Recruiter Appointments/ |

| |Visits form. |

|SRASUMI |PURPOSE OF FORM |

| |This is a stand alone query form used to display a summary of all recruiting |

|Title: Prospect Summary |records, both active and inactive, which have been entered for a person. |

| | |

| |This form may also be called from the Prospect Information Form (SRARECR) for |

| |display of all recruiting records entered, and for the selection of the |

| |desired record. It is accessed by performing a DUPLICATE RECORD function from|

| |the Key Block of SRARECR. |

| | |

| |It may also be accessed from the Admissions Application Form (SAAADMS) by |

| |performing a DUPLICATE FIELD function from the Entry Term field of the |

| |Admissions Application Block. |

| |FORM DEPENDENCIES |

| |A recruiting record must first exist for the person whose identification |

| |number is entered in the Key Block. Recruiting records are created through |

| |SRARECR or through the Quick Recruit Form (SRAQUIK). |

| |FUNCTIONS ALLOWED |

| |EXIT WITH VALUE - When accessed through SRARECR or SAAADMS, this function, |

| |when performed from the Prospect Summary Block, will select the record on |

| |which the cursor rests, return you to the appropriate form (SRARECR or |

| |SAAADMS), and perform a NEXT BLOCK function, retrieving the information |

| |associated with the selected recruiting record. |

|SRAWACK |PURPOSE OF FORM |

| |Use this form to customize the acknowledgement letter. The acknowledgement |

|Title: Web for Prospects Acknowledgement Letter |letter will appear on the Web page after the student presses the Submit |

| |button. Enter a code from STVPREL in the Web Electronic Prospect Code field in|

| |the key, and use Next Block to see the sequence numbers and variables for the |

| |letter. The prospect codes on STVPREL must have the Enter on WEB checkbox |

| |checked in order to be displayed in the list of values for the Web Electronic |

| |Prospect Code field on SRAWACK. |

|SRAWPDS |PURPOSE OF FORM |

| |Use this form to reduce the number of choices the student can select from or |

|Title: Web for Prospects Display Rules |to change the descriptions that will display on the Web. This is accomplished |

| |by customizing the pull down lists with specific values from SCT Banner |

| |validation tables. All list boxes in the Web for Prospects Web pages are |

| |populated from SCT Banner validation tables. |

|SRIPREL |PURPOSE OF FORM |

| |This form is used to query and view records in the Search Tape View (SRVPREL).|

|Title: Electronic Prospect Inquiry |This form is also used in conjunction with the Search Tape Matching Process |

| |(SRRSRIN) and the Migrate Electronic Prospects Process (SRRPREL). |

|STVADMR |PURPOSE OF FORM |

| |The Admission Request Checklist Validation Form is used to codes, descriptions|

|Title: Admission Request Checklist Code Validation |and processing rules for items used admission checklist processing. Other |

| |forms use this form to validate admission request checklist codes. The user |

| |can create or update the admission request checklist items only from this |

| |form. |

|STVAPDC |PURPOSE OF FORM |

| |This form is used to create, update, insert, and delete admission application |

|Title: Admission Application Decision Code |decision codes (i.e., pending decision, quick admit, applicant withdrawal, |

|Validation |etc.). Other forms use this form to validate the admission application |

| |decision codes. The user may only create or update these codes from this |

| |form. |

|STVAPST |PURPOSE OF FORM |

| |The Admissions Application Status Code Validation Form is used to define codes|

|Title: Admission Application Status Code Validation |and processing rules for the statuses which can be assigned to BANNER |

| |admission applications. |

| | |

| |SYSTEM REQUIRED VALUES |

| |A number of values are system-required. These values will be assigned to and |

| |updated in BANNER admissions applications as applications move through the |

| |processing cycle. |

| |- I - Incomplete Application - will be automatically assigned to an |

| |application if there are mandatory checklist items for the application which |

| |have not yet been received. |

| |- C - Complete, Ready for Review - will be automatically assigned to an |

| |application when all mandatory checklist items have been received as long as |

| |no significant decision has been posted to the application. |

| |- D - Decision Made - will be automatically assigned to an application when |

| |the first significant decision is posted to the application. |

| | |

| |Automatic updating of application status will occur until a user manually |

| |posts an application status to the application. |

|STVPREL |PURPOSE OF FORM |

| |Use this form to define the various types of search or test score tapes that |

|Title: Electronic Prospect Load Validation |are to be loaded. |

|STVSBGI |PURPOSE OF FORM |

| |The Source/Background Institution Validation Form is used to define codes, |

|Title: Source/Background Institution Code Validation|descriptions, and processing rules for institutions and organizations which |

| |areas school and other sources of students. Institutions which are high |

| |school or colleges are background institutions. Marketing campaigns or |

| |referral agencies are examples of sources. Sources are used only in the |

| |Recruiting and Admissions modules of the BANNER Student System, but high |

| |school and college codes are used across many BANNER systems. |

| |More detailed information, like source or institution address and contact |

| |persons, is maintained on other forms, especially the Source/Background |

| |Institution Base Form (SOASBGI). |

|STVWAPP |PURPOSE OF FORM |

| |The Application Type Code Validation Form is used to define codes and other |

|Title: Application Type Code Validation |processing rules for BANNER Web Admissions Applications. Each application |

| |type to be used in the BANNER Web processing must be defined. In addition, |

| |the Student Level, Student Type, and Admission Type associated with each |

| |Application Type will be defined. When a Web application is loaded into |

| |BANNER, the values specified for these fields will be used in the created |

| |applications. |

| | |

| |Correct definition of Application Types will increase the likelihood that you |

| |will get valid and complete information from applicants in Web Admissions |

| |Applications. For example, different information is generally required from |

| |undergraduate freshmen, undergraduate transfers, graduate applicants, and |

| |international undergraduates. Because institutions can define the sections |

| |which will be part of each Web application type, they can highly customize the|

| |information which will be requested (and/or required) from each Web applicant.|

| |SCT recommends that institutions define, at minimum, separate Undergraduate |

| |Freshman, Undergraduate Transfer, and Graduate application type (as |

| |appropriate for the institutions) and also consider separate application types|

| |for different types of international applicants (for example, International |

| |Undergraduate Freshman, International Undergraduate Transfer, International |

| |Graduate). |

|STVWSCF |PURPOSE OF FORM |

| |This form is used to define the data elements that can be used on a Web |

|Title: Admissions Web Page Element Validation |application. It is also used to define within which section that data element |

| |will display. These values are delivered by SunGard SCT and are not meant to |

| |be updated. This validation form is used by the Web Application Section Rules |

| |Form (SAAWAPP) to create Web applications. |

|STVWSCT |PURPOSE OF FORM |

| |The Web Application Section Validation Form is used to define Web Application |

|Title: Web Application Section Validation |Section codes and descriptions and to specify basic processing rules for each |

| |section. Information maintained on this form is used only in BANNER Web |

| |Admissions Application processing. |

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download