Banner Student Self-Service Admissions Training Workbook Release 8.3 - December 2009 Updated 2/25/2010
_______________________________________________________________________________________________

Prepared by: Ellucian

4375 Fair Lakes Court

Fairfax, Virginia 22033

United States of America

Customer Support Center website

http://connect.ellucian.com

Distribution Services e-mail address

distserv@ ellucian.com

Other services

In preparing and providing this publication, Ellucian is not rendering legal, accounting, or other similar professional services. Ellucian makes no claims that an institution's use of this publication or the software for which it is provided will insure compliance with applicable federal or state laws, rules, or regulations. Each organization should seek legal, accounting and other similar professional services from competent providers of the organization's own choosing.

Trademark

Banner®, Colleague®, PowerCAMPUS®, Luminis® and Datatel® are trademarks of Ellucian or its affiliates and are registered in the U.S. and other countries. Ellucian, Advance, Recruiter, and Open Digital Campus are trademarks of Ellucian or its affiliates. Other names may be trademarks of their respective owners.

Revision History Log

Publication Date	Summary
December 2009	New version that supports 8.3 software.

Notice of rights

Copyright © Ellucian 2004-2012.

This document is proprietary and confidential information of one or more of the Ellucian companies and is not to be copied, reproduced, lent, displayed used or distributed except under license from Ellucian. Third party copy centers are advised that clients of Ellucian that have licensed the underlying technology associated with this documentation have a valid license to copy and use this documentation in accordance with that underlying license.

Table of Contents

Introduction	4

Process Introduction	6

Set Up	8

User Interface Modernization	9

Validation and Rules That Control Admissions Self-Service	11

Displaying New Person Fields for Internationalization	13

Application Type Code Validation	15

Electronic Application Section Code Validation	17

Web Application Elements	19

Displaying Validation Forms on the Web	21

Defining User Defined Questions	25

Building Admissions Self-Service Applications by Combining Sections	27

Determining Use of Medical Information Question	30

Customizing Web Menus	32

Existing or Incoming Student Data Mapping	34

Customizing the Signature Page	37

Customizing Web Application Data	46

Building QuickStart Processing	50

Populating the EDI Cross-Reference Rules Form	60

Customizing Curriculum Rules and Defining EDI Cross- Reference Curriculum Rules	66

Establishing Dates for the Creation and Receipt of Students’ Applications	72

Updating or Defining the Procedures and Routines for Each Application Type	78

Reviewing and Updating Rule Values	83

Set up Accept Admissions Offer on the Web	86

Self Check	90

Answer Key for Self Check	91

Day-to-Day Operations	92

Process Introduction	93

Displaying Received Web Applications	94

Matching, Verifying, and Loading the Web Applications	96

Resolving Suspended Electronic Applications	99

Resolving Verification Errors	102

Re-Running SARETMT in Update Mode	104

Summary	106

Self Check	107

Answer Key for Self Check	110

Appendix	113

Forms Job Aid	114

Terminology	116

Introduction

Course goal

The goal of this workbook is to provide you with the knowledge and practice to setup Admissions Self-Service and process Web admissions applications. The workbook is divided into these sections:

Introduction

Set Up

Day-to-Day Operations

Reference

Course objectives

In this course you will learn how to

set up all controls to create a web application

create user defined questions

create verification steps for web applications submitted

review submitted electronic applications

reconcile suspended applications

run verification steps for electronic applications

override verification steps not satisfied

“PUSH” verified applications into permanent Banner tables.

Intended audience

Admissions Office Applicant Processing Staff and members of the IT department.

Prerequisites

To complete this course, you should have

completed the Education Practices computer-based training (CBT) tutorial Banner 8 Fundamentals, or have equivalent experience navigating in the Banner system

administrative rights to create and perform the necessary set up in Banner

know the basics of the Banner Student Admissions module

review General Web controls

set up the global Web rules using the Customize Web Rules in WebTailor

set up the title, header, back URL and link, and help URL and link fields using Customize a Web Menu or Procedure in WebTailor.

Process Introduction

About the process

The Admissions Self-Service product includes Banner set up enabling applicants to submit an application on the web as well as review the status of applications already submitted. They may also respond to offers of admission on the web as well.

Flow diagram

This diagram highlights where the Self-Service Admissions process occurs within the overall Student process.

About the process

Rules, control forms and validation forms that control web processing are set up on the Banner system. Unless a new code is required, these steps are only performed once.

Values that will be displayed on the web are web-enabled on the Banner system.

Web pages are customized using WebTailor.

Quick Start Processing rules are defined.

Set Up

Section Goal

The goal of this section is to outline the set-up process and detail the procedures to set-up your Banner system to enable applicants to submit information to your institution.

Objectives

In this section you will learn how to

set up all controls to create a web application

create user defined questions

create verification steps for web applications submitted.

User Interface Modernization

Overview

The release of Banner Web Tailor 8.3 includes an optional user interface modernization that institutions’ site administrators may choose to implement. This modernization is easy to apply or undo, and provides the following benefits:

A user-centric design approach

Improved usability

Consistent and appropriate user interfaces for the global community

Persona-driven workspaces

The changes to the user interface do not change the functionality of the actual Self-Service Banner pages themselves; users will be able to perform the same tasks using either interface. The new user interface is optional at this time; institutions that choose to continue using the “Classic” Self-Service Banner user interface may do so.

Impact on this workbook

Since the new interface is optional for this release, the screenshots and steps included in this workbook will continue to be based on the “Classic” Self-Service Banner user interface. However, the common functionality between the two interfaces should make the workbook applicable to institutions using either interface. In cases where the steps for each interface differ in a way that impacts functionality, the lesson will make this clear and provide guides for each interface; otherwise, users of the new interface can substitute in the appropriate navigation steps as needed.

Modernized Interface

Some of the enhancements to the user interface are listed below:

The Breadcrumb Path displays the module and menu that you are currently viewing. These components are links; you may click them at any time to return to that level.

The tab-based interface of Self-Service Banner is replaced by buttons for each available module. If your roles grant you access to more modules than can fit on the screen at one time, the arrows at either side of the screen will allow you to navigate between them.

The enhanced Search functionality will allow you to locate Self-Service Banner pages based on entered search terms. For example, entering Trans in the Search field will return pages involving transcripts, transfer students, and such.

The screens are compartmentalized in such a way that in many cases, the module menu will remain on the screen at the same time as submenu options are displayed. In the example above, the Benefits and Deductions options are available, but other Employee submenus such as Time Sheet, Leave Report and Request Time Off also remain visible and clickable. This will result in more efficient browsing of the site.

Validation and Rules That Control Admissions Self-Service

Introduction

Before the Admissions Self-Service product can be used, there are several forms and rules that need to be set or created.

Rule forms needed

These forms are used to set the rules and parameters in Banner for handling Self-Service Admissions. Directions on how to set the parameters start on the next page.

Form Description	Banner Name
Application Type Code Validation	STVWAPP
Electronic Application Section Code Validation	STVWSCT
Web Application Elements	STVWSCF
Admission Request Checklist Code Validation	STVADMR
Admissions Application Status Code Validation	STVAPST
Admissions Application Decision Code Validation	STVAPDC
Web User Defined Questions	SAAWUDQ
Web Application Section Rules	SAAWAPP
Web Application Customized List	SAAWADP
Existing or Incoming Student Data Mapping	SOAEQUI
Letter Code Validation	GTVLETR
HTML Letter Rules	SOAELTL
Format HTML Letter Rules	SOAELTR
Electronic Web Applicant Default Rules	SAAWADF
EDI Cross Reference Rules	SOAXREF
EDI Cross Reference Curriculum Rules	SOAXCUR
Web Application Customized Curriculum	SAAWCUR
Electronic Applicant Web Calendar Rules	SAAWATR
Web Application Term Display Control	SOAATRM
Admissions Web Calendar Rules	SAAWAAD
Electronic Admissions Procedure/Routine Control	SAAECRL
Electronic Admissions Application Rules	SAAERUL

Displaying New Person Fields for Internationalization

Introduction

A major initiative of Ellucian is to make Banner more adaptable for use in different countries and with different languages. This ongoing effort is called internationalization (often abbreviated I18N).

As part of this initiative, Banner Student 8.0 delivered several new fields in the database. These fields, however, were not visible on the user interface. With Banner Student 8.2, these new fields can be displayed on forms and reports. This enhancement provides worldwide clients with a more robust, accurate, and efficient method of storing personal data.

New person fields

The following person fields are now available on several Banner Student Forms and reports:

Field	Length	Description
Last Name Prefix	60 characters	Prefix that precedes a last name (for example, “Von” in the last name “Von Hintz”)
House Number	10 characters	Unique number assigned to each building on a street or in an area and used as part of the postal address in some countries (no validation)
Street Line 4	75 characters	Additional street address (no validation)
Telephone Country Code	4 characters	Code that designates the region and country of the telephone number (no validation)

Masked fields

Some users do not need these new fields on Banner forms. For this reason, Banner Student 8.2 is being delivered with masking rules turned on for these new fields. This means the fields are not displayed on forms when you first upgrade to Banner Student 8.2. If you want to display the new fields, you can do one of the following:

Run the gssmask.sql script, delivered with Banner General 8.2, to unmask the new fields. Refer to the Banner General 8.2 Release Guide for more details.

Use the Data Display Mask Rules Form (GORDMSK) to unmask the fields. You can unmask specific fields on specific forms. Refer to the Banner General Data Security Handbook for more details.

Masking rules apply only to name fields when they are displayed independently (that is, not concatenated). If fields are concatenated, the masking rules do not apply. It is assumed that the fields where data would normally be entered would be masked, preventing data entry. As a result, no values would be available for display on forms when the fields are concatenated.

Changed forms

Several forms can display the new person fields. Some forms display all new person fields; other forms display some of the new person fields. In general, the new person fields are displayed on forms as follows:

Last Name Prefix is displayed before the Last Name field.

House Number is displayed before the Street Line 1 field.

Street Line 4 is displayed after the Street Line 3 field. (If a form does not include Street Line 3, then Street Line 4 is not included on the form.)

Telephone Country Code is displayed before the Telephone Area Code field.

The following forms support the new person fields:

Electronic Application Process Form (SAAEAPS)

Electronic Application Verify/Load Process (SARETMT)

Application Type Code Validation

Purpose

The Application Type Code Validation Form (STVWAPP) is used to identify application codes and define the level, student type, and admission types associated with the code. You can also choose which codes to display on the Self-Service website and indicate which codes is system required.

Banner form

Steps

Follow these steps to create an application type code.

Access the Application Type Code Validation Form (STVWAPP).

Enter a code in the Code field.

Enter a description in the Description field.

Select a level in the Level field.

Select a student type code in the Student Type field.

Select an admission type code in the Admission Type field.

Click the Web Indicator checkbox.

Note: The System Required checkbox specifies whether a value is required by the system. If this checkbox is checked, the validation table record cannot be deleted. .

Click the Save icon.

Click the Exit icon.

Electronic Application Section Code Validation

Purpose

The Electronic Application Section Code Validation Form (STVWSCT) is used to define the procedure for each section code.

Banner form

Steps

Follow these steps to define the procedure for each section code.

Access the Electronic Application Section Code Validation Form (STVWSCT).

Review the codes listed.

Perform an Insert Record function if additional codes are needed.

Enter a section code in the Section Code field.

Enter a description of the section code in the Description field.

Note: The Sys Req checkbox specifies whether a value is required by the system. If this checkbox is checked, the validation table record cannot be deleted. .

Enter StuWebInfoball in the Image field.

Enter the procedure code in the Procedure field.

Click the Save icon.

Click the Exit icon.

Web Application Elements

Purpose

The Web Application Elements (STVWSCF) is used to link an element code to a web section code.

Example: The Web Section code ADDR2 contains the following elements: ADDR2_City, ADDR2_County, ADDR2_Nation, ADDR2_Phone_Number, ADDR2_Street1, ADDR2_Street2, ADDR2_Street3, and ADDR2_Zip.

Banner form

Steps

Follow these steps to define the web application elements.

Access the Web Application Elements (STVWSCF).

Enter an element code in the Element Code field.

Enter a description of the code in the Description field.

Note: The System Required checkbox specifies whether a value is required by the system. If this checkbox is checked, the validation table record cannot be deleted. .

Select a web section in the Web Section field.

Click the Save icon.

Click the Exit icon.

Displaying Validation Forms on the Web

Introduction

Several admissions-related validation forms include Web Display Indicator checkboxes. These indicators control whether a specific value in the validation form will display or be available for selection via the Web. Scripts that added the Web Indicator fields set the Web Indicator checkbox to unchecked (set to N) for all values on these forms. It must be checked (set to Y) for a value to be available on the Web. When you Web enable a value in one of these validation forms, you should also review the description. The description of a value, not the code itself, displays on the Web.

Validation forms

The following validation forms include Web Display Indicator checkboxes that control admissions application processing via the Web.

Admission Request Checklist Code Validation Form (STVADMR)

Admission Application Status Code Validation Form (STVAPST)

Admission Application Decision Code Validation Form (STVAPDC)

Banner form

Admission Request Checklist Code Validation Form (STVADMR). An applicant's outstanding checklist items display in the Review Application Status section of the Web when the checklist item is Web enabled.

Steps

Follow these steps to set up the applicant’s outstanding checklist items for display.

Access the Admission Request Checklist Code Validation Form (STVADMR).

Verify that the Web Indicator checkbox is checked for all desired application requirements.

Click the Save icon.

Click the Exit icon.

Banner form

Admission Application Status Code Validation Form (STVAPST). The indicated values display when an applicant reviews his or her applications via the Web. If the status of an existing application has not been Web-enabled, the descriptionNot Availableis displayed.

Steps

Follow these steps to create and maintain application status codes for web display.

Access the Admission Application Status Code Validation Form (STVAPST).

Verify that the Web Indicator checkbox is checked for all application statuses desired.

Click the Save icon.

Click the Exit icon.

Banner form

Admission Application Decision Code Validation Form (STVAPDC). If an application is entered into Banner (either manually or via the Web), the calendar on SAAWAAD is set up, and the Display on Web check box is checked on STVAPDC and then the most recent decision for that application displays on the Web Application Summary Page. If the decision code has not been Web enabled, then the descriptionPlease Contact Admissions Officeis displayed.

Steps

Follow these steps to web-enable the application decisions code(s).

Access the Admission Application Decision Code Validation Form (STVAPDC).

Verify that the Display on Web check box is checked for all decision codes desired.

Click the Save icon.

Click the Exit icon.

Defining User Defined Questions

Introduction

The Web User Defined Questions Form (SAAWUDQ) is used to define institution-specific questions that request information not found elsewhere in any application section. You can use the form to develop questions to collect any additional kind of information your processing requires. The user can specify that an ADMR checklist code be associated with a Question/Answer. In addition, they can indicate that a question should have a Yes/No radio button as the answer option on the Web.

Up to ten user-defined questions can be displayed on any application section, and up to twenty user-defined questions can be displayed in the Additional Information section. In addition, the user can also display up to ten essay questions in the essay section (v. 5.4). Each question can be up to 2000 characters in length. The applicant has 2000 characters to answer each non-essay question and up to 32,700 characters to answer each essay question.

Banner form

Steps

Follow these steps to set up the web user defined questions.

Access the Web User Defined Questions Form (SAAWUDQ).

Perform an Insert Record function.

Select a value in the Application Type field.

Enter a number in the Ordering Sequence field.

Enter the question to be answered by the student in the Question Text field.

Click the Save icon.

Click the Exit icon.

Building Admissions Self-Service Applications by Combining Sections

Combining sections and elements

In earlier steps, you reviewed or created Electronic Application Types (using STVWAPP) and reviewed delivered Web Application Sections (STVWSCT) and Web Application Elements (STVWSCF). Now it is time to combine the sections and elements to make an application. Sections include the actual questions that applicants are asked to answer, and each application is composed of a set of sections in a specific order.

Web Application Section Rules Form

The Web Application Section Rules Form (SAAWAPP) is used to define the sections and elements that make up each application type. It also is used to specify the address type for each section of an application that collects address information. This form allows the user to determine in what order the sections appear and in what order the data elements appear within a section. Users can designate an element as required on this form, as well as indicate if the element should display on the Web. Users can also assign specific questions that were previously defined on SAAWUDQ to a Web section.

Web Application Section—Data Element Rules window

Use the Web Application Section—Data Element Rules (SAAWAPP) window to enter the data elements that display on a given section.

The first time you enter this window when defining a new section, all the data elements defined on STVWSCF for that Web section populate the window. The user can then reorder the elements and delete any not automatically marked as required. This window enforces the entry requirement of First and Last name, Street Line 1, City, and Choice of Study before an application can be marked complete.

This window allows updates to the Order, Label, Question, Required, and Display Indicator fields.

The Element Rules block is sorted by the Display Order field. When data elements initially populate the Element Rules block, their order is automatically set in increments of five. The user can update the Display Order field or delete an entire data element record.

The user can copy the sections and elements set up for another application type to a new application type by using the Copy Configuration icon.

User-defined questions

If the existing application type makes use of user-defined questions, those questions must also be defined on SAAWUDQ for the new application type prior to performing the Copy function. Otherwise, an error will occur when the copy is attempted.

Banner form

Steps

Follow these steps to define the sections and elements that make up each application type.

Access the Web Application Section Rules Form (SAAWAPP).

Select a value in the Web Application Type field.

Perform a Next Block function.

Enter a number (to determine in what order the section will appear) in the Display Order field.

Select a value in the Web Section field.

Example: International Information

Select a value in the Address Type field.

Note: The Activity Date field defaults when you save your work.

Click the Save icon.

Perform a Next Block function to navigate to the Data Elements window.

Enter a number (to determine in what order the element will appear) in the Display Order field.

Select a value in the Element Code field.

Example: Nickname

Click the Save Icon.

Click the Exit icon.

Determining Use of Medical Information Question

Introduction

Determine whether you want to collect medical information on applications received via the Web. The data element, Medical, can be defined under the Personal Information section rule on SAAWAPP. This data element displays the Web-enabled values defined on SOAXREF (where the label is equal to STVMEDI). If no values are defined on SOAXREF, then the drop-down menu displays all values in the Medical Code Validation Form (STVMEDI).

Banner form

Steps

Follow these steps to specify whether you want to collect medical information on applications received via the Web.

Access the Web Application Section Rules Form (SAAWAPP).

Select the Web application you have been working with in the Web Application Type field.

Enter a number (to determine in what order the element will appear) in the Display Order field.

Select Personal Information in the Web Section field

Click the Save icon.

Note: The Activity Date field defaults when you save your work.

Click the Exit icon.

Customizing Web Menus

Introduction

Define codes, by application type, on the Web Application Customized Lists Form (SAAWADP) that should display in the Web menus for test codes, requested materials, interests, and credit card waiver reasons. If no codes are defined here, the menu values are taken from the appropriate Web-enabled rows on SOAXREF. If no codes are defined on SOAXREF, the values are taken from the appropriate validation table.

Banner form

Steps

Follow these steps to define the customized codes.

Access the Web Application Customized Lists Form (SAAWADP).

Select the Web application you have been working with in the Web Application Type field.

Select a value in the Validation Table Name field.

Navigate to the Table field.

Result: The table entered in the Key block defaults.

Select a code in the Code field to appear on the Web menu.

Repeat the above steps until all codes to appear on the Web menu are entered for the application type.

Note: The User and Activity Date fields default when you save your work.

Click the Save icon.

Click the Exit icon.

Existing or Incoming Student Data Mapping

Purpose

The Existing or Incoming Student Data Mapping Form (SOAEQUI) is used to compare web application data with the existing student data in the system. If there is a match, the rule with the highest priority number (1=highest) is used. In this way, you can set up rules that review that student’s status, academic status, and registration status by College, Degree, Program, and Major.

Example: A former student in the nursing program who left the school in good academic standing would be eligible to register while you could set another rule that would make a former student who left the nursing program because of academic suspension ineligible to register for the nursing program.

Banner form

Steps

Follow these steps to set up the comparison of web application data with existing student data.

Access the Existing or Incoming Student Data Mapping Form (SOAEQUI).

Select a term in the Existing Term field.

Select a level code in the Existing Level field.

Select a college code in the Existing College field.

Select a degree code in the Existing Degree field.

Select a program code in the Existing Program field.

Select a major code in the Existing Major field.

Select a term in the Incoming Term field.

Select a level code in the Incoming Level field.

Select a college code in the Incoming College field.

Select a degree code in the Incoming Degree field.

Select a program code in the Incoming Program field.

Select a major code in the Incoming Major field.

Perform a Next Block function.

Enter a number in the Priority field.

Select a status code in the Student Status field.

Select an academic status code in the Academic Status field.

Select a registration status code in the Registration Status field.

Enter a term in the End Term field for Existing Student data.

Enter a term in the End Term field for Incoming Student data.

Select a letter code in the Letter Code field.

Click the Save icon.

Click the Exit icon.

Customizing the Signature Page

Introduction

A Signature page is delivered with the Banner Web Admissions Application, and its display is controlled using the SIGPAGEDISP label rule on the Electronic Admissions Application Rules Form (SAAERUL) for the group of DISP. The Signature page allows you to provide processing instructions to applicants who submit applications via the Web.

Examples: Information such as Remit an Application Fee of $25, or Print, Sign, and Return this Page to the Admissions Office to Complete Your Application, or any other information you wish to have the student complete as part of the Application Process.

Customizing the Signature page

The default Signature page is Info Text for the page. Sample Info Text for this page is delivered, but you can customize it to reflect your institution's processing and desired instructions. Use the Format HTML Letter Rules Form (SOAELTR) to update the Information Text for the Display Signature package to reflect your institution's desired instructions, if you decide to have the Signature page displayed.

You can customize the Signature page by application type using the Electronic Applicant Web Default Rules From (SAAWADF). The Signature Page Letters window is used to assign customized letters to specific letter types. The letter type of Standard is used to assign a Signature page for Web applicants not using QuickStart processing. The other letter types are used with QuickStart processing to identify which letter should be displayed, depending on the circumstances (i.e., a record is suspended during the automatic match).

Banner form

Steps

Follow these steps to create letter codes.

Access the Letter Code Validation Form (GTVLETR).

Perform an Insert Record Function.

Enter a code in the Letter Code field.

Example: ADM_CHKL

Enter a description for your code in the Description field.

Example: Admissions Checklist Letter

Click the Save icon.

Click the Exit icon.

Banner form

Steps

Follow these steps to complete the process of creating letter codes.

Access the HTML Letter Rules Form (SOAELTL).

Select the letter code in the Letter field that you want to associate with the appropriate module code.

Select the appropriate code in the Module field.

Click the Save icon.

Click the Exit icon.

Banner form

Steps

Follow these steps to construct letter contents.

Access the Format HTML Letter Rules Form (SOAELTR).

Select a code in the Letter Code field.

Enter a number indicating placement of variable and text in the email letter in the Sequence Number field.

Select a value in the Formatting field.

Select a variable in the Variables field.

Enter free-form text in the Text field.

Click the Save icon.

Click the Display Letter button to review letter.

Click the Exit icon.

Note: The package HWSKASGN organizes the letter and places it on the Signature Web page after the application is marked complete.

Banner form

Steps

Follow these steps to customize the Signature page.

Access the Electronic Applicant Web Default Rules Form (SAAWADF).

Select a value in the Web Application Type field.

Select a term in the Effective Term field.

Perform a Next Block function.

Result: The information defaults.

Select a term in the Effective Term field in the Default Curriculum block.

Click the Save icon.

Select the Web Signature Letters tab.

Select a code in the Letter Code field to view the codes.

Click the Return button to return to SAAWADF.

Click the Save icon.

Click the Exit icon.

Banner form

Steps

Follow these steps to activate/inactivate the Signature page.

Access the Electronic Admissions Application Rules Form (SAAERUL) to Activate/Inactivate the Signature page.

Enter DISP in the Group field.

Enter SISPAGEDISP in the Rule Label field.

Enter True to Activate Signature page or False to Inactivate Signature page in the Value field.

Click the Save icon.

Click the Exit icon.

Banner form

Steps

Follow these steps to customize Info Text.

Select the Enter Secure Area link from the Web Self-Service homepage.

Enter your user ID or 710000011in the User ID field.

Enter your personal identification number in the PIN field.

Note: If you are using 710000011 (Eugene Adams) as your login ID, the PIN should be 123456. If the PIN does not work, click the Forgot PIN? button. The answer to the question “What color is the sun?” is Yellow. Reset the password to 123456.

Click the Login button.

Click the WebTailor Administration tab.

Select the Web Menus and Procedures link.

Select hwskalog.P_DispSigPage from the list.

Scroll to the bottom of the page and click on Customize Information Text.

Edit/add info text and adjust order as needed.

Click the Exit icon.

Customizing Web Application Data

Introduction

The Electronic Applicant Web Default Rules Form (SAAWADF) is used for entering default data and rules for curriculum, email address, link text, and credit cards, as well as customizing the Signature page on the Web for a given Web 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. For a curriculum to be used on this form, it must first be set up on the EDI Cross-Reference Curriculum Rules Form (SOAXCUR). If the term and curriculum are entered on this form, the curriculum data automatically populates 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 automatically fills in.

Defining the email address and email link text

The form can be used to define the email address and the email link text that appears on the Application Checklist menu on the Web page. If no link text or email address exists on this form, but the EMAILSENDADDR and EMAILSENDLINK rules exist on SAAERUL where the value in the Group field is equal to ADMS, then that link text displays on the Application Checklist menu and that email address becomes the To: address.

Defining credit card processing rules

The Application Credit Card Fee Rule window on SAAWADF is used to define the credit card processing rules. The institution indicates if they accept credit cards, and if they do, the following decisions must be made: are they required, are waivers allowed, what detail code should be associated with the payment, and what, if any, checklist rule is satisfied by the credit card payment. The Detail Code and Dollar Amounts are required fields, and the Detail Code field must have a category code of APF.

Banner form

Steps

Follow these steps to customize default data and rules for curriculum, email address, link text, and credit cards, as well as customizing the Signature page on the Web for a given Web application type.

Access the Electronic Applicant Web Default Rules Form (SAAWADF).

Select the Web application you have been working with in the Web Application Type field.

Select a term the Term field.

Perform two Next Block functions.

Select a curriculum in the Curriculum field in the Primary Curriculum block.

Note: For a curriculum to be used on this form, it must first be set up on the EDI Cross-Reference Curriculum Rules Form (SOAXCUR)—(this form is reviewed later in the workbook). If the term and curriculum are entered on this form, the curriculum data automatically populate the student’s application when the electronic application is created.

Click the Save icon.

Select the E-mail and Credit Card Rules tab.

Enter an email address in the Email Address field.

Enter the text that displays on the Application Checklist menu in the Link Text field.

Perform a Next Block function.

Select a value in the Charge Detail field.

Example: Application Fee

Enter a dollar amount in the Amount field.

Click the appropriate radio buttons and/or checkboxes (Allow Credit Card, Require Credit Card, Do Not Allow Credit Card, Allow Waiver, Transactions to Miscellaneous Table).

Click the Save icon.

Click the Return button.

Click the Exit icon.

Building QuickStart Processing

Behind the scenes

QuickStart processing begins automatically when either:

The Application Complete icon is clicked on the Web Application Checklist page, and credit card processing has been turned off for the application type on SAAWADF, or

Credit card processing is enabled on SAAWADF and:

The applicant selects the Pay Later icon on the Application Fee Payment page.

The applicant selects the Signature Page icon from the Payment Status page after successfully processing their credit card payment.

Step 1

The match package is run to determine if the Web applicant matches an existing Banner person. The processes indicated in the steps below, i.e. “verification routines” run automatically when Quick Start is set up.

Step 2

If the match package returns a status of S (Suspended) or E (Error), then the application status code is updated on SAAEAPS, and the Display Signature package (hwskalog.p_dispsigpage) displays the letter code associated with the SUSPENSE or MATCHERR letter types respectively.

Step 3

QuickStart processing checks to see if the Automatically Create Application Record checkbox is checked on SAAWADF. If it is checked, the verification routines run automatically (the same routines as run on SAAEAPS or with the SARETMT process).

If any errors are encountered during the verification process, the Status App field on SAAEAPS is updated appropriately, and the Signature Display package (hwskalog.p_dispsigpage) displays the letter assigned to the VERERR letter type on SAAWADF.

Step 4

Now the create_appl package is run. It first checks for the existence of an application hold for the Web applicant (assuming they had matched someone in Banner).

If an application hold exists, then the Status Application field on SAAEAPS is updated appropriately, and the Display Signature package displays the letter assigned to the APPLHOLD letter type on SAAWADF. If no application hold exists, the application is created.

Step 5

If the Automatically Create Application Record checkbox is checked, then you can optionally request that a decision record be created as well. The decision record uses the admissions decision code stored on the Automated Processing Rules window of SAAWADF. Just as with SAAQUIK, no decision code with the Inactive Application checkboxes checked on STVAPDC can be created.

In addition, the Automatically Create Student Record checkbox must be checked to have a decision record inserted. If QuickStart processing indicates that a student record cannot be created, then no decision record is inserted if the decision code would generate a student record.

Step 6

If the Automatically Create Recruit Record checkbox is checked, run the create_recruit package to create a recruit record on SRBRECR.

Step 7

If the Automatically Create Student Record checkbox is checked, look at the Auto Student checkbox on SAAWCUR and SOAXCUR for the applicant’s curriculum to see if QuickStart processing is allowed for that curriculum.

If QuickStart processing is not allowed for the curriculum, then no student record is created, and the letter associated with the standard letter type is displayed. If you selected the option to create a recruit or application record, these will be created.

Step 8

If QuickStart processing is allowed for the curriculum and the match status returned earlier is N (New), a student record is created for the Web applicant, and the Signature page is displayed with the letter assigned to the QUIKADMIT letter type.

Step 9

If the match status returned earlier is M (Match), SOAEQUI is queried to see if the Web applicant’s most recent Banner student record and Web application match any of the exception processing rules on the form.

If one or more rules match, then the rule with the highest priority number is used (1 = highest), and no student record is created. If that rule has a letter code associated with it, then that letter is displayed as the Signature page.

If no letter code exists, then the letter associated with the NOSTUREC letter type is displayed. If no letter code has been assigned to the NOSTUREC letter type, then the letter associated with the DEFAULT letter type is displayed. If no letter has been assigned to the DEFAULT letter type, the default WebTailor letter is displayed.

Application status errors and resolutions

The following table shows possible application status codes that can be generated by the QuickStart process and how they may be resolved. They can be viewed on SAAEAPS.

Application Status Code	Description/Resolution
H	Admissions Hold If an admissions hold exists for an applicant, their application status is updated to H, and their record cannot be pushed on SAAEAPS until the hold is removed on SOAHOLD. Even if the hold is removed, only an application record can be created, not a student or decision record. Perform the following steps Remove the hold on SOAHOLD, if appropriate. Run the Verification Process by selecting Verify Application from the Options menu of SAAEAPS. This process runs even though the Status App field is set to H. Run the Load Application process by selecting Load Application from the Options menu in the main window of SAAEAPS. Assuming no other errors occur, the application should be pushed. It will not, however, automatically create a student record if that was indicated for the application type on SAAWADF. The institution has to do that manually. It will create the recruit record though, if that was indicated on the Automated Processing rules window of SAAWADF. You can also run SARETMT to verify and push the application having an application status of OK H, as long as the hold has been removed.
I	Can’t Insert Decision Code This error is received when you are trying to create a student record and the system knows that one or more of the rules governing the creation of a student record would be broken in doing so. For example, if a student record already exists for the same term as the newly created QuickStart application, the insert of a new student record would fail, because you cannot insert a new student record if one already exists for the same term. However, all other items defined by the indicators in the Automated Processing Rules window of SAAWADF, as well as items defined by the SAAECRL rules, are still processed. So, the QuickStart applicant would not have a new student record created, but they could have an application record created, additional personal data updated on SPAPERS, test score data added, an application and recruit record created, and additional items.
P	Push Error This error rarely occurs. It is usually caused by invalid data or data that is not acceptable to the database because of indices. If a push error occurs, the part of the process receiving the error is not pushed. All other pieces are pushed. For example, if a question/answer receives a push error, the recruit, application, and student record is still created along with person data.
R	Match Error Perform the following steps: Use the Person Search or Create Person options in the Options list from the Applicant and Application Manual Verification window on SAAEAPS to mark the record with the match error as New or Matched. Mark any of the other manual verification steps as complete in the Manual Person Verification Steps block and save the changes. Return to the main block, where the Status Pers and Status App fields should both be set to Y. Now, you can either manually verify and push the application on SAAEAPS or run the SARETMT process to automatically re-verify and push the application.
V	Verification Error You can go to SAAEAPS to try and override the verification error if the correct override indicators were set on SAAECRL. Perform these steps: Select the Review Results option in the Options menu in the main window of SAAEAPS to access the Verification/Load Results window. Scroll through the procedures in the System Verification Procedures block until you find the procedure(s) where the Comp(lete Indicator) checkbox is blank. Click on the O/R (Override Indicator) checkbox for this procedure. If an override is allowed for this procedure, you can check the box and then save the change. Return to the main block of SAAEAPS. You can manually verify and push the application or run SARETMT to automatically re-verify and push the application.
U	Suspended Record Perform these steps: Select the Manual Verification Steps option in the Options menu in the main window of SAAEAPS to access the Applicant and Application Manual Verification window. Select the Step field that has a value of IDVR (ID verification). Select the Person Search option from the Options menu to access SOQMTCH. Query the production database on SOQMTCH to see if a match occurs. * If a match occurs, select the Match icon. This automatically matches the electronic application to the matching record in Banner. It also checks the IDVR step. * If a match does not occur, exit SOQMTCH. Select the Create Person option from the Options list in the Applicant and Application Manual Verification window. This takes you to the Create Person window, where you can indicate which type of ID to use when creating the person in Banner. After selecting the ID type, save your work and then click Return. The IDVR step is checked, and the Status Pers field is set to Y.

Banner form

Steps

Follow these steps to build QuickStart processing.

Access the Electronic Applicant Web Default Rules Form (SAAWADF).

Select the Web application you have been working with in the Web Application Type field.

Select a term the Term field.

Perform a Next Block function.

Select the Matching and Processing Rules tab.

Select an interface code in the Interface Code field to be used by QuickStart.

Select an application source in the Application Source field.

Perform a Next Block function.

Click the Enable QuickStart Processing checkbox.

Select an admission decision in the Admission Decision field.

Choose the QuickStart features you would like to use by checking the appropriate checkboxes.

Automatically Create Recruit Record - When checked, a recruit record is created for the Web applicant.

Automatically Create Application Record - When checked, an application record is created for the Web applicant.

Process Decision - When a decision code is selected, an admissions decision record is created on SARAPPD.

Automatically Create Student Record - When checked, a student record is created on SGBSTDN, as long as no matching record is found on SOAEQUI.

Provide Access to Student Self-Service - Once the applicant has a student record, she or he can now register for classes through Student Self-Service.

Create one application - When checked, only one recruiting and/or application record will be created, and all curricula entered will be associated with that one record.

Click the Save icon.

Select the Web Signature Letters tab.

Select a letter code in the Letter Code field.

Select a letter type in the Letter Type field.

Click the Save icon.

Click the Exit icon.

Populating the EDI Cross-Reference Rules Form

EDI Cross-Reference Rules

Although much of the setup on the EDI Cross-Reference Rules Form (SOAXREF) may not be required for your Web Admissions applications, your EDI admissions application processing still relies heavily on the use of SOAXREF.

Purpose of SOAXREF

SOAXREF is used mainly by Web Application processing to customize what values the applicant sees in the various drop-down menus available on the Web application. If an institution wants all values within a validation table to display in the Web menu, then no data from that validation table should be inserted into SOAXREF. For example, because most institutions want all state and province codes to display in the state menu, no state or province codes need be inserted into SOAXREF. If, however, an institution would like to customize what values from a validation table display in the Web menu, then they can either use the appropriate script to insert all values from the validation table and then check the Web Indicator checkbox for those values that should display, or they can manually insert only those values that should display on the Web (remembering to check the Web Indicator checkbox).

Other forms used

Data pertaining to which majors a Web applicant can select must be entered on SOAXREF as well as on SOACURR. The institution also can decide to default in a curriculum for a given application type. In that case, the major information comes from the Electronic Applicant Web Default Rules Form (SAAWADF). This form also uses the curricula defined on SOAXREF and SOAXCUR.

Web-enabled rows

Not all rows in SOAXREF are used in Web Admissions application processing. Many rows are used only to process incoming TS 189 transaction sets received through EDI. Other rows may be used only to process incoming AMCAS records for medical school applications. Regardless, only rows that are completely Web enabled are available for display in the Web Admissions application menus.

A Web-enabled row is one that

exists in SOAXREF

has an EDI Value, and perhaps, an EDI Qualifier (depending upon the type of data reflected in the rule)

has the Web Display Indicator check box checked (set to Y)

has a description

has a Banner value.

Some guidelines

In many cases, the only thing you need to do is ensure that all the values you want displayed on the Web exist on SOAXREF and that the description clearly represents the value you want the student to select. However, in some cases, you may need to build additional rules.

Example: The values delivered for the label STVDEGC (e.g., Degree Level - Degree Codes) are generic EDI Degree Levels (Associate, Baccalaureate, Master). Web-enabled values for this label are displayed when a transfer applicant is asked about the degree pursued or earned at a prior college, and you may want to collect information about specific degrees (e.g., Associate of Technology, Bachelor of Arts, Master of Sciences) and have values in the corresponding Banner validation table that reflect these specific degrees. In these cases, you need change the value to an existing value in the STVDEGC validation table for the Value field, and you should make sure that the value does not already exist for the label on another row. For these rules, you set the Standard checkbox to unchecked (set to N).

Banner form

Steps

Follow these steps to create and update the cross-reference rules.

Access the EDI Cross-Reference Rules Form (SOAXREF).

Select STVATYP Address Type Codes in Cross-reference Label field.

Perform a Next Block function to access the Cross-Reference Rules block.

Define the appropriate address types on SOAXREF using the label STVATYP.

Note: The Web-enabled rows must contain a Banner value.

Click the Save icon.

Perform a Rollback function.

Repeat the above steps for the following cross-reference labels.

Telephone Types	STVTELE

EDI Major	STVMAJR

State/Provinces	STVSTAT

Nation	STVNATN

Ethnicity	STVETHN

Note: These values must also be built in SOAXCUR.

Click the Save icon.

Steps

Follow these steps to define multiple major codes on SOAXREF.

Note: You will also use the Curriculum Rules Form (SOACURR) in this procedure.

Enter the label STVMAJR in the Cross-Reference Label field to create SORXREF values for multiple major codes that use the same CIP Code.

Query for the first CIP code that may have multiple values.

Enter the CIP code and query on it in the Electronic Value field.

Note: Review the values that exist, or add new values for the majors.

Enter 81 in the Electronic Qualifier field.

Note: 81 is the major code qualifier for CIP codes.

Enter a value that is different than any existing CIP code in the Electronic Value field.

Note: For the first major code you define in a set, you might use the actual CIP code.

Enter the major code for one of the majors represented by the CIP code in the Banner Value field.

Note: For every other major code that uses the same CIP code, create one line on SOAXREF. On each line, you need to enter a different EDI value in the Electronic Value field. For example, you might merely put a letter at the end of the CIP code. Specifically, Accounting (major code ACCT) might use an EDI value of 060201, and Fund Accounting (major code ACTF) might use an EDI value of 060201A.

Access the Curriculum Rules Form (SOACURR).

Review entries in the Curriculum Rules Form (SOACURR) to ensure that you have an entry for each major. If you do not, create the entry because cross-reference rules are dependent on curriculum rules.

Define the electronic curriculum cross-reference values for the newly created major codes on SOACURR.

Query for the first major code.

Note: Review the electronic cross-reference information in the line that displays. You may need to define cross-reference values.

Access the Majors and Departments tab.

Enter the appropriate degree level code in the EDI Degree field.

Click the Display on Self-Service checkbox.

Enter a Web display description in the Self-Service Description field which will display in the Planned Course of Study drop-down menu on the Web.

Click the Save icon.

Repeat these steps until you have appropriate cross-reference values defined for all major codes.

Review your updates by accessing the Planned Course of Study page for a Web Admissions application.

Result: The programs you have just defined should display.

Customizing Curriculum Rules and Defining EDI Cross- Reference Curriculum Rules

Introduction

In Banner, a student's academic program is defined by a combination of the data elements program, campus, college, level, degree, and major, and these data elements must be valid alone and in combination. When an applicant completes an application for admission, it is not likely that they would know all of the valid combinations of these elements.

Forms used

To make Web program choice selection clearer and easier, use the Curriculum Rules Form (SOACURR). In previous versions of Banner, you would have used the EDI Cross- Reference Curriculum Rules Form (SOAXCUR). When you access SOAXCUR for the first time in a Banner session, you will receive this message:

Before beginning Web Application processing, you need to update the curriculum cross-reference rules with appropriate EDI values. All EDI and Web display control items are located in one centralized location on SOACURR. SOAXCUR and SAAWCUR, which were previously used for updating self-service controls, are query-only forms.

Specifics

On the Curriculum Rules Form (SOACURR), you will update the EDI Degree and EDI Level fields. In addition, you need to update the Display on Self Service checkbox and Self Service Description field for all curricula that are available for Web selection.

If a specific curriculum rule is not allowed with QuickStart processing, then the Auto Student checkbox must be unchecked. This curriculum may stay displayed on the Web application, but a student record is not created using this curriculum.

Banner form

Steps

Follow these steps to customize curriculum rules.

Access the Curriculum Rules Form (SOACURR).

Double-click the Term field to select a term and click OK.

Perform a Next Block function.

Enter and execute a query to find the program.

Access the Majors and Departments tab.

Navigate to the EDI and Self-Service block.

Click the drop-down arrow above the EDI Degree field to select a valid value to edit.

Note: This field defines the generic level of the degree program for which the applicant is applying, e.g., 2.4 equals Bachelors degree.

Click the drop-down arrow above the EDI Level field to select a valid value to edit.

Note: This field defines the EDI qualifier for the code set used for Field of Study Codes, which will be entered in the next field, e.g., 81 equals CIP codes.

Click the drop-down arrow above the EDI Identification field to update to a valid value.

Note: This field defines the subject matter of the intended field of study.

Check the Display on Self Service checkbox for all rules for which applications can be received via Banner Self-Service Admissions application processing.

Enter a description in the Self-Service Description field provide a description for all rules representing curricula that is displayed in Web Admissions applications.

Note: The description maintained is exactly what displays on the Web and also represents the total information from which the student can select.

Example: If the curriculum rule represents a Bachelor of Arts degree with a major in English, which is only valid on the Main Campus, you would want the description to be BA—English (Main Campus only).

Click the Save icon.

Click the Exit icon.

Customizing curriculum rules by application type

The Web Application Customized Curriculum Form (SAAWCUR) allows institutions to select certain qualifying curricula to appear in the Plan drop-down menu for a particular application type.

When you enter the form with a valid application type in the Key block, the form returns all SORCMJR records whose level matches the level for the application type and that have non-null values in SORCMJR_DEGR_CODE, SORCMJR_EDI_QLFR, and SORCMJR_EDI_VALUE. Once all valid records are displayed, you can choose which ones should be available for this application type by checking the Restrict to Application checkbox. As with SOACURR, a record must have the Web Display checkbox selected and the Description complete for the record to display on the Web.

Once all appropriate rules for this application type have had the Restrict to Type checkbox checked, the user can re-enter the form with the application type and can check the Restricted checkbox in the Key block. On performing a Next Block function, the form shows only those curricula that have been restricted to this application type.

Banner form

Steps

Follow these steps to customize curriculum rules by application type.

Access the Web Application Customized Curriculum Form (SAAWCUR).

Double-click the Web Application Type field in the Key block to view the List of Values, and select an application type.

Click the Restricted checkbox.

Perform a Next Block function.

Result: Curriculum that has been restricted to this application type displays.

Select the records you want to be available for this application type by checking the Restrict to Type checkbox.

Note: A record must have the Web Display checkbox checked and the Description complete for the record to display on the Web.

Click the Save icon.

Click the Exit icon.

Steps

Follow these steps to review your work.

Access SAAWCUR.

Double-click the Web Application Type field to view the List of Values and select an application type.

Perform a Next Block function.

Review the application types.

Click the Exit icon.

Establishing Dates for the Creation and Receipt of Students’ Applications

Introduction

Define calendars for the application types that have different schedules on the Web Application Term Calendar Rules Form (SAAWATR). Once this form is used for an application type, it must always be used. This form allows the institution to define the dates when applications of each type can be created and subsequently viewed on the Web. This form works in conjunction with the Web Application Term Display Control Form (SOAATRM), where the calendar for all applications can be defined. If no rules exist on SAAWATR for an application type, then the rules defined on SOAATRM take effect.

Banner form

Steps

Follow these steps to define calendars for the application types that have different schedules.

Access the Web Application Term Calendar Rules Form (SAAWATR).

Select a value in the Web Application Type Code field.

Select a term in the Term field.

Navigate to the Application Entry block.

Select a term in the Term field.

Enter a date in the Start Date field for when applications of each type can be created.

Enter a date in the End Date field.

Navigate to the Application Display block.

Select a term in the Term field.

Enter a date in the Start Date field for when applications of each type can be viewed on the Web.

Enter a date in the End Date field when it can longer be viewed.

Click the Save icon.

Result: The Activity Date field defaults.

Click the Exit icon.

Introduction

Define the date ranges that you will receive applications for a term. The Web Application Term Display Control Form (SOAATRM) is used to specify these time periods.

Banner form

Steps

Follow these steps to define the date ranges that you will receive applications for a term.

Access the Web Application Term Display Control Form (SOAATRM).

Select a value in the Term field.

Enter a date in the Start Date field to define the date range that you will receive applications for a term.

Enter a date in the End Date field to define the date range that you will no longer receive applications for a term.

Click the Save icon.

Result: The Activity Date field defaults.

Click the Exit icon.

Introduction

Control the calendar of applications in the Banner production tables using the Web Admissions Term Calendar Rules Form (SAAWAAD). This calendar determines by term, level, campus, college, and admit type when an application can be viewed (regardless of its source), when the status can be viewed, and when the most recent decision can be viewed on the Web.

The Priority (code) field is used to create a unique key for each calendar rule. It may be necessary to have multiple records for one level and term that start and end on the same date to exclude specific admit types from displaying on the Web. The Priority (code) field can be used to make each record unique.

Banner form

Steps

Follow these steps to control the calendar of applications in the Banner production tables.

Access the Web Admissions Term Calendar Rules Form (SAAWAAD).

Select a term in the Term field.

Note: The Term field defaults from the previous form. If you would like to work with a different term, double-click the Term field and select the term you want.

Select a college in the College field.

Select a level in the Level field.

Select a campus in the Campus field.

Select an admission type in the Admission Type field.

Access the Term field

Note: in the next block; values default.

Enter a number to create a unique key for each calendar in the Priority field.

Enter the start date of when an application can be viewed in the State Date field.

Enter the end date of when an application can be viewed in the End Date field.

Click the View Application checkbox to allow applications to be viewed during the date range.

Click the Show Status checkbox to allow application status to be viewed during the date range.

Click the Show Decision checkbox to allow application decisions to be viewed during the date range.

Click the Save icon.

Click the Exit icon.

Updating or Defining the Procedures and Routines for Each Application Type

Introduction

Before loading data from the holding tables into the permanent Banner tables, you want to make sure that the information submitted by the applicant is as complete and correct as it possibly can be. Application procedures and routines perform much of this work.

When a web application is submitted, the data does not go directly into Banner permanent tables, but instead to temporary tables to be reviewed and then “PUSH” to the permanent Banner tables.

Procedures and routines

A procedure is a collection of routines. Routines check data at the data element level, and a number of routines may be included within a procedure. Procedures are closely related to each table into which data is loaded. All required routines must be satisfied before a procedure can be satisfied. A set of procedures and routines has been delivered and is attached to each of the delivered Application Types.

Banner form

Procedures and routines are attached to each Electronic Application Type using the Electronic Admissions Procedure/Routine Control Form (SAAECRL). This form also includes several flags that specify how each procedure and routine will be used in electronic application processing.

Required Flag and Override Flag checkboxes

Both the Procedures section of the main window and the Routines section of the Admissions Verification and Load Routines window include a Required Flag checkbox and an Override Flag checkbox.

The Required Flag checkbox is used to specify the procedures and routines that are attached to each electronic application when it is received. When a procedure or routine is attached to an application, it needs to be fulfilled before the application is considered verified and before the data is pushed to the permanent Banner tables. More specifically, each routine needs to be fulfilled before the overall procedure can be satisfied.

Procedures and routines

The procedures and routines control the types of data that is verified and eventually pushed into Banner. You can set procedures and routines to Not Required if you do not wish certain data to be verified or loaded into Banner.

Example: You might choose not to load Medical Conditions from electronic applications. You would set the Required Flag checkboxes for Procedure P060 (Health Conditions Verification) to unchecked (N), and also set the Required Flag for Routine R0080 (Create Medical Conditions) in Procedure P900 (PUSH Verification) to unchecked (N). This would tell the system not to verify Medical Conditions and not to push them into Banner.

The Override Flags associated with procedures and routines allow you to specify whether a routine or procedure can be overridden manually at the individual application level on SAAEAPS or automatically using the Elec Appl Verify/Load Process (SARETMT). If a Routine or Procedure is overrideable, it still is attached to an electronic application (based on the Required Flag), but can be overridden if desired.

Example: You may normally collect required visa types from international applicants but not all applicants may understand the visa type they require. You could require visa types from international applicants, but allow the push of visa information to be overridden if an applicant does not provide the correct information. In this case, you would check the Required Indicator checkboxes for Procedure P032 (International Information Verification) including all of its routines to checked (Y), but set the Override Indicator checkbox for Routine R0030 (Create International Record) in Procedure P900 (PUSH Verification) to checked (Y) so that you could override the push of this information.

Process

The Elec Appl Verify/Load Process (SARETMT) automatically overrides a procedure or routine that fails the verification process because of empty data, if that procedure or routine is marked as able to be overridden on SAAECRL and the AUTOOVERRIDE label for the group VCRL on SAAERUL is set to Y.

For Web Application Types delivered by Ellucian, all appropriate procedures and routines already have been attached to each application type. If you define additional application types, you need to attach the appropriate procedures and routines to each new application type. You can do so automatically by using the Copy Procedure icon in the Key Block of SAAECRL. The Copy Procedure icon allows you to copy all the procedures and routines defined for any existing application type to your new application type.

Steps

Follow these steps to attach procedures and routines to each Electronic Application Type .

Access the Electronic Admissions Procedure/Routine Control Form (SAAECRL).

Select the Web application you have been working with in the Web Application Type field.

Enter a value in the Procedure field.

Note: If there are no blank lines left, perform an Insert Record function.

Enter a description in the Description field.

Select the appropriate checkbox(es)—Required, Override, System Required.

Enter a number in the Number of Routines field.

Click the Save icon.

Set the cursor on your first procedure.

Select Routines from the Option menu.

Enter a value in the Routine field.

Enter a description in the Description field.

Click the appropriate checkboxes(es)- Required, Override, System Required.

Click the Save icon.

Perform a Next Block function to return to the Electronic Admissions Procedure/Routine Control Form (SAAECRL).

Repeat steps 9 through 15 for all Procedures created

Click the Exit icon.

Reviewing and Updating Rule Values

Introduction

The Electronic Admissions Application Rules Form (SAAERUL) includes a number of rules that control how data is handled. All rules that are used by system processing have been delivered by Ellucian and should have been installed during the upgrade process.

How rules are categorized

For convenience purposes, rules are categorized into groups found in the EDI Rules Group Validation form, STVEGRP. Rule groups are used to display rules with a similar purpose together, and group codes can be used to specify that you want to display only a single group of rules at one time.

How the Value for Rules are updated

A label and a description also identify each rule. The script that installed the rule groups and rules also installed either the specific value expected for a rule or the literal UPDATE ME in the Value field. When an actual value was delivered, its EDI Standard Indicator checkbox was checked (set to Y) indicating that the rule expects an EDI value, and the value for these rules should not be changed. When the literal UPDATE ME was delivered, the value must be updated to reflect the local option for EDI application processing to be used.

When reviewing and updating rules…

When reviewing and updating rules, you may want to query on the Value field for the value UPDATE ME. After updating the appropriate rows, you may want to review all rules so that you better understand how data will be processed.

Banner form

Steps

Follow these steps to review and update the application rules.

Access the Electronic Admissions Application Rules Form (SAAERUL).

Enter ADMS in the Group field.

Perform a Next Block function to populate the form.

Update the value in the Value field if the Value field contains UPDATE ME.

Note: The value must be updated to reflect the local option for Self-Service or EDI application processing to be used.

Click the Save icon.

Perform a Rollback function.

Repeat step 2-6 for all rules connected to groups pertaining to the Self-Service application, which depending on your application, can include the following: ADDR, ADMS, ATYP, CHKL, CURR, ENTY, DISP, FLVL, LGCY, PCOL, PQLF, QSTN, RESD, RLTN, TELE, VCRL.

Click the Exit icon.

Set up Accept Admissions Offer on the Web

Introduction

Your institution can set up the ability for an admissions applicant to view an offer of admission (with conditions if appropriate) and then accept, reject, or withdraw the application through Banner Student Self-Service. Once the student has made a decision in self-service to accept the offer of admission, that decision data is also updated on the Decision Data block of the Admissions Decision Form (SAADCRV). If the student rejects the offer and withdraws the application in self-service, the withdrawal data is updated in the Withdrawal Data block on the Admissions Application (SAAADMS).

Banner form

Steps

Follow these steps to set up the accept admissions offer functionality in Student Self-Service.

Access the Electronic Admissions Applications Rules Form (SAAERUL).

Enter DCSN in the Group field in the Key Block, then click on the Next Block icon.

Enter Y in the Value field for the ALLOWDECISION rule.

Note: This must be done to allow applicants to use the web for their decisions. You can make more refinements, as explained in the following steps, but if the ALLOWDECISION rule is not set to Y, the Confirm Attendance and Withdraw Application buttons will not be displayed on the Application Summary page regardless of the other details you put in place.

Observe Update Me in the Value field for the CONFIRMCODE rule. Replace Update Me with the value from the Admission Application Decision Code Validation Form (STVAPDC) which should be used for the confirm decision code.

Observe Update Me in the Value field for the CONFIRMLABEL rule. Replace Update Me with any value that should be used for the Applicant Confirm label.

Observe Update Me in the Value field for the WITHDRAWLABEL rule. Replace Update Me with any value that should be used for the Applicant Withdraw label.

Observe Update Me in the Value field for the WITHDRAWCODE rule. Replace Update Me with the value from the Admission Application Decision Code Validation Form (STVAPDC) which should be used for the withdraw decision code.

Observe Update Me in the Value field for the CAPTUREWDINFO rule. Replace Update Me with Y or N to indicate whether to request additional information from the applicant when withdrawing an application.

If you do not wish to allow the Withdraw Application button to be displayed on the Application Summary page under any circumstances then enter N in the Value field for the ALLOWWITHDRAW rule and skip to step 31.

If you wish to allow the Withdraw Application button to be displayed on the Application Summary page based on the applicant’s student level, create a new rule on the Electronic Admissions Applications Rules Form (SAAERUL) in the DCSN group by highlighting the first blank line and clicking the Insert Record icon, otherwise skip to step 16.

Enter the rule’s name in the Rule Label field, appending a valid student level code (from the Level Code Validation Form [STVLEVL]) to the rule label.

Enter the rule description in the Rule Description field.

Enter Y in the Value field.

Click the Save icon.

For each level for which you want to allow Withdraw Application button to be displayed on the Application Summary page, repeat steps 10 through 14. When you have finished setting rules for each level, continue to the next step.

If you do not wish to allow withdrawing applicants to provide more information about their decisions via the web skip to step 31.

Enter Y in the Value field for the CAPTUREWDINFO rule.

Note: If you set this rule to Y, when a user selects the Withdraw Application on the Application Summary page, the system will display the Applicant Withdrawal Information page.

Click the Save icon.

Click the Exit icon.

Access the Admission Application Decision Code Validation Form (STVAPDC)

Select the Display on Web checkbox for each decision code that you wish to be available on the web.

Click the Save icon.

Click the Exit icon.

Access the Withdrawal Reason Code Validation Form (STVWRSN).

Review the existing codes. If you do not wish to add any new codes, skip to step 31.

Highlight the first blank line, and click the Insert Record icon.

Enter the withdrawal reason code in the Code field.

Enter the withdrawal reason description in the Description field.

Observe the Activity Date field. This will be blank until you have saved this form, then it will reflect the date this record was most recently updated.

Repeat steps 26 through 30 until you have entered all of the new withdrawal reason codes.

Click the Save icon.

Click the Exit icon.

Self Check

Directions

Use the information you have learned in this workbook to complete this self-check activity.

Question 1

You cannot edit the Signature page that is delivered with Banner.

True or False

Question 2

Which form do you use to define credit card processing rules?

Question 3

What does UPDATE ME in the Value field of the Electronic Admissions Application Rules Form (SAAERUL) mean?

Answer Key for Self Check

Directions

Use the information you have learned in this workbook to complete this self-check activity.

Question 1

You cannot edit the Signature page that is delivered with Banner.

False. You can customize the Signature page by application type using the Electronic Applicant Web Default Rules Form (SAAWADF).

Question 2

Which form do you use to define credit card processing rules?

The Email and Credit Card Rules tab on the Electronic Applicant Web Default Rules Form (SAAWADF).

Question 3

What does UPDATE ME in the Value field of the Electronic Admissions Application Rules Form (SAAERUL) mean?

If any of the Value fields contain UPDATE ME, the value must be updated to reflect the local option for Self-Service or EDI application processing to be used.

Day-to-Day Operations

Section Goal

The purpose of this section is to explain the day-to-day or operational procedures to review web submitted applications, resolve discrepancies, and move application data into permanent Banner tables.

Objectives

In this section you will learn how to

review submitted electronic applications

reconcile “suspended” applications

run verification steps for electronic applications

override verification steps not satisfied

“PUSH” verified applications into permanent Banner tables.

Process Introduction

About the process

This process outlines steps Admissions personnel would need to take on a day to day basis to review electronically submitted applications and move them into Banner forms.

Flow diagram

This diagram highlights the processes used in Self-Service Admissions.

What happens

The stages of the process are described in this table.

Stage	Description
1	Electronic application is submitted.
2	Matching process is run.
3	Suspended applications are reconciled.
4	Verification procedures are run.
5	If necessary verification procedures not completed are overridden.
6	Application data is “PUSH”ed to Banner forms.

Displaying Received Web Applications

Overview

To display the application(s) for a specific person, enter the electronic ID for that person in the Key block of the Electronic Application Process Form (SAAEAPS), or use a List function to display the Electronic Applicant Search Form (SOAEIDN), where you can search for an electronic applicant using name and ID. You also can select only those applications added on a certain date by entering the date in the Add Date field in the Key block. Only applications matching the Web ID field or Add Date field in the Key block display.

You can enter the main block and query on certain fields. Those fields are: Application Preference, Application Number, Application Type, Person Status and Application Status, Term, Source (with a value of Web), Add Date, Completion Indicator, Accepted Indicator, Process, and Process Date.

If you find applications that you believe are frivolous, they can be deleted using the Record Remove function. Once an application is deleted on SAAEAPS, its associated data is deleted from the electronic application holding tables; therefore, the application is no longer viewable on the Electronic Application Submitted Form (SAAETBL).

Banner form

The Electronic Application Process Form (SAAEAPS)

Steps

Follow these steps to display received web applications.

Access the Electronic Application Process Form (SAAEAPS) to display received Web applications.

Select the electronic ID for an applicant in the Web ID field or use a List function to display the Electronic Applicant Search Form (SOAEIDN) where you can search for an electronic applicant using name and ID to display the application for a specific person.

Note: You also can select only those applications added on a certain date by entering the date in the Add Date field in the Key block. Only applications matching the Web ID field or Add Date field in the Key block display.

Perform a Next Block function—values for applicant self populate.

Review the information.

Click the Exit icon.

Matching, Verifying, and Loading the Web Applications

Introduction

Use the Elec Appl Verify/Load Process (SARETMT) to match, verify, and load the Web applications that meet your processing guidelines.

Parameters for SARETMT allow processing based on Application Type, Application Source, Application Term, and the Date Range of when applications were added.

SARETMT can be run in audit mode providing the user with the opportunity to review the match, verify, and load status of each application before it is actually processed. The Status field indicates whether the Web application is New, Matched, Suspended, or in Error based on the matching rules specified by the interface code on GORCMRL. If a Web application type has previously been pushed for a given Web ID, the Status field indicates N/A, as a matching PIDM already existed for the Web ID. The process indicates if verification errors occurred or if the application was pushed.

The user can run the match, verify, and load process in update mode. All electronic applications matching the input parameters are processed by SARETMT.

Possible outcomes

Three possible outcomes can exist for each record processed by SARETMT.

The record was matched, verified, and pushed successfully resulting in the creation of a SAAADMS application record.

The record was placed into suspense or error status during the match process. Suspended records are not processed further by SARETMT until the match status has been resolved to either New or Matched. The user can resolve the suspended status using the Electronic Application Process Form (SAAEAPS). Records with a status equal to E will not load automatically as a required field indicated on the GORCMRL matching rules was empty on the Web application. These records also can be resolved to Match or New using SAAEAPS.

The record failed the verification process. Numerous verification routines exist to ensure the integrity of the data being loaded into Banner. If certain errors occur during the verification process, the record is marked with a verification error.

Banner form

Steps

Follow these steps to match, verify and load web applications.

Access the Elec Appl Verify/Load Process (SARETMT).

Enter the desired printer name in the Printer field.

Note: You can enter DATABASE to write the report to a table for on-line viewing and to enable the saving of the report to a shared folder on a designated network drive.

Enter these parameter values.

Parameter	Value
Interface Code w/match rules	Click on the Values icon to view the List of Values. Select a code.
Application Source	Click on the Values icon to view the List of Values. Select a source.
Application Type	Click on the Values icon to view the List of Values. Select a type.
Start Date Range	Enter a date in DD/MON/YYYY format.
End Date Range	Enter a date in DD/MON/YYYY format.
Term Code	Click on the Values icon to view the List of Values. Select a code.
Override App. Status Ind.	Enter Y for yes or N for no.
Override App. Accept Ind.	Enter Y for yes or N for no.
Use Gen. ID, SSN or Web ID	Enter one of the following: G—Generated ID S—SSN ID E—Web ID
Print Detail/Summary or Errors	Enter one of the following: P—Print S—Summary E—Errors
Audit or Update	Enter A for audit or U for update.
Create Recruit Records Y or N	Enter Y for yes or N for no.
Source code for Recruit Record	Enter the source (SBGI) code to be used for Recruit records (optional).

Click the Save Parameter Set as checkbox.

Enter a name and description in the Name and Description fields.

Click the Submit radio button.

Click the Save icon to run the process.

Resolving Suspended Electronic Applications

Introduction

Resolve suspended electronic applications using the Electronic Application Process Form (SAAEAPS). If, after running SARETMT, the match status is set to suspended, the user accesses SAAEAPS to resolve the suspended record. This means that the institution decides if this person is new to Banner or if they match an existing Banner person.

Banner form

Steps

Follow these steps to resolve suspended electronic applications.

Access the Electronic Application Process Form (SAAEAPS).

Click the Web ID search icon to display the Electronic Applicant Search Form (SOAEIDN).

Enter N in the Record Type field.

Note: These are the records that need to be resolved before they can be verified and pushed into Banner.

Perform an Execute Query function.

Double-click on the desired Web ID to return to the Electronic Application Process Form (SAAEAPS).

Perform a Next Block function.

Select the Verification Steps tab.

Select IDVR (ID verification) in the Step field in the Manual Person Verification Steps block.

Select Associate Person with ID from the Options menu.

Click the Associate Person with an ID button.

Result: You are taken to the Common Matching Entry Form (GOAMTCH).

Enter a matching source in the Matching Source field, if necessary.

Enter data about the person in the Data Entry block and click the Duplicate Check button.

IF match is…	THEN…
found	click the Select ID button.
not found	create as new and save.

Access the Verification Steps block of SAAEAPS.

Result: The Completion Indicator checkbox and Completion Date field associated with the IDVR step is set.

Click the Electronic Applications tab.

Notes: The Person Status checkbox will be set to Y.

This record can now be reprocessed by SARETMT.

Resolving Verification Errors

Introduction

Resolve verification errors using the Electronic Application Process Form (SAAEAPS). If the AUTOOVERRIDE label on the Electronic Admissions Application Rules Form (SAAERUL) for which the group VCRL is set to Y, and the procedures and routines are marked as overrideable on SAAECRL, then SARETMT will not stop the process if verification errors occur (unless they are data errors).

If the AUTOOVERRIDE label is set to N, then any verification errors found while SARETMT is processing are identified, and the process halts. These errors can be viewed on SAAEAPS and must be resolved before the affected applications can be reprocessed by SARETMT. Verification errors can only be resolved on SAAEAPS if the routine or procedure causing the error has the Override checkbox checked on SAAECRL for the appropriate application type.

Banner form

Steps

Follow these steps to resolve verification errors.

Access the Electronic Application Process Form (SAAEAPS).

Perform a Next Block function to navigate to the main block.

Query for the appropriate records (e.g., term, source) having a Process value of E.

Note: These are the records that need their verification errors resolved before they can be pushed into Banner.

Select Review Results from the Options menu or access the Review Results tab.

Result: In the System Verification Procedure block, each procedure is displayed, one procedure at a time. At the same time, each routine associated with a procedure is displayed in the System Verification Routines block.

Scroll through each procedure to find the procedures that have not been verified (i.e., the Complete checkbox is not checked).

Click the appropriate Override Indicator checkbox to resolve a procedure or routine.

Note: If you override an individual routine, only the verification associated with that routine is bypassed. If an entire procedure is overridden, none of the individual routines will have verification performed.

Return to the main block of SAAEAPS once all routines or procedures are overridden.

Note: You can manually re-verify the application here by selecting Verify Application from the Options menu, or you can re-run SARETMT.

Click the Exit icon.

Re-Running SARETMT in Update Mode

Introduction

Electronic Application Verify/Load Process (SARETMT) will try to verify all records that were previously suspended and will attempt to re-verify all applications that originally failed verification. All applications that pass the match and verification processing are pushed to Banner. Once an application has been pushed, the Process Indicator check box will be set to P(ushed).

Banner form

Steps

Follow these steps to complete the report on the Electronic Application Verify/Load Process.

Access the Elec Appl Verify/Load Process (SARETMT).

Enter the desired printer name in the Printer field.

Note: You can enter DATABASE to write the report to a table for on-line viewing and to enable the saving of the report to a shared folder on a designated network drive.

Enter these parameter values.

Parameter	Value
Interface Code w/match rules	Click on the Values icon to view the List of Values. Select a code.
Application Source	Click on the Values icon to view the List of Values. Select a source.

Perform a Next Block function.

Click the Save icon.

Click the Exit icon.

Summary

Let’s review

As a result of completing this workbook, you have

reviewed and created validation forms that control Admissions Self-Service

created a Self-Service application

defined rules for electronic verification

reviewed submitted electronic applications

executed all verification steps

reconciled suspended applications and verification steps not completed

“PUSH”ed electronic applications to Banner forms.

Now you are ready to begin determining the information related to your Admissions Office which will be implemented within the Admissions Self-Service product module. Decisions will need to be made based upon your organization’s needs as to which code validation forms and control and rules forms will be used as well as what your values will be on these forms.

Self Check

Directions

Use the information you have learned in this workbook to complete this self-check activity.

Question 1

Applications that do not appear to have enough valid information can be deleted.

True or False

Question 2

It is possible to view applications entered on a certain date by querying the ‘Add Date’ field.

True or False

Question 3

If the status field displays ‘N/A’, then the application did not “push” properly.

True or False

Question 4

Records with a status of ‘E’ require specific data to be present during the match process as defined in the rules on GORCMRL.

True or False

Question 5

If after running the match process and a record is set to S, the record must be deleted as it will not process correctly.

True or False

Question 6

It is possible to the system stop the SARETMT process if verification errors occur.

True or False

Question 7

Once overrides have been verified, the applications can be processed either manually or by re-running SARETMT.

True or False

Question 8

Once all applications have been verified and “pushed” this creates a SAAADMS record in Banner.

True or False

Question 9

Clients who are implementing Self-Service Admissions can create group codes on the SAAERUL form

True or False

Question 10

Institutions can create customized applications allowing specific application types to be associated with specific curriculum programs.

True or False

Question 11

It is not always necessary to associate name, address, and plan of study to application types on the SAAWAPP form.

True or False

Question 12

Applications entered in native Banner via the SAAQUIK or SAAADMS forms can be viewed via the Self-Service Admissions Product on the web.

True or False

Answer Key for Self Check

Question 1

Applications that do not appear to have enough valid information can be deleted.

True

Question 2

It is possible to view applications entered on a certain date by querying the ‘Add Date’ field.

True

Question 3

If the status field displays ‘N/A’, then the application did not “push” properly.

False. ‘N/A’ indicates that the record matched on a previous “push” process with an existing PIDM within Banner.

Question 4

Records with a status of ‘E’ require specific data to be present during the match process as defined in the rules on GORCMRL.

True

Question 5

If after running the match process and a record is set to ‘S’, the record must be deleted as it will not process correctly.

False. The ‘S’ indicates that the record has been suspended and the match status must be resolved to either a New record or a Matched record.

Question 6

It is possible to the system stop the SARETMT process if verification errors occur.

True

Question 7

Once overrides have been verified, the applications can be processed either manually or by re-running SARETMT.

True

Question 8

Once all applications have been verified and “pushed” this creates a SAAADMS record in Banner.

True

Question 9

Clients who are implementing Self-Service Admissions can create group codes on the SAAERUL form

False. Group codes on SAAERUL are delivered by Ellucian and cannot be generated by clients.

Question 10

Institutions can create customized applications allowing specific application types to be associated with specific curriculum programs.

True

Question 11

It is not always necessary to associate name, address, and plan of study to application types on the SAAWAPP form.

False. When creating application types on SAAWAPP, name, address, and plan of study must be tied to application types.

Question 12

Applications entered in native Banner via the SAAQUIK or SAAADMS forms can be viewed via the Self-Service Admissions Product on the web.

False. Only applications created through the Self-Service Admissions product can be viewed on the web.

Appendix

Forms Job Aid

Form	Full Name	Use this Form to...
GTVLETR	Letter Code Validation	create and maintain letter codes
SAAECRL	Electronic Admissions Procedure/Routine Control	attach procedures and routines to each Electronic Application Type
SAAERUL	Electronic Admissions Application Rules	create and maintain the electronic admissions rules
SAAWAAD	Admissions Web Calendar Rules	determine by term, level, campus, college, and admit type when an application can be viewed (regardless of its source), when the status can be viewed, and when the most recent decision can be viewed on the Web
SAAWADF	Electronic Web Applicant Default Rules	customize the application signature page
SAAWADP	Web Application Customized List	define codes, by application type, that should display in the Web menus for test codes, requested materials, interests, and credit card waiver reasons
SAAWAPP	Web Application Section Rules	the sections and elements that make up each application type
SAAWATR	Electronic Applicant Web Calendar Rules	define calendars for the application types that have different schedules
SAAWCUR	Web Application Customized Curriculum	select certain qualifying curricula to appear in the Plan drop-down menu for a particular application type
SAAWUDQ	Web User Defined Questions	define institution-specific questions that request information not found elsewhere in any application section
SOAATRM	Web Application Term Display Control	define the date ranges that you will receive applications for a term
SOACURR	Curriculum Rules	create and maintain the curriculum rules
SOAELTL	HTML Letter Rules	create and maintain HTML letter rules
SOAELTR	Format HTML Letter Rules	construct letter contents
SOAEQUI	Existing or Incoming Student Data Mapping	compare web application data with the existing student data in the system
SOAXREF	EDI Cross Reference Rules	customize what values the applicant sees in the various drop-down menus available on the Web application
STVADMR	Admission Request Checklist Code Validation	set up the applicant’s outstanding checklist items for display
STVAPDC	Admissions Application Decision Code Validation	web-enable the application decisions code(s)
STVAPST	Admissions Application Status Code Validation	create and maintain application status codes for web display
STVWAPP	Application Type Code Validation	identify application codes and define the level, student type, and admission types associated with the code
STVWSCF	Web Application Elements	link an element code to a web section code
STVWSCT	Electronic Application Section Code Validation	define the procedure for each section code

Terminology

Push

The process of moving data from temporary tables into permanent tables.

Matching

The process of comparing data from two separate sources and/or files to prevent duplicate records.

WebTailor

An option in the Banner Self-Service Web application that allows you to customize how web pages are displayed on your institution’s Self-Service website.