Using AR Sole Receivables

(1)

Using AR Sole Receivables

Georgia Enhanced Banner Student and

Financial Aid Systems User Documentation

Version 7.1.1.1

(2)

(3)

Using AR Sole Receivables Office of Information

Georgia Enhancements 7.1.1.1 and Instructional Technology

Using AR Sole Receivables

Introduction to AR Sole Receivables

Purpose of AR Sole

Receivables The Georgia Banner Enhanced Student and Financial Aid AR Sole _{Receivables Project provides functionality to process all accounts} receivable records in one subsidiary ledger, Banner.

The Georgia Enhanced AR Sole Receivables Process includes both Banner baseline and Georgia requirement information.

Target Audience _{Accounting and Business Officers} Purpose and Scope

of Document This document explains how to use the Georgia Enhanced AR Sole _{Receivables process to meet the requirements specified by the State} Department of Audits.

This chapter includes the following topics: • Introduction to AR Sole Receivables

• AR Sole Receivables Forms and Processes Reference • AR Sole Receivables Process Flow

• Detail Code Maintenance • Setting up Codes and Rules • Fee Assessment

• Setting Up Codes and Rules • Assigning Attributes

• Student Health Insurance • Setting Up Codes and Rules • Creating a Submission File • Loading Exemption Records • Direct Deposit Subscription

• Setting Up Codes and Rules

• Creating a Direct Deposit Subscription

(6)

• Direct Debit

• Setting up Codes and Rules

• Creating Direct Debit Subscriptions • Creating an ACH File

• End of Day Processing • Baseline Processing

• Account Aging and Reporting • Non-Banner Finance Interface

• Purging the GURFEED Temporary Table • Resetting a Feed

• End of Day Processing Check List

Graphics _{Graphic cues used in this document assist with labeling of steps and} items that are particularly important.

Steps for recovery or support.

For additional information, see references.

Exercise caution.

Warning: an error here is critical.

References _{For information about the baseline product, see Using SCT Banner User}

Manual for Accounts Receivable.

Support _{For additional OIIT resources and support, contact the OIIT HelpDesk:} Web http://www.usg.edu/customer_services

(self-service ticket submission)

E-mail [email protected]

For urgent or production down situations, call the OIIT HelpDesk:

Local 706-583-2001

Toll free within Georgia

1-888-875-3697

(7)

AR Sole Receivables Forms and Processes Reference

Overview _{Use the following forms:}

Descriptive Title Name

Detail Code Control Form ZSADETC

Chartfield Validation and Inquiry Form ZSICHFD Miscellaneous Transactions Form ZSAMISC Detail Code Accounting Mass Data Entry

Form

ZSRMASS

Process Definition Form ZTVPROC

E-Mail Status Definition Form ZTVSTAT

E-Mail Rules Form ZUREMRU

E-Mail Text Rules Form ZURMAIL

E-Mail Hierarchy Definition Form ZUREHIR E-Mail Process/Letter/Status Control Form ZUREPLS

Direct Deposit Rules Form ZSRDDRU

Direct Deposit Subscription Form ZSADDSD E-Mail Additional Information Form ZURAEML

Direct Debit Rules Form ZGRDEBT

Work Area Validation Form ZTVWKAR

Direct Debit Subscription Form ZGADEBS Direct Debit Worksheet Transaction Form ZGADDWS

Use the following processes:

Bank Routing Number Load ZGRDIRD

PeopleSoft HRMS Receivables Load Process

ZGRARLD

Customer Conversion Load Process ZORPDCL

(8)

Student Health Insurance Exemption Load ZSRHIEL

Aging Report ZGRAGES

Use the following script:

(9)

Detail Code Maintenance Process Flow

Description of Detail Code Maintenance

The Banner Accounts Receivable module requires the use of detail codes for processing transactions for student and non-student receivables. There are occasions when detail code maintenance is required due to changes in chart field strings.

The Detail Code Maintenance flow includes the following major steps: • Establish Detail Codes

• Mass Detail Code Updates • Chart Field Validation • Report Working Area Data

Timeframe _{Detail Code maintenance is required when changes occur to the} PeopleSoft chart field strings or new detail codes are needed for processing.

Warnings _{To prevent potential erroneous data and accounting feeds, users are} strongly encouraged not to delete detail code information or to change the Type from a charge to a payment or vice versa.

Detail Code Maintenance Process Flow Overview

Complete the following steps to set up and maintain detail codes within the Banner Accounts Receivable module.

I. Setting Up Codes and Rules

1. Establish detail codes ZSADETC

2. Make multiple chart field string adjustments

ZSRMASS

3. Validate chart field strings ZSICHFD

↓

II. Review Working Area Data

(10)

Detail Code Maintenance

I. Setting Up Codes and Rules

Introduction to

Setup Detail codes are required for processing in Banner Accounts Receivable. _{Users establish detail codes in the Georgia Detail Code Control Form} (ZSADETC). Each detail code is defined as a charge or payment,

assigned to a user-defined category and application of payment information.

The Detail Code Accounting Mass Data Entry Form (ZSRMASS) is used to make chart field string changes to multiple detail codes.

Records can be updated, added, or deleted from the working area of the form either individually or in groups.

Chart field strings are validated against the PeopleSoft COA Combo table within PeopleSoft. Validation occurs in real time when accounting information is entered into the ZSADETC, ZSRMASS and ZSAMISC forms. Query access is available in the Chartfield Validation and Inquiry Form (ZSICHFD).

1. Create Detail Codes (ZSADETC)

Create detail codes to be used for processing transactions in Accounts Receivable in the Georgia Detail Code Control Form (ZSADETC).

Each detail code is established with accounting entries in the GL

Interface Window. Chart field strings are validated against the PS COA Combo Table within PeopleSoft Financials at the time of entry.

Account string entries are effective dated and the Percent must equal 100.

(11)

2. Make multiple chart field adjustments

The Detail Code Accounting Mass Data Entry Form (ZSRMASS) is used to make adjustments to multiple chart field strings for a given population of detail codes.

The Working Area is a temporary holding area to work with data until adjustments are ready to be posted to the accounting tables. The information can be saved and retrieved later. Records are updated, added, and deleted from the working area either individually or in groups. Records may also be copied from one working area to another. Users are provided with counts of the total number of records, erroneous records, and warnings in the working area.

• Summary: The total number of records in the working area. • Errors: The total number of errors in the working area that will

require correction. Errors will occur when the following conditions are met:

o Percentages are not equal to 100%. o Account string is invalid.

o Detail code is not term based and any TBDS codes are populated.

(12)

red box shows how many erroneous records there are in the working area. The number displayed in the orange box shows how many records with warnings there are in the working area.

The Current TBRACCT Record View window allows the user to select a population of records for adjustments. Users may select the

population based on the detail category code, the percent, the term-based designator code, and/or the chart field string for Account A and/or Account B.

Records selected in the population may be copied to the Working Area by selecting the Copy to Working Area button.

(13)

The user receives a confirmation window with the number of records to be copied. Selecting the OK button in this window will copy the records into the working area.

When the records are successfully copied, a window will display the number of records copied to the working area.

After clicking the OK button in the window, the user should select the Working Area Detail Code Information from the options menu. Enter the Working Area Name or select the working area from the list of values by double clicking in the working area field. A next block function will display the copied records in the working area.

Warnings _{When records are written to a working area, the user may query the}

working area for specific information. This will cause the Summary, Error, and Warning data to be reported in the form inaccurately. The data displayed for these three fields are based on all data found in the

(14)

description of the chart field, the active indicator, and the effective date. This form is display only and will not allow for manual updates.

Validation is real time.

All fields allow query access to select valid values for each chart field.

The Select Combo String button allows for query access to the complete chart field string.

(15)

II. Review Working Area Data

Introduction to reporting on working area data

The Working Area Summary Report (ZSRMSUM) provides the user with the ability to print data related to a specific working area for review. The user may print all records, error records only, or warning records only related to a working area.

1. Execute

ZSRMSUM The ZSRMSUM process reports on all records, error records only, or _{warning records found within a specific working area.}

The parameters displayed in the Job Submission Form (GJAPCTL) are as follows. The parameter number, name, requirement, and description are provided to assist you when entering the parameter values.

Parameters for ZSRMSUM

No Name Required? Description/Instructions

Default Values

(16)

Sample zsrmsum.log

(17)

Fee Assessment Process Flow

Description of Fee

Assessment The Banner Accounts Receivable module requires fee assessment rules _{for charges to be placed on student accounts during the registration} process. Fee assessment occurs each term.

The Fee Assessment flow includes the following major steps: • Set up codes and rules

• Assign attributes

Timeframe _{Fee Assessment is required when registration occurs on a student} account and charges are assessed.

Fee Assessment Process Flow Overview

1. Create attribute codes STVATTS

2. Build crosswalk validation rules GTVSDAX 3. Set reverse non-tui/fee indicator SOATERM 4. Build fee assessment rules SFARGFE

↓

II. Assigning Attributes

(18)

Fee Assessment

Introduction to

Setup Fee assessment will be used to address the Guaranteed Tuition Plan and _{Student Health Insurance.} The Student Attribute Validation Form (STVATTS) will be used to define specific attribute codes for each. These attribute codes will be associated with the student’s account.

The Crosswalk Validation Form (GTVSDAX) will be used to build a rule to allow the user to refund charges with a detail category code other than TUI/FEE only.

The Term Control Form (SOATERM) will be used to set the Reverse Non Tuition/Fee Charges indicator.

Fee assessment rules will be built in the Registration Fee Assessment Rules Form (SFARGFE) using the created attribute code to assess charges to each student account that has the attribute code assigned.

1. Create attribute

codes (STVATTS) Create attribute codes to be used for processing the Guaranteed Tuition _{Plan and Student Health Insurance in the Student Attribute Validation} Form (STVATTS).

2. Build crosswalk

validation rules Create the crosswalk validation rules in the Crosswalk Validation Form _{(GTVSDAX). The rule will allow non tuition/fee charges to be} reversed.

The External Code set to ‘Y’ will allow charges with a category code other than TUI and FEE to be reversed from accounts. This rule will be required for those institutions that set up the insurance detail code with a

(19)

specific detail category code.

3. Set Reverse Non Tuition/Fee

Indicator

Set the Reverse Non-Tuition/Fee Charges indicator in the Term Control Form. This indicator will allow, in conjunction with the GTVSDAX rule, charges with a category code other than TUI and FEE to be reversed from accounts.

(20)

Note: The rules below indicate fee assessment for the Guaranteed Tuition Plan.

II. Assigning Attribute Codes

Introduction to assigning attribute codes

The Student Attribute Assignment Process (ZGRATTR) provides the user with the ability to assign a specific attribute to student accounts based on a user defined population selection.

1. Execute ZGRATTR

The ZGRATTR process creates a student attribute record in the General Student Additional Information Form (SGASADD). A term code is assigned to the record based on the term entered in the parameters of the process. The process will maintain previously assigned attributes. When a student is removed from the population selection, the attribute will be deleted from the record. A report of the records created is provided as part of the .lis file.

Parameters for ZGRATTR

01 Run Mode Yes Enter ‘A’ to view records to be updated. Enter ‘U’ to assign attribute codes

A

02 Attribute Code Yes Enter the attribute code to be assigned.

03 Term Code Yes Enter the term you wish to assign to the attribute record. 04 Application

Code

Yes Enter the application for the population selection to be processed.

05 Selection ID Yes Enter the selection ID for the population selection to be processed.

(21)

06 User ID Yes Enter the user ID associated with the population selection. 07 Creator ID Yes Enter the creator ID for the population selection.

Sample Files Samples of the zgrattr.log and zgrattr.lis files follow.

Sample zgrattr.log

(22)

Student Health Insurance Process Flow

Description of Student Health Insurance

The Student Health Insurance provides the user with the ability to create an extract file for submission to Pearce & Pearce, the USG approved health insurance provider, of participants in the mandatory health insurance plan. Users are also provided the ability to load

waiver/exemption data into the Exemptions Form (TSAEXPT) for the purposes of waiving charges for participants that provide documentation of approved insurance plans other than Pearce & Pearce. Students are charged the approved rate based on assigned attributes and fee

assessment rules described in the Fee Assessment section of this document.

The Fee Assessment flow includes the following major steps: • Set Up Rules and Codes

• Create submission file • Load waiver/exemption data

Timeframe _{Files are submitted to Pearce & Pearce throughout the term, specifically} when changes occur. The waiver/exemption file is received when other insurance providers are approved by Pearce & Pearce.

Student Health Insurance Process Flow Overview

I. Set Up Rules and Codes

1. Create detail codes ZSADETC

2. _Create exemption codes TSAEXPT

↓

II. Create submission file

5. Create submission file ZSRSHIR

↓

III. Load exemption data

(23)

Student Health Insurance

Introduction to

Setup Student Health Insurance requires codes and rules to process _{exemptions/waivers when a file is received from Pearce & Pearce.}

1. Create detail

codes (ZSADETC) Create a detail code for the student health insurance exemption/waiver.

2. Create fee exemption codes (TSAEXPT)

Create an exemption code to use when exemptions/waivers are received from Pearce & Pearce. The exemption code and associated rules are established in the Exemptions Form (TSAEXPT). Students will be assigned to the exemption code when the load process is successfully executed.

(24)

Rules are established for the Account Level, Category Code Level, or Detail Code Level. This illustration below is for rules at the Detail Code Level.

II. Creating a Submission File

Introduction to Creating a submission file

The Student Health Insurance Extraction (ZSRSHIR) is used to create a file to be submitted to Pearce & Pearce. The file contains specific information requested by Pearce & Pearce. The file will only include those participants in the mandatory insurance plan.

1. Execute ZSRSHIR _{The ZSRSHIR process creates the submission file for submission to} Pearce & Pearce. The process will create the file based on the assigned attribute. Additional required information will be included in the file based on the file layout provided by Pearce & Pearce.

Parameters for ZSRSHIR

01 Attribute Code Yes Enter the attribute code used as the selection criteria. 02 SSN or Student

ID

Yes Enter the value of ‘I’ if the file contains the Student ID or S if the file contains the SSN.

I

03 Address Hierarchy

Yes Enter the address type hierarchy. 1MA

04 Address Selection Date

Yes Enter the date for selection of address type entered. Sysdate

05 Email Address Hierarchy

(25)

06 Email Address Selection Date

Yes Enter the date used for selecting the valid email address. Sysdate

07 Effective Date Enter the date the mandatory plan becomes effective for the term.

Sysdate

08 Termination Date

Enter the date the mandatory plan is terminated for the term. Sysdate

09 Class Standing Enter the class standing Undergraduate, Graduate, Visiting Scholar

Sample Files Samples of the zsrshir.log, zsrshir.lis, and zsrshir.txt files follow.

Sample zsrshir.log

(26)

Sample zsrshir.txt

Note: This file has been compressed for the purposes of this document

III. Loading Exemption Data

Introduction to loading exemption data

The Student Health Insurance Exemption Load (ZSRHIEL) provides the user with the ability to assign students found in the waiver/exemption file provided by Pearce & Pearce to an exemption code within Banner.

1. Execute ZSRHIEL

The ZSRHIEL process assigns student ID numbers in the Exemptions Form (TSAEXPT) based on the waiver file provided by Pearce and Pearce. The process will match based on ID number, last name, first 3 letters of the first name, and the date of birth for the individual. The user enters the exemption code as a parameter and the process will assign each student in the file to the exemption code for the term specified.

Warning _{The exemption file received from Pearce & Pearce must be renamed to}

include a file extension of .csv for ZSRHIEL to read the file.

The file must be placed in the $DATA_HOME/arsys directory before executing the ZSRHIEL process.

Parameters for ZSRHIEL

01 Run Mode Yes Enter ‘A’ to execute process in audit mode or ‘U’ to execute the process in update mode.

A

02 Term Code Yes Enter the term you wish to assign to the exemption.

03 Exemption Code Yes Enter the exemption code the students in the waiver file will be assigned.

(27)

Sample Files Samples of the zsrhiel.log and zsrhiel.lis files follow.

Sample zsrhiel.log

(28)

Direct Deposit Subscription Process Flow

Description of Direct Deposit Subscription

The Direct Deposit Subscription provides the ability for students to enter banking information to process financial aid proceeds and other refunds to their checking accounts through Banner Student Self Service. Institutional users also have the ability to enter and maintain

subscription data through the Banner application.

The Direct Deposit Subscription flow includes the following major steps:

• Setting Up Rules and Codes

• Creating a Direct Deposit Subscription

• Reviewing/Maintaining Direct Deposit Subscription Data Warnings _{The Direct Deposit functionality requires setup in PeopleSoft}

Financials. Users should contact OIIT Customer Services to load a HelpDesk case for assistance with setting up direct deposit functionality in PeopleSoft.

(29)

Direct Deposit Subscription Process Flow Overview

Complete the following steps to set up, maintain, and create direct deposit subscriptions.

1. Define an e-mail process ZTVPROC

2. Define e-mail statuses and identify error conditions

ZTVSTAT

3. Establish e-mail host settings ZUREMRU 4. Create text and formatting for e-mail

notifications

ZURMAIL

5. Define e-mail type hierarchy ZUREHIR

6. Define letter codes GTVLETR

7. Define letter codes statuses ZUREPLS 8. Establish the Direct Deposit Process

controls

ZSRDDRU

9. Load bank routing numbers ZGRDIRD 10. Validate bank routing numbers GXVDIRD

↓

II. Creating a Direct Deposit Subscription

1. Enter the secure area of Banner Student Self Service

2. Select the Student and Financial Aid Menu Option

3. Select the eDeposit Menu option 4. Create Banking Information 5. Confirm the eDeposit Subscription

Agreement

6. Confirm the eDeposit Subscription Acknowledgement

7. Load the Direct Deposit Subscription Data into the PeopleSoft staging table

(30)

Using Direct Deposit Subscription

Introduction to

Setup Specific codes and rules are required for processing Direct Deposit _{Subscriptions. Users establish codes and rules within Banner to allow} the students to have the ability to enter, change, inactivate, and delete direct deposit banking information through Banner Student Self Service. The E-Mail Process Definition Form (ZTVPROC) is used to define the eDeposit process to the e-mail system for the generation of e-mail notifications to students.

The E-Mail Status Definition Form (ZTVSTAT) is used to define the statuses associated with e-mails. Error conditions are also identified. The E-Mail Rules Form (ZUREMRU) is used to enter the mail host settings for the institution. Users can define the Banner instance as production or test. Production will generate e-mail notifications to the student. Test will generate e-mail notifications to the e-mail address entered in the form.

The E-Mail Text Rules Form (ZURMAIL) is used to create the text and formatting for an mail notification. Types and descriptions of the e-mail notifications are entered or created in this form.

The E-Mail Hierarchy Definition Form (ZUREHIR) is used to define the hierarchy of e-mail types to which e-mail notifications will be generated to students.

The Letter Code Validation Form (GTVLETR) is used to define the letter codes for each type of e-mail notification that will be processed through direct deposit subscription.

The E-Mail Process/Letter/Status Control Form (ZUREPLS) is used to define the status of each letter code. The letter codes associated with direct deposit subscription are defined with system-required value of HOLD as the status.

The Direct Deposit Control Form (ZSRDDRU) is used to control the direct deposit processes. Users have the ability to activate or inactivate the Web subscription and Web refund. Agreement text is stored in this form.

The Bank Routing Number Load (ZGRDIRD) is used to load bank routing numbers from an ACH file into the Bank Routing Number Validation Form (GXVDIRD).

The Bank Routing Number Validation Form (GXVDIRD) is used to store the bank routing numbers.

(31)

1. Define an e-mail

process Define a Direct Deposit Subscription process to the e-mail system.

Note: The system-required value EDEPOSIT is delivered through a

script to load the record. This record should not be updated or deleted.

2. Define e-mail statuses and identify error conditions

Define e-mail statuses and identify potential error conditions in the E-Mail Status Definition Form (ZTVSTAT).

Note: The system-required values to support Direct Deposit are

delivered with a script. These delivered values should not be updated or deleted.

(32)

for the generation of e-mail notifications.

4. Create text and formatting for e-mail notifications

Create the text and formatting for e-mail notifications in the E-Mail Rules Form (ZURMAIL). The type and description may be entered, created, or updated from this form. When a transaction is created through Banner Student Self Service, the e-mail notification text and format will be sent to the student.

There are four types of transactions that will generate an e-mail

notification. Each notification is generated based on the text and format entered in this form.

• DDACT: This notification is generated when a direct deposit subscription is activated.

• DDCHG: This notification is generated when a direct deposit subscription is changed.

• DDDEL: This notification is generated when a direct deposit subscription is deleted.

• DDINACT: This notification is generated when a direct deposit subscription is inactivated.

(33)

5. Define the e-mail

type hierarchy Define the e-mail type hierarchy in the E-Mail Hierarchy Definition _{Form (ZUREHIR). The process code EDEPOSIT is used for the} address selection hierarchy.

(34)

7. Define letter

code statuses The E-Mail Process/Letter/Status Control Form (ZUREPLS) is used to _{define the status of each letter code. The letter codes are defined with a} system required HOLD status. E-mail requests are ‘released’ and changed to the status of SEND automatically once the subscription data is created, audit records are generated, and PeopleSoft data is created.

Note: Required values to support Direct Deposit Subscription are

(35)

8. Establish Direct Deposit Process Controls

The Direct Deposit Rules Form (ZSRDDRU) is used to control the Direct Deposit Process as follows:

• Turn on and off the link to the Direct Deposit Subscription and Refund Status pages on Banner Student Self Service.

• Create/edit the agreement text displayed on the agreement verification page of Banner Student Self Service.

• Create/enter hierarchy of address types. Note: The direct deposit process uses this hierarchy when selecting the student address to load into PeopleSoft.

The Web Subscription and Web Refund Enabled indicators allow the user to control the WebTailor settings that create the menu item. The menu items are available when the indicators are marked with a check. The Agreement Text provides the user with the ability to enter the text that is displayed when students subscribe to Direct Deposit. Note: The agreement text should follow National Automated Clearing House Association (NACHA) standards.

PeopleSoft requires address information for the processing of direct deposit subscriptions. The Address Hierarchy provides the priority for which an address will be selected to load into PS.

(36)

9. Load bank

routing numbers The Bank Routing Number Load (ZGRDIRD) is used to insert bank _{routing numbers in the Bank Routing Number Validation Form} (GXVDIRD).

ACH File _{The ACH file is obtained from the Federal Reserve Financial Services} Web site. The location is:

https://www.fededirectory.frb.org/download.cfm

The Receive All FedACH Participant RDFIs link should be selected to download the file containing the bank routing numbers. The files must then be moved from the location and saved to the

$DATA_HOME/tapedata/arsys directory for the ZGRDIRD process to read.

Parameters for ZGRDIRD

01 Fed ACH Data File Name

Yes Enter the name of the file downloaded.

Samples of the zgrdird.log and zgrdird.lis files follow. Sample zgrdird.log

(37)

(38)

10. Validate bank

routing numbers The Bank Routing Number Validation Form (GXVDIRD) is used to _{store the bank routing numbers for the purposes of validating when} direct deposit subscription data is entered through Banner Student Self Service.

Note: Required values are preloaded for the purposes of Direct Deposit

Subscription

II. Creating a Direct Deposit Subscription

Introduction to Direct Deposit Web Interface

The second major step in Direct Deposit Subscription is creating subscription data in Banner Student Self Service.

The user enters the secure area of Banner Student Self Service acting as a student. The eDeposit menu appears after selecting the Student and Financial Aid Menu option.

The eDeposit Subscription page provides the user with information regarding the subscription of direct deposit to an account. A sample check is displayed to provide the user with the location of the bank routing and account numbers. The user enters this data to create a subscription record. An e-mail notification is generated at the time the subscription is created.

The eDeposit Subscription Agreement page provides the institution permission to submit financial aid proceeds and other refunds to the bank account provided by the student.

The eDeposit Subscription Acknowledgement provides the user notification that data related to direct deposit have been

(39)

The eDeposit Subscription records generated are fed to PeopleSoft Financials. The information processed will allow for the creation of the ACH file to be sent to the bank for processing.

1. Enter secure area of Banner Self Service

Enter the Secure Area of Banner Student Self Service.

(40)

3. Select eDeposit

Menu Select the eDeposit Menu Option.

4. Create Banking

Information Enter the Bank Routing Number and the Bank Account Number that _{will be used to direct deposit financial aid proceeds and other refunds.} A sample check is provided to display the information required for processing.

(41)

5. Confirm eDeposit subscription agreement

The eDeposit Agreement is displayed when the user submits the routing and account numbers. The agreement text follows NACHA standards for the submission of banking information online.

(42)

6. Confirm Acknowledge-ment

The eDeposit Subscription Acknowledgement is displayed as a confirmation to the user that the information has been

received/processed.

7. Load Records into PeopleSoft

The loading of the subscription data into PeopleSoft Financials happens automatically by a trigger in the system. Once the Banner tables are saved, the data is sent through the Banner to PeopleSoft link to a staging table where it awaits further processing to be loaded in the required PeopleSoft tables.

(43)

III. Review/Maintain Direct Deposit Subscription Data

Introduction to maintaining Direct Deposit data

The third major step in Direct Deposit Subscription is the review and maintenance of subscription data.

The user can review and maintain Direct Deposit Subscription data in the Direct Deposit Subscription Form (ZSADDSD). This form displays current and historical subscription data.

The E-Mail Additional Information Form (ZURAEML) provides the ability to review and query e-mail notification statuses generated through the subscription process.

1. Review current and historical subscription data

Review the current subscription data for a student.

This information is displayed on the first screen of the form. The bank routing number is displayed. The account number is displayed as Xs with the exception of the last two numbers.

The most current banking information may be updated from this form. When new banking information is entered and the record is

saved/committed, the Bank Name information appears on the form for verification. The changes made will become the most current when the

(44)

2. Review e-mail notifications sent to students.

The status of e-mail notifications is reviewed in the E-Mail Additional Information Form (ZURAEML).

(45)

Refund Status Process Flow

Description of

Refund Status The Refund Status provides the ability for students to review Banner _{refund status information through Banner Student Self Service.} The Refund Status flow includes the following major step:

• Review Refund Status Information Refund Status

Process Flow Overview

Complete the following steps to set up, maintain, and create direct deposit subscriptions.

I. Reviewing a Refund Status

1. Enter the secure area of Banner Student Self Service

2. Select the Student and Financial Aid Menu Option

3. Select the Refund Status Menu option 4. Review Refund Status Information

(46)

Using Refund Status Page

I. Reviewing a Refund Status

Introduction to Refund Status Web Interface

The Refund Status page provides the student the ability to review the status of a refund processed in Banner. The student is provided with the transaction number, entry date, term code, and refund amount for all refunds processed to date.

Students with no processed refunds will receive a message stating, ‘No refunds have been processed.’

1. Enter secure area of Banner Self Service

Enter the Secure Area of Banner Student Self Service.

(47)

2. Select Student and Financial Aid Menu

Select the Student and Financial Aid Menu option.

3. Select Refund

(48)

4. Review Refund Status

Information

The refund status information is displayed. The student can review all refund transactions processed to date.

Warnings _{The refund status is displayed based on the RFD detail category code}

associated with the detail code. Detail codes without this category code will not be displayed.

(49)

Receipt Writing Process Flow

Description of

Receipt Writing Writing Receipts for Non-Student Receivables provides the ability to _{load outstanding charges for non-student receivables into Banner, write} the receipts for payments received, and feed the data into PeopleSoft. The data is stored in one subsidiary ledger.

The Receipt Writing flow includes the following major steps: • Setting Up Rules and Codes

• Writing Departmental Receipts • Loading General Person Records • Loading COBRA and Retiree Data • Processing Non-Student Receivables

Timeframe _{Institutions must begin writing receipts for all non-student related data} in Banner Accounts Receivable beginning July 1, 2005.

Warnings _{Non-student receivable data should only be receipted in the TF% forms} within the Banner Accounts Receivable module.

(50)

Receipt Writing Process Flow Overview

Complete the following steps to set up, maintain, and write receipts in Banner for non-student receivables.

I. Set Up Codes and Rules

1. Create detail codes ZSADETC

2. Create GTVSDAX rules GTVSDAX

↓

II. Writing Departmental Receipts

1. Write departmental receipts ZSAMISC

↓

III. Loading General Person Data

1. Request a file from PeopleSoft Financials

customer.csv

2. Load general person data ZORPDCL

↓

IV. Loading COBRA and Retiree Data

1. Request a file from PeopleSoft HRMS BBARxxx and ARxxx 2. Load COBRA and Retiree data ZGRARLD

↓

V. Processing non-student receivables

1. Send an invoice/bill 2. Write non-student receipts

(51)

Using Receipt Writing

Introduction to

Setup Detail codes are required for processing receipts in Banner Accounts _{Receivable. Detail codes are created in the Detail Code Control Form} (ZSADETC). Detail codes are defined as a charge or payment and have an associated category code.

Crosswalk Validation Rules (GTVSDAX) are required for loading HRMS COBRA and Retiree data into Banner Accounts Receivable. The rules defined will assign the detail code with the appropriate transaction when the load process is executed.

1. Define detail

codes Define detail codes for use during receipting of departmental deposits, _{COBRA, and Retiree charges.}

Note: Additional information regarding the establishment of detail

codes can be found in the Detail Code Maintenance section of this chapter.

2. Define crosswalk

(52)

II. Writing Departmental Receipts

Introduction to writing

departmental receipts

Institutional Departments often bring payments to the Business Office for receipt of funds. The departmental deposits are receipted into Banner to feed to the PeopleSoft Financials system.

1. Writing departmental receipts

Receipts for various institutional departments are written in the Miscellaneous Transactions Form (ZSAMISC). The form requires a balanced debit and credit entry.

Detail codes marked as GL Enterable in the Detail Code Control Form (ZSADETC) allow for the entry of account numbers in the Account field of ZSAMISC. Account number validation occurs at the time of

(53)

manual entry of the chart field string. The user also has the capability to search for valid chart field strings through the Chartfield Validation and Inquiry Form (ZSICHFD). Note: Additional information regarding account number validation can be found in the Detail Code Maintenance section of this chapter.

III. Loading COBRA and Retiree Data

Introduction to loading COBRA and Retiree data

The PS AR Banner Load Process (ZGRARLD) loads the transactional data for Retiree and COBRA recipients into Banner Accounts

Receivable.

1. Request a file _{The BBARxxx and ARxxx files are requested from PeopleSoft HRMS.} The BBARxxx file contains COBRA transaction data. The ARxxx file contains the Retiree transactional data.

The BBARxxx and ARxxx files should reside in the

$DATA_HOME/arsys directory for processing by the ZGRARLD process.

2. Execute

ZGRARLD Execute the ZGRARLD process.

The process is executed for each of the HRMS files received. The description associated with each transaction in the file will be associated with the detail code for COBRA or Retirees defined in GTVSDAX. A cashier session is generated based on the User ID entered as the

(54)

01 Run Mode Yes Audit Mode (A) will generate report output. Update Mode (U) will update the tbraccd table with transaction information.

A

02 COBRA or Retiree

Yes Enter a ‘C’ to process the COBRA file. Enter ‘R’ to process the Retiree file.

C

03 File Name Yes Enter the name of the file you are processing (BBARxxx.txt or ARxxx.txt).

04 User ID Yes Enter the user ID to be used to generate the cashier session. 05 Address

Selection Date

Yes Enter the date to be used when selecting the address. SYSDATE

06 Address Hierarchy

Yes Enter the address type hierarchy (1MA, 2PR).

This process will only load records when no errors are encountered. Errors are written to the report output and should be corrected for the data to load into Banner.

Sample Files Samples of the zgrarld.log and zgrarld.lis files follow. Sample zgrarld.log

Sample zgrarld.lis

Report Output

Errors You might see the following error(s): • ***ERROR: SSN/Name does not exist • ***ERROR: ATYP code does not exist

• ***ERROR-Sequence Number exists in TBRACCD. Aborting Program.

(55)

IV. Processing Non-Student Receivables

Introduction to processing non-student receivables

Banner baseline provides functionality for processing non-student receivables. Users have the ability to create and send invoices to the non-student receivables through the Invoicing/Statement Report (TFRBILL).

There are several forms available for writing receipts for non-student receivables. The primary form, TFADETL, is discussed in this document.

The Aging Analysis Report (TGRAGES) reports on all the past due accounts in Banner. The aging process is started by executing TFRBILL in STATEMENT mode.

Non-student receivables may have holds associated with the account. Holds are placed on a record by executing the Auto Hold/Release Process (TGPHOLD).

1. Send an

invoice/bill The Invoice/Statement Report (TFRBILL) allows the user the ability to _{generate invoices based on the invoice number for the current charges} (INVOICING mode), to produce a billing statement (STATEMENT mode), and to assess charges for recurring receivables (ASSESSCHG mode).

STATEMENT mode starts the aging process by updating the billed and due dates. The previously billed transactions are reflected in the

previous billed balance on the invoice. Detail will not be updated with a bill and due date until the effective date is reached. Future balances due will appear in detail based on the parameters used to execute the process until the effective date is reached and the process is run in

STATEMENT mode.

Note: An invoice/statement cannot be generated using TFRBILL when

the person has a term code other than ‘ARTERM’. Individuals with a term code other than ‘ARTERM’ have student related data. An invoice/statement must be generated using the Student Billing Process (TSRCBIL).

2. Write a

(56)

student receivable transactions when posted through the TFADETL form.

Detail information related to the non-student receivable is displayed in this form. The Account Balance and Amount Due will change when transactions are entered on this form.

3. Aging Analysis _{The aging process begins when the Invoice/Statement Report}

(TFRBILL) is executed in STATEMENT mode. The Aging Analysis Report (TGRAGES) provides the ability to analyze past due accounts. The report lists unpaid account balances within each age-date range in addition to future balances.

4. Setting and Releasing Holds

A hold is established using the Auto Hold/Release Process

(TGPHOLD). Holds are automatically set or released for a student, non-student, or entity based on the rules established in the Auto Hold Rules Form (TGAHOLD).

Information regarding baseline functionality is taken from the SSCT Accounts Receivable User Guide, version 6.0. Additional information may be obtained from this documentation.

(57)

Direct Debit Process Flow

Description of

Direct Debit Direct Debit provides the ability to withdraw funds from a customer’s _{bank account to relieve the debt owed to the institution while} simultaneously posting the “payment” to the customer account. The Direct Debit flow includes the following major steps: • Setting Up Rules and Codes

• Subscribing for Direct Debit • Creating the Working Area • Creating the ACH File

Timeframe _{Setting up rules and codes should be done as soon as an institution} determines this option will be made available for customer use.

Warnings _{There should be only one institutional representative responsible for} creating the Direct Debit Worksheet and ACH file.

(58)

Direct Debit Process Flow Overview

Complete the following steps to set up, maintain, and create an ACH file for Direct Debit

I. Set Up Codes and Rules

1. Create Bank Routing Numbers GXVDIRD

2. Create Bill Codes TTVBILL

3. Define a Detail Code ZSADETC

4. Create Bank Rules GXRBANK

5. Create Direct Debit Rules ZGRDEBT

6. Assign Bill Codes TSAACCT

7. Create Working Areas ZTVWKAR

↓

II. Subscribe for Direct Debit

1. Create Direct Debit Subscription records

ZGADEBS

↓

III. Create the Working Area

1. Create Working Area Records ZGADDWS

↓

IV. Create the ACH File

1. Create the Direct Debit ACH File ZGRDACH 2. Submit the ACH file to the bank

(59)

Using Direct Debit

Introduction to

Setup Bank routing numbers are required for validation of routing numbers _{provided by the individual subscribing for the use of Direct Debit. The} routing numbers are stored and maintained in the Bank Routing Number Validation Form (GXVDIRD).

Bill codes are created to allow the user the ability to select specific individuals into a working area. The bill codes are created and validated against the Bill Code Validation Form (TTVBILL).

A payment type detail code is established in the Detail Code Control Form (ZSADETC). This detail code will be used to pay outstanding charges that will be covered through the direct debit process.

Bank rules are established in the Bank Code Rules Form (GXRBANK). The rules are associated with a user-defined rule code for each bank the institution uses.

Direct debit rules are used to provide the agreement text and to define specific criteria for the ACH file. These rules are established in the Direct Debit Rules Form (ZGRDEBT).

Individuals participating may set up the optional use of a bill code. The bill code is assigned to the individual record in the Student Account Review Form (TSAACCT). The use of the bill code allows for the user to predefine the individuals that will be selected into a working area. Working areas are defined in the Working Area Validation Form (ZTVWKAR). An ACH file cannot be created without a defined working area. This is a one to one relationship – one working area per ACH file.

1. Create Bank Routing Numbers

Create and maintain bank routing numbers in the Bank Routing Number Validation Form (GXVDIRD) for validation when subscription records are created.

(60)

2. Create Bill Codes (Optional)

Define the bill codes to associate with individuals participating in direct debit in the Bill Code Validation Form (TTVBILL). The bill codes are validated in this form when entered in the Student Account Review Form (TSAACCT).

3. Define a Detail

Code Define the direct debit detail code in the Detail Code Control Form _{(ZSADETC). Direct Debit requires that a payment type detail code} with a category code of ‘CSH’ be built for the purposes of posting payments to individual accounts. The payment is posted to each account processed in the working area for the amount approved.

Note: If you need assistance in determining the accounting structure

behind this detail code, see the section related to detail codes in the Using Banner Accounts Receivable User Guide.

(61)

4. Create Bank

Rules Create the institution’s bank rules for processing the direct debit ACH _{file in the Bank Code Rules Form (GXRBANK). The bank code is user} defined to identify the bank to which the collected funds will be

(62)

5. Create Direct Debit Rules

Create the rules related to direct debit processing in the Direct Debit Rules Form (ZGRDEBT). The agreement text is stored in this form and is related to the individual subscription records. The debit description, padding, and file ID information are all used when creating the ACH file and provide formatting information for the process.

6. Assign Bill

Codes (Optional) A bill code is assigned to an individual through the Student Account _{Review Form (TSAACCT). Direct Debit processing provides the} ability for users to define bill codes for individuals. The bill code is used when creating the working area so that a specific population of individuals is retrieved for processing.

(63)

7. Create Working

Areas A working area name is created in the Work Area Validation Form. _{The work area is used when selecting records for processing as direct} debit payments. The work area entered in the Direct Debit Worksheet Transaction Form (ZGADDWS) is validated against the records in this form. The process indicator is also located here to identify those working areas that have been processed or are waiting to be processed.

(64)

II. Subscribe for Direct Debit

Introduction to subscribing for Direct Debit

Individuals receiving benefits often prefer to have their savings or checking accounts direct debited for the purposes of making payments to the institution for benefits received. The subscription process allows the institution to establish the banking and related information for the individuals.

1. Create Direct Debit

Subscription Records

A subscription record for Direct Debit is created in the Direct Debit Subscription Form (ZGADEBS). Individuals who want to participate in Direct Debit will provide the institution with written authorization to establish the subscription record.

The routing number is entered and validated against GXVDIRD. The name of the bank is automatically populated when a valid routing number is entered. The account number is entered and the account type (Checking or Savings) is selected. Once the record is saved, the account number is masked and only displays the last two digits. The

Active/Inactive indicator is also selected here.

This form also contains the history records of changes made to Direct Debit subscription records. Any activity where changes are made to the subscription record are recorded and displayed in the audit trail of the form.

(65)

III. Creating a Working Area

Introduction to Creating a Working Area

The Direct Debit Worksheet Transaction Form (ZGSDDWS) is used to create and alter the accounts and amounts of the individuals to be processed as direct debit transactions.

1. Create Working

Area Records Create a working area for direct debit transactions in the Direct Debit _{Worksheet Transaction Form (ZGADDWS). The work area name is} entered in the key block. The bill code is not required for processing a work area; however, it allows the user to select specific groups of individuals for processing.

The data block displays the ID, name, bill code, amount, and status of the individuals queried when a page down function is performed. Individuals can be removed from the working area by using the status of Reject. The amount can be changed to decrease the total to be direct debited by entering a new amount in the amount column for the individual. However, the amount cannot exceed the balance on the individual account.

If an individual already exists in another working area, a warning appears and the individual is highlighted in orange.

(66)

The amount queried is the total amount due for the individual and may exceed the amount of benefits the individual is charged.

IV. Creating the ACH file

Introduction to Creating the ACH file

The Direct Debit ACH File Process (ZGRDACH) is used to generate the ACH file for submission to the institution’s bank. The process uses the parameters to select the work area name for processing. The

individuals in the work area with a status of Approved will be written to the ACH file. A direct debit payment will be posted to the individual account for the amount approved in the working area.

1. Create the Direct

Debit ACH File The ACH file is generated when the Direct Debit ACH File Process _{(ZGRDACH) is executed in update mode. The ACH file is generated} with the name of ACH_workareaname.txt. This name may need to be changed prior to submission to the bank.

Warning _{Some banks may require that positions 40–54 of all type 6 records be}

populated with an identification number. Parameter 10 allows the user to select the option to populate these positions with the ID number, PIDM, or a Null value. The population of the ID number or PIDM in these positions may result in the number displaying on the individual bank statement.

(67)

Parameters for ZGRDACH

01 Audit/Update Mode

Yes Audit Mode (A) will generate report output. Update Mode (U) will update the individual accounts and create the ACH file.

A

02 Working Area Yes Enter the working area name that will be processed 03 Address

Selection Date

Yes Enter the date of which address that is effective on this date will be selected for the accounts processed

Sysdate

04 Address Selection Hierarchy

Yes Enter the address type to be printed on the report. 1MA

05 Detail Code Yes Enter the direct debit payment type detail code to be posted to the individual accounts.

06 Term Code Yes ARTERM is default value when this parameter is left blank. 07 Cashier User ID Yes Enter the cashier user ID that will be used when the payment

transactions are processed.

08 Bank Code Yes Enter the bank code created in GXRBANK. This is the bank code that is referenced in the ACH file.

09 Bank Selection Date

Yes Enter the date for selecting the bank data that is effective for this date.

sysdate

10 Individual Identification

Yes Enter ‘I’ for ID, ‘P’ for PIDM, or leave blank. The default value is null.

11 File Location Yes Enter the location for the ACH file to be written. Note: The length of the file location cannot exceed 30 characters. 12 Trace Number

Indicator

Yes Enter ‘Y’ to produce a trace number or ‘N’ to leave positions zero filled.

N

Sample Files Samples of the zgrdach.log and zgrdach.lis, and ACH files follow. Sample zgrdach.log

(68)

Sample zgrdach.lis

Sample ACH file

2. Submit the ACH

File to the Bank The ACH file is submitted to the bank to receive payment deducted _{from individual accounts for benefits received.}

(69)

End of Day Processing Flow

Description of End

of Day Processing The baseline and GaMod processes and forms included in End of Day _{Processing provide the user with the ability to create the accounting} entries for the PeopleSoft General Ledger and Accounts Payable modules.

The End of Day Processing flow includes the following major steps: • Baseline Functionality

• Account Aging and Reporting • Non-Banner Finance Interface

• Deleting Records from the GURFEED Temporary Table • Resetting a Feed

• End of Day Processing Check List

Timeframe _{Institutions should execute the end of day processes on a daily basis.} End of Day Process

Flow Overview Complete the following steps to maintain and create general ledger _entries.

I. Baseline Processing

1. Assess Fees SFRFASC

2. Assess housing and meal charges SLRFASM 3. Apply contracts, exemptions, and deposits TSRCBIL 4. Close all non-cash drawer cashier sessions TGRCLOS/

TGACREV 5. Close cash drawer cashier sessions TGACREV

6. Process refunds TSRRFND

7. Finalize all closed cashier sessions TGACSPV 8. Produce report of all finalized cashier

sessions

TGRCSHR

9. Apply all payments TGRAPPL

(70)

II. Account Aging and Reporting

1. Insert due date and initiate aging ZSRCBIL

2. Aging Analysis ZGRAGES

↓

III. Non-Banner Finance Interface

1. Execute the Non-Banner finance interface ZGRPSLD

↓

IV. Purging ZURGFTT

1. Delete records from the GURFEED temporary table

ZOPGFTT

↓

V. Resetting a Feed

1. Reset a problematic feed zorfred.sql

↓

VI. End of Day Processing Check List

(71)

Using End of Day Processing

I. Baseline Processing

Introduction to Baseline Processing

Banner baseline provides functionality for preparing records to be fed to the financials system, PeopleSoft.

1. Assess Fees _{The Batch Fee Assessment Process (SFRFASC) is used to assess fees} for all students in batch mode.

2. Assess housing and meal

charges

The Batch Room/Meal/Phone Assessment Process (SLRFASM) is used to assess housing, meal, and/or phone fees in batch mode.

3. Apply contracts, exemptions, and deposits

The Student Billing Process (TSRCBIL) is used to post contracts, exemptions, and deposits to student accounts when executed in APPLYCRED mode.

4. Close non-cash drawer cashier sessions

Non-cash drawer cashier sessions are closed using the Automatic Cashier Session Close Process (TGRCLOS) or using the Cashier Session Review Form (TGACREV).

The TGRCLOS process will close, finalize, close and finalize, or by-pass cashier sessions automatically. User-defined rules for the criteria to close, finalize, close and finalize, or by-pass cashier sessions are found in the Charge/Payment Source Code Validation Form (TTVSRCE). The TGACREV form will permit a supervisor to close non-cash drawer cashier sessions manually.

5. Close cash drawer cashier sessions

The Cashier Session Review Form (TGACREV) is used by individual cashiers to close reconciled/balanced sessions. An open cashier session maintains a session number of 0 (zero) until it is closed. The form displays charges, payments, or both charges and payments. Detail information related to the charges and/or payments is displayed on the second page of the form.

The cashier’s cash drawer is expected to balance back to cash type payments found in TGACREV.

(72)

7. Finalize cashier

sessions The Cashier Supervisory Form (TGACSPV) is used to finalize closed _{cashier sessions.} Open cashier sessions are displayed on the first page of this form. The second page of the form displays the closed, finalized, and reported cashier sessions.

Cashier sessions may also be finalized using the Auto Cashier Session Close Process (TGRCLOS).

8. Produce finalized cashier session report

The Cashier Detail Report (TGRCSHR) provides a list of the transactions by cashier, cashier session, detail code, and date. Each cashiering session and session number reported includes the detail code, associated ID number, amount of the transaction, as well as the

transaction and effective dates.

9. Apply all

payments The Application of Payments Process (TGRAPPL) is used to apply _{payments to outstanding charges. The application of a payment is based} on the user-defined and system-defined priorities. Payments with a balance greater or less than zero will be used to relieve charges with a balance greater or less than zero when both have an effective date less than or equal to the current date.

10. Unapply

payments from application pending roster

The Student Unapplication of Payments Form (TSAUNAP) is used to unapply payments based on term, transaction number, or applied date. This form should be used to unapply payments for students appearing on the Application Pending Roster.

11. Reapply payments

The Account Detail Review Form (TSAAREV) can be used to reapply payments for students whose payments were unapplied.

12. Create GL and AP entries

The Accounting Feed Process (TGRFEED) produces the entries to be made to the General Ledger and Accounts Payable modules of

PeopleSoft Financials.

The totals are verified for a balanced entry to be made in the financials system.

13. Generate the reconciliation report

The Accounts Receivable Reconciliation Report (TGRRCON) enables the user to reconcile receivable data with the general ledger. The report calculates the accounting information based on the term code and the associated designator code.

Additional information regarding the Baseline functionality may be obtained from the Accounts Receivable User Guide, version 6.0.

Using AR Sole Receivables

Using AR Sole Receivables

Georgia Enhanced Banner Student and

Financial Aid Systems User Documentation

Version 7.1.1.1

Table of Contents

Using AR Sole Receivables

Introduction to AR Sole Receivables

AR Sole Receivables Forms and Processes Reference

Detail Code Maintenance Process Flow

↓

Detail Code Maintenance

Fee Assessment Process Flow

↓

Fee Assessment

Student Health Insurance Process Flow

↓

↓

Student Health Insurance

Direct Deposit Subscription Process Flow

↓

Using Direct Deposit Subscription

Refund Status Process Flow

Using Refund Status Page

Receipt Writing Process Flow

↓

↓

↓

↓

Using Receipt Writing

Direct Debit Process Flow

↓

↓

↓

Using Direct Debit

End of Day Processing Flow

↓

↓

↓

↓

Using End of Day Processing