Student Billing Implementation Guide · Student Management 1 Implementing Student Billing Setting...

Student Billing

Implementation Guide

Copyright (c) 2001 Jenzabar, Inc. All rights reserved. You may print any part or the whole of this documentation to support installations of Jenzabar software. Where the documentation is available in an electronic format such as PDF or online help, you may store copies with your Jenzabar software. You may also modify the documentation to reflect your institution's usage and standards. Permission to print, store, or modify copies in no way affects ownership of the documentation; however, Jenzabar, Inc. assumes no responsibility for any changes you make. Filename: imstub Distribution date: 06/21/2001 Contact us at www.jenzabar.com

Jenzabar CX and QuickMate are trademarks of Jenzabar, Inc. INFORMIX, PERFORM, and ACE are registered trademarks of the IBM Corporation Impromptu, PowerPlay, Scenario, and Cognos are registered trademarks of the Cognos Corporation UNIX is a registered trademark in the USA and other countries, licensed exclusively through X/Open Company Limited Windows is a registered trademark of the Microsoft Corporation All other brand and product names are trademarks of their respective companies

i

JENZABAR, INC.

STUDENT BILLING IMPLEMENTATION GUIDE

TABLE OF CONTENTS

Setting Up Student Accounts/Billing Tables............................................................................................... 1 Introduction............................................................................................................................................. 1 Billing Parameters Record...................................................................................................................... 1 Fields in the Billing Parameters Record ................................................................................................. 1 Assessment Table .................................................................................................................................. 2 Fields in the Assessment Table ............................................................................................................. 3 Functions of the Primary and Secondary Sections ................................................................................ 4 Conditions Fields .................................................................................................................................... 4 Primary Section Fields............................................................................................................................ 5 Secondary Section Fields....................................................................................................................... 5 Refund Section Fields ............................................................................................................................ 6 File and Field Keywords ......................................................................................................................... 6 Database File Keywords......................................................................................................................... 6 Keywords Based on Accumulated Hours or Courses ............................................................................ 7 Other Keywords...................................................................................................................................... 7 Charge Table.......................................................................................................................................... 8 Fields in the Charge Table ..................................................................................................................... 8 Charge Table Break Definition Fields..................................................................................................... 9 Charge Table Calculation Fields ............................................................................................................ 9 Refund Table (rfnd_table)..................................................................................................................... 10 Classification Table .............................................................................................................................. 10 Subsidiary Total Table.......................................................................................................................... 11 Entry table............................................................................................................................................. 11 Example Charge and Assessment Tables: Lab Fees......................................................................... 11 Example Assessment and Charge Tables: Drop/Add Fees................................................................ 11 Example Assessment and Charge Tables: Dorm Fees ...................................................................... 11 Example Assessment and Charge Tables: Tuition Charges .............................................................. 12 Example Assessment and Charge Tables: Meal Plan Charges ......................................................... 12 Example Assessment and Charge Tables: Course Audit Fees .......................................................... 12 Example Assessment and Charge Tables: Pre-Payment Credits ...................................................... 13 Example Assessment and Charge Tables: holding accounts............................................................. 13

Evaluating and Implementing Special Student Billing Features............................................................. 14 Introduction........................................................................................................................................... 14 Macro Values........................................................................................................................................ 14 Configuration Table Entries.................................................................................................................. 14 Table Entries Relating to the Distribution of Financial Aid by Fee Collection ...................................... 14 Table Entries Relating to Consolidated Statements............................................................................. 15 Table Entries Relating to Financial Aid Refunding using Multiple Subsidiaries................................... 15 Include Relating to Display of Pending Financial Aid on Statements .................................................. 15

Calculating Interest on Subsidiary Accounts............................................................................................ 17 Introduction........................................................................................................................................... 17 Prerequisites......................................................................................................................................... 17 Student Billing Charges vs. Interest Charges ...................................................................................... 17 Tables Used for Interest Calculations .................................................................................................. 17 Types of Interest Calculation Methods ................................................................................................. 18 Balance Type Calculations................................................................................................................... 18 Sample Data Used ............................................................................................................................... 18 Beginning and Ending Balance Methods ............................................................................................. 19 Codes Beginning and Ending Balance................................................................................................. 19 Average Daily Balance Method ............................................................................................................ 20 Example of the Average Daily Balance Method................................................................................... 20 Assessment Table Codes for the Average Daily Balance Method ...................................................... 21

ii

Balance Minus Credits Method ............................................................................................................ 21 Codes: the Balance Minus Credits Method......................................................................................... 21 Invoice Type Calculations..................................................................................................................... 22 How to Run the Interest Program......................................................................................................... 22

Calculating Minimum Payment................................................................................................................. 24 Introduction........................................................................................................................................... 24 The Deferred Payment Table ............................................................................................................... 24 Sample Data Used for Deferred Payment Table.................................................................................. 24 Month and Day Example ...................................................................................................................... 24 Formulas for Computing the Minimum Payment.................................................................................. 25 Examples of Calculations ..................................................................................................................... 25 Examples of Calculations ..................................................................................................................... 25 Examples of Calculations ..................................................................................................................... 26 Examples of Calculations ..................................................................................................................... 27

Running the Billing Program From the Shell ............................................................................................ 29 Introduction........................................................................................................................................... 29 Prerequisites......................................................................................................................................... 29 Parameters ........................................................................................................................................... 29 Interactive Mode ................................................................................................................................... 29 Verify Report Mode............................................................................................................................... 29 Verify Report Mode............................................................................................................................... 29 Post Charges Mode or Execute Mode ................................................................................................. 30 Process-to-Process (PTP) Modes........................................................................................................ 30 Optional Parameters............................................................................................................................. 31 Compilation Values............................................................................................................................... 31 Program Flow ....................................................................................................................................... 31

Using Reports and Audits to Review a Billing Period .............................................................................. 33 Introduction........................................................................................................................................... 33 Accounting Subsidiary Ledger Audits................................................................................................... 33 Student Billing and Accounting Reports ............................................................................................... 33 Registration Reports............................................................................................................................. 34 Student Services Reports..................................................................................................................... 34

Report File Information............................................................................................................................. 35 Introduction........................................................................................................................................... 35 Report Access and Files....................................................................................................................... 35

Preparing for a New Billing Session......................................................................................................... 38 Introduction........................................................................................................................................... 38 Macro Files to Update .......................................................................................................................... 38 Tables Specific to General Ledger ....................................................................................................... 38 Tables Specific to Student Accounts/Billing ......................................................................................... 38 Other Functions to Review and Update ............................................................................................... 40 Additional General Ledger Tables........................................................................................................ 40

Processing Taxpayer Relief Act Information (1098-T) ............................................................................. 42 Introduction........................................................................................................................................... 42 Format of Required Information ........................................................................................................... 42 Required Information ............................................................................................................................ 42 CARS Solution Record Used for Data Collection................................................................................. 42 Reports from Data Collection ............................................................................................................... 42 Impact of 1098-T Processing on Other Tables and Records............................................................... 42 Process Flow for 1098-T Production .................................................................................................... 43 Macro Setup for 1098-T Processing..................................................................................................... 45 Macros in $CARSPATH/macros/custom/t1098.................................................................................... 45 Macros in $CARSPATH/macros/custom/periodic ................................................................................ 48 Other 1098-T Macros that Do Not Require Modification...................................................................... 48 Macros in $CARSPATH/macros/custom/comment.............................................................................. 48 Macros in $CARSPATH/macros/user/prompt ...................................................................................... 48 Macro in $CARSPATH/macros/user/inc............................................................................................... 49 Menu Options for Data Collection and Formatting ............................................................................... 49

iii

Menu Options for Reporting ................................................................................................................. 50

INDEX ......................................................................................................................................................... 51

Student Management 1 Implementing Student Billing

Setting Up Student Accounts/Billing Tables

Introduction The billing program uses information that you have entered in several database files to calculate student charges based on registration and student services information. The information on these pages describes each file and identifies how each database field is used by the billing program to calculate charges.

For more information on how to run the billing program once your institution sets up the tables, see Running the Billing Program From the Shell in this guide.

Billing Parameters Record The Billing Parameters record (pbill_rec) defines several parameters required by the billing program to calculate student charges. The information determines the academic program and session for which charges are to be calculated and identifies posting information. The Interest program also shares the Billing Parameters record to obtain information used for calculating interest charges on past due account balances.

For information on how to set up interest parameters, see Calculating Interest on Subsidiary Accounts in this guide.

Following is an example of the Billing Parameters record. Query Next Previous View Add Update Remove Table Screen Current Master Detail ... Searches the active database table. ** 1: pbill_rec table** BILLING PARAMETERS Billing Parameter...[ ][ ] Program.............[ ] Billing Code........[ ] Session.............[ ] Year................[ ] Site................[ ] Subsession..........[ ] Bursar Calc.........[ ] Subsidiary Code.....[ ] Subsidiary Entry....[ ][ ] Bal Code............[ ] Bal Period..........[ ] G/L Account.........[ ][ ][ ][ ]

Fields in the Billing Parameters Record The following list contains descriptions of the fields that appear in the Billing Parameters record.

Bal Code The Subsidiary Balance record in which to post charges. The value in the Bal Code field identifies the type of Subsidiary Balance record, and the value in the Bal Period field identifies the balance period in which to post charges. Since the Bal Period field and the Academic Session fields contain different values, billing uses the Bal Period code to link academic session codes to balance periods.

Bal Period The subsidiary balance period to which to post charges.

Billing Code A code linking Billing Parameters information to the Assessment record. You can enter either SB (for Session Billing) or INT (for Interest Parameters) in this field. The billing

Implementing Student Billing 2 Student Management

program uses this field with the Session, Year, Program, and Subsession fields to join to the Assessment tables for table lookup purposes.

Billing Parameters A unique billing code that is used to reference information in a Billing Parameters record. The billing program uses this code to find and read information in a Billing Parameters record. Use the untitled field to the right of the Billing Parameters field to enter text that describes the run code. The untitled field is the Descr field.

Bursar Calc A Y/N flag enabling billing to calculate or charge financial adjustments and display the information in the bursar program. An "N" in this field indicates that the bursar program can calculate and display the specified session in the record as long as there are posted charges or credits. However, the system will not calculate financial aid adjustments. A "Y" in this field indicates the bursar program can calculate and display charge or financial aid adjustments in the bursar program. This field allows the bursar to turn off the automatic calculation of billing adjustments for the session in which additional billing charges are not to be posted.

Entry Type The entry code (e.g., BILL) used to post student billing charges. The value in this field must be a valid entry code in the Entry Type table.

Program An academic program (e.g., UNDG) that is to be billed. You must enter a code in this field. A separate Billing Parameters record must exist for each academic program to be billed.

Session (The academic session to be billed.

Subsession The subsession to be billed. Leave this field blank unless your institution wants to set up separate billing runs for each subsession within a session. Generally, this field is left blank, and subsessions are billed together in one billing run for a session.

Subsidiary Code The student account subsidiary (e.g., S/A) in which Billing is to post subsidiary student charges. The subsidiary must use Subsidiary Balance records (subb_rec) and Subsidiary Total records (subt_rec).

Subsidiary Entry Desc The description of the General Ledger Entry record when charges are posted to student accounts. The description is the heading for student billing charges that are printed on the student account statements.

Year The academic calendar year (e.g., 1998) of the academic session to be billed.

Assessment Table The Assessment table (assess_table) defines the criteria used to determine whether or not a student is to be charged, and defines the information on which to base the charge. You must set up Assessment tables for each session and academic program in which automated student billing occurs.

It is important to understand the function of the Assessment and Charge tables in automatic student billing. The Charge table determines the dollar amount of a charge. The Assessment table determines the charges that apply to a student, and also determines some of the information used in the Charge table to calculate the amount.

The billing program calculates charges to be posted by loading all of the Assessment tables that join the selected Billing Parameters record. The join is based on the fields in each record for the session, year, subsession, and bill codes (e.g., SB). The billing program selects a charge code based on information in the Assessment table and on information found in other files referenced


by the Assessment table. If the charge code matches the session and academic program of the billing run, the billing program then calculates dollar amount.

Following is an example of an Assessment table. See Conditions Fields in this section for explanations of the lower case letters assocated with the fields.

ASSESSMENT TABLE Code.............[a ][b ] Program......[c ] Billing Code.....[d ] Session...[e ] Year........[f ] Subsession...[g ] CONDITIONS: #1.......[h] [i ] [j ] [ ][k ] #2..[l ][m] [n ] [o ] [ ][p ] #3..[q ][r] [s ] [t ] [ ][u ] #4..[v ][w] [x ] [y ] [ ][z ] IF TRUE: Charge Code.........[pa ] [ ][pb ] (primary) Charge Units........[pc ] [ ][pd ] Break Code..........[pe ] [ ][pf ] Break Units.........[pg ] [ ][ph ] IF FALSE: Charge Code.........[sa ] [ ][sb ] or NONE: Charge Units........[sc ] [ ][sd ] (secondary) Break Code........ .[se ] [ ][sf ] Break Units.........[sg ] [ ][sh ] REFUND: Based on ...........[ra ] [rb ][rc ] Schedule ...........[rd ] as of Date.. 12/31/191998 Pct..

Fields in the Assessment Table The First two lines of the Assessment table constitute the identification section of the table. The identification section contains fields that link the Assessment table to the Billing Parameters record and the Charge table.

The following list contains descriptions of fields that appear on the top two lines in the Assessment table.

Billing Code A value that links information from the Billing Parameters record to the Assessment table along with the session, year, subsession, and program codes. The Billing program calculates interest charges instead of student billing charges if this fields contains any value defined in the INT_BILL_CODE macro in the billing macro file located in the following directory path: $CARSPATH/include/custom/billing.

Code A four-character code that references an Assessment table. The value in this field is not used as a direct link to the charge code. Rather, the value in this field references an Assessment table and must be unique within each session, subsession, and program. Use the untitled field to the right of the Code field to enter text that describes the purpose of information within an assessment. The untitled field is the assess_desc field.

Program The academic program (e.g., UNDG) that is to be billed. You must enter a code in this field. The Billing Parameters program bills each academic program separately.

Session The academic session to be billed.

Subsession The subsession within a session to be billed. Leave this field blank, because all subsessions within a session can be billed at the same time.

Year


The academic calendar year (e.g., 1998) of the academic session to be billed.

Functions of the Primary and Secondary Sections The primary and secondary sections in the Assessment table correspond to an if-then-else statement. The following is an example of an if-then-else statement: “If test conditions are true, then use primary side, else use secondary side”.

If the conditions specified in one of the Conditions fields are met, billing uses the primary side and ignores the secondary side. If the conditions listed in the Conditions fields are not met, billing ignores the primary side and uses the secondary side.

Each primary and secondary section contains fields from a set of special codes that reference other database files, accumulations of courses or hours (audit, registered, or total), or constant values. When the billing program reads an assessment, the primary and secondary values are translated by information already in the database for a student. Once the values have been found, the billing program evaluates the conditions. If the condition is met, billing uses the primary side to determine the charge. If the condition fails, billing uses the secondary side to determine the charge.

You can leave all the fields in a primary or secondary section blank if the section is not needed. However, complete all required fields when using a section. You must complete the Charge Code and Charge Units fields and only one of the Break Code or Break Units fields.

Conditions Fields The Condition #1 [h-k], Condition #2 [m-p], Condition #3 [r-u], and Condition #4 [w-z] fields comprise the "if" part of the if-then-else statement for the primary section. You can specify up to four test conditions. If only one test condition is needed, use Condition #1 fields and leave the Condition #2, 3, and 4 fields blank. If more than one condition is needed, you can logically relate them by using “and or” in the test. Using “and” requires that the conditions be met to use the primary fields [pa-ph]. Using “or” requires that only one of the conditions be met to use the primary fields [pa-ph].

If there are no primary test conditions, leave the primary fields [pa-ph] blank. Since the primary test conditions are blank, use the secondary fields [sa-sh].

To use a combination of "and/or" conditions, Condition #1 and Condition #2 must be parenthetically linked. Condition #3 and Condition #4 must be similarly linked. The "and/or" code that you entered for [q] is considered the logical link between the two parenthetical tests. You would interpret the following combination of "and/or" tests as follows:

Case 1: (Test 1 OR Test 2) AND (Test 3 OR Test 4)

Case 2: (Test 1 AND Test 2) OR (Test 3 AND Test 4)

Case 3: (Test 1 OR Test 2) AND (Test 3 AND Test 4)

The [l], [q], or [v] field can contain either an "and" or "or" value. This value is used in relating the Condition tests. Leave this field blank if Conditions #2, 3, or 4 is not needed. The [h], [m], [r], or [w] field identifies a relational operator that determines how to compare the constant value of the test with a value found for a student. The relational operators are valid.

= Equal to

! Not equal to

< Less than

>


Greater than

The [i], [n], [s], and [x] fields identify a fixed or constant value that is compared with student information. This value must contain four or fewer characters, and can either be a numeric code or an alphabetic code.

Use the [j] and [k], [o] and [p], [t] and [u], and [y] and [z] fields to enter special keywords that Billing reads and translates to actual values located in a student's database records. If the four-character keyword or "file" field ([j], [o], [t], or [y]) contains an entry, then the longer field ([k], [p], [u], [z]) must contain a corresponding value to further identify the value for which the Billing program is searching. For more information on valid reference codes that you can use in the Conditions fields, see File and field keyword in this section.

CAUTION: Do not use the keywords CODE, SAME, SUBS, or UNIT in the Primary Test fields. Also, if you use a database record keyword (e.g., TFAC, SERV), and billing cannot locate the referenced database record for a student, then the primary test condition will fail.

Primary Section Fields The primary section fields determine what information is used to charge students when the primary test conditions are met. If the primary section does not apply for any charge, leave all the primary fields blank.

The following list contains descriptions of the primary section fields in the Assessment table.

Charge Code [pa], [pb] The actual charge code used to post a student billing charge to a student's account. This value is the link from the Assessment tale to the Charge table. Enter any valid file keyword in this field, except the code SAME.

Charge Units [pc], [pd] The charge units that are used to calculate a fee. When billing locates the Charge table for the assessment, it multiplies the charge units by the rate specified in the Charge table. In the following equation used to calculate the charge fee, the charge units are substituted for the "UNITS" variable in the equation. You can enter any valid keyword in this field except for SUBS or SAME. The Primary Charge Units field must contain a valid keyword, even though the charge rate may be zero. The following is the formula used for calculating a fee based on the charge units: Fees = Base + Rate * ((UNITS - Offset) / Step

Break Code Break Units

Determine which charge break level is used to calculate the fee. The Charge table allows up to three separate break levels that can be used to charge up to three different fee amounts within the same Charge record. You can select a break level either by using a one- to four-character code or by entering a numeric value (using Break Units); however, you cannot use both. You must use either the Break Code or Break Units field. If there is only one break level used in the Charge table, enter the keyword SAME to indicate that the break code or break units are the same as the charge units. You can enter any valid keyword in the Break Code or Break Units field except for SUBS.

Secondary Section Fields The following secondary section fields function the same as the corresponding primary fields:

• Charge Code [sa], [sb] • Charge Units [sc], [sd] • Break Code [se], [sf]


• Break Units [sg], [sh]

The main difference between the primary and the secondary fields is that billing uses the secondary side only when the Primary Test fails or does not exist (i.e., is not entered).

Refund Section Fields The refund section references a refund schedule from the Refund table (rfnd_table). This allows percentage refunds to be returned to students based on date values. For percentage refunds to function properly, there must be a date value that is used to locate the correct refund schedule and percentage that applies on that date. If no date can be referenced, a refund schedule cannot be used, and billing refunds 100 percent of the fee.

You can specify refund dates in two ways. Since the Registration process automatically adds a Registration record (reg_rec) for each course added or dropped with the date of the add or drop, the billing program accesses these dates and refunds student fees based on the actual drop dates. To use this method, the Primary Charge Units or Secondary Charge Units field must use one of the accumulator keywords (e.g., THRS, RHRS). In addition, the Refund Conditions [ra] field must contain the keyword "TUIT." If the assessment Charge Units fields do not contain one of the accumulator keywords, the Refund Conditions field must be blank. The only two options that you have for completing this field is to enter the code TUIT or leave the field blank.

The second method involves charges that are not based on course adds or drops, but that still depend on a date value. The Refund Date [rb] or [rc] fields enable you to specify a date from a database record. You can use any four-character keyword that references a database record (e.g., ACAD, SERV, PENR). The field [rc] must be a database field in the given record that is a date type field.

You can enter the refund schedule code in the Refund Schedule [rd] field. This code is a valid code from the Refund table that matches the session and academic program specified in the Assessment table.

File and Field Keywords Using fields in the Assessment table, you can enter certain keywords that billing translates when a student is selected. The billing program translates keywords to a value that usually corresponds to a value from the student's database records. For example, if you specify registered hours, the system calculates the registered hours for the selected student. Similarly, if you specify the database record containing the Dorm field, billing locates and uses the actual code for the dormitory that the student is signed up for.

Each of the primary or secondary fields discussed previously contain two codes. One code is a four-character code, and the second code is a thirty-six character description of the four-character code. The four-character code is called the "file" or "keyword" field, and the description is called the "field." You must have an entry in both the file and field for every type of keyword, except for the keyword "SAME."

Database File Keywords The database file keywords reference a list of database records that the billing program looks up for a student. For each of the records listed in the following table, you must enter a code and the field value must be a valid database field name from the database record specified. The following table describes the database file keywords.

Note: If you add local fields, you must reinstall all source programs for those fields to be recognized. You should notify offices that are impacted by these fields.

ACAD Student Academic Record (stu_acad_rec)

CUST Student Billing Customization Record (sbcut_rec)

ID


ID Record (id_rec)

PENR Program Enrollment Record (prog_enr_rec)

PROF Profile Record (profile_rec)

SERV Student Services Record (stu_serv_rec)

SUBA Subsidiary Account Record (suba_rec)

TFAC Facility Table (facil_table)

Note: This table is based on campus, dorm, and room values in the Student Services record (stu_serv_rec).

Keywords Based on Accumulated Hours or Courses When you use the accumulator values, the field must contain either the code "ALL," which causes billing to total all of the hours or courses for the keyword type; or a code that is a valid tuition, fee, or bill code. When a tuition, fee, or bill code is used, billing only totals the number of hours or courses that a student is registered for that contain the tuition, fee, or bill code specified.

The following list describes the keywords that are based on accumulated hours or courses.

THRS Total number of registered and audit hours

TCRS Total number of registered and audit courses

RHRS Total number of registered hours

RCRS Total number of registered courses

AHRS Total number of audit hours

ACRS Total number of audit courses

FHRS Total number of hours for courses with a fee code

FCRS Total number of courses for a fee code

BHRS Total number of hours for course with a bill fee code

BCRS Total number of courses with a bill fee code

Other Keywords The following list describes other keywords.

CODE Billing references the field value entered as literal text.

SAME


Billing uses this keyword when the break code or break units are the same as charge code or charge units. The code requires a blank field value.

SUBS Billing uses this keyword when the field contains a subsidiary code other than the main student receivables account code (usually S/A). The subsidiary must not include Subsidiary Balance and Subsidiary Total records.

UNIT Billing uses the value in the field as a numeric type.

Charge Table The Charge table (chg_table) calculates the actual dollar amount of a fee based on information in the Assessment table. A Charge table must exist for every Assessment table that references a charge code.

Following is an example of a Charge table. CHARGE TABLE Charge Code.[a ][b ] Session.....[d ] Program.....[c ] Year........[e ] Site........[c1 ] Subsession..[f ] ------------------------------ BREAK DEFINITIONS ------------------------------ Level Break Unit OR Break Code Description ----- ---------- ---------- ------------------------------------ #1 < [g ] [i ] [l ] #2 between #1 and #3 [j ] [m ] #3 > [h ] [k ] [n ] ------------------------------- FEE CALCULATIONS ------------------------------ Level Base Amt Rate Offset Step Minimum Maximum ----- -------- -------- ------- ------- -------- -------- #1 [o ] [p ] [q ] [r ] | [s ] [t ] #2 [ ] [ ] [ ] [ ] | [ ] [ ] #3 [ ] [ ] [ ] [ ] | [ ] [ ] Fees = Base + Rate * ((UNITS - Offset) / Step) rounded to nearest [u ]

Fields in the Charge Table The first three lines in the Charge table contain the fields that identify the charge code, program, and session for which the charge is to be calculated.

The following list describes the identification fields that appear in the Charge table.

Charge Code [a], [b] The charge code used for posting the charge. This code must have a corresponding entry in the Subsidiary Total table (subt_table). Use the untitled field to the right of the Charge Code field ([b]) to enter text that describes the charge code. This description is only used for reference purposes in the Charge table and is not the charge description that is printed on the SDS bill. The descriptions that are printed on the statements and the SDS bill come from the Subsidiary Total table (subt_table).

Program Session Site Subsession Year


[c-f] The academic program to which the charge applies and the session for which the charge is to be calculated. The billing program uses these fields to join information to the Assessment table.

Charge Table Break Definition Fields Each entry in the Charge Table can have a maximum of three methods for computing a charge based on the break codes or break units. Note that you cannot use break codes and break units at the same time within the same Charge table entry. Values in the Assessment Table determine whether break units or break codes are used.

The following list describes the break definition fields that appear in the Charge table.

Break Codes [i] [k] Codes that determine which charge level is to be used in calculating the fee. If no match exists, the system uses the last charge level. The system matches characters on a character-by-character basis except in the case of a wild card position, in which any character or series of characters can be substituted for the wild card character. You can define a wild card comparison in any of the Break Code fields in the Charge table by substituting an asterisk (*) for any character in the break code. For example, to charge all break codes beginning with the letter "M" using the same equation, you can define the break code in the Charge table as "M***."

Break Units [g] [h] Used if the Assessment table is using break units instead of break codes to determine the charge level. In this case, the system applies the first charge level if the break units established by the Assessment table are less than the first break unit value in the Charge record.

Note: • The system applies the second level if the break units in the Assessment table fall

between the first and second break unit values in the Charge table. • The system applies the last level when the break units in the Assessment table are

greater than the second break units value in the Charge table.

Description [l] [m] [n] Descriptive comments explaining how the system calculates the charge.

Charge Table Calculation Fields The system calculates charges or fees using the following formula that allows either a fixed amount calculation or a variable rate calculation:

Fees = Base + Rate * ((UNITS - Offset) / Step

Each of the variables in the equation, except for UNITS, are defined in the Charge table. The "UNITS" variable comes from the value determined by the Primary Charge Units field or the Secondary Charge Units field in the Assessment table.

The following list contains descriptions of the fee calculation fields that appear in the Charge table.

Base Amt [o] A fixed amount that is added to an optionally calculate rate.

Maximum


[s] A value that allows you to specify a maximum fee amount. If the value in this field is not zero, the calculated fee will not exceed the maximum amount.

Minimum [s] A value that allows you to specify a minimum charge amount. For any fee amount that Billing calculates, if the charge minimum is non-zero, the fee will not be less than the minimum value.

Offset [q] The number of units subtracted from the units specified at run time in the Charge table.

Rate [p] A variable amount that is based on the UNITS, less the amount in the Offset field, divided by the amount in the Step field.

Step [r] If the value in this field is zero, Billing defaults a value of one.

The following table contains some examples of how the formula for calculating a fixed amount or variable rate can be used to calculate a billing fee.

For a basic fee of $50.00 per student Fee = $50.00 + 0 * (UNITS -1 )/1

For a tuition charge of $100.00 per credit (UNITS) Fee = 0 + 100.00 * (UNITS - 0) / 1

For a tuition charge of $1000.00 plus $100.00 for every hour over 18 credits (UNITS) Fee = 1000.00 + 100.00 * (UNITS - 18) / 1

For a fee of $10.00 for every three credit hours Fee = 0 + 10.00 * (UNITS - 0) / 3

For a tuition charge of $1000 plus $300 for every three credits over 18 Fee = 1000 + 300 * (UNITS - 18) / 3

Note: This calculation is not used for every fraction of three credits because billing uses only whole number or integer values.

Refund Table (rfnd_table) The Refund table (rfnd_table) establishes a refund schedule for any charge to be refunded to a student. You must create the Refund table as well as the Assessment and Charge tables for each session, subsession, year, and program. The Refund table enables you to enter a refund schedule that lists refundable percentages that are valid for specific date ranges.

Specify a refund schedule for all assessment codes, even if a refund is not going to be granted. If a refund is not going to be granted, you can add a refund schedule with a refund percentage of zero and a refund date that is one day less than the beginning date of the billing session. (If the billing session begins on 08/15/1998, then the refund date equals 08/14/1998.) Charges are refunded at 100 percent regardless of the refund schedule used if the assessment charge units are not based on one of the accumulator keywords (e.g., RHRS, TCRS, FHRS).

Students marked as "no-shows" (where stuac_rec.reg_stat = "N") receive a 100 percent refund of all charges regardless of the information in the Assessment table for the refund schedule.

Classification Table The Classification table (cl_table) defines the various student classifications and determines which classifications are billed through the billing program. Set the Billing field to Y for any


classification that the billing program is to bill. Set the Billing field to N for any classifications that the billing program is not to bill. If any classification is not to billed by billing, set this field to N. Set the Billing field to N if it is easier or more efficient to manually charge students under any classification.

Subsidiary Total Table The Subsidiary Total Table (subt_table) defines the general ledger revenue account for every charge. Every code in the Charge table must have an equivalent Subsidiary Total table code.

A "Lost Tot" refers to any charge that the billing program posted at one time, but in a subsequent run, the billing program cannot justify why the charge was posted to a student's account. Think of a lost tot in terms of an "unlinked tot." In order for billing to calculate a charge, an Assessment and Charge table must exist for the charge. In addition, the Assessment table must allow the student to be charged a fee.

If at some time your institution changes an Assessment table, or the student no longer satisfies conditions within an Assessment table, the billing program cannot link information from the Assessment to the Charge table to calculate a fee. In this case, the once calculated charge becomes a lost or unlinked tot. In other words, based on current assessment information, the billing program cannot determine why the charge was ever posted. The billing program will refund the charge at 100 percent if the Lost Total flag (subt_table.lost) is set to "Y."

Entry table An entry with a code of "RFND" must be defined in the Entry table with a Subsidiary Post value of "PAY" that can be used by an "SA" journal, if one does not already exist.

Example Charge and Assessment Tables: Lab Fees The following is an example of how you can set up the Assessment and Charge tables for lab fees.

Your institution charges a computer lab fee of $30.00 for each course that has a fee code of "COMP." In addition, your institution uses the refund schedule "RFND" to calculate non-refundable amounts when students drop courses. Prior to registration, place the fee code in the Fee Code (sec_fee_code) field of the Section Record (sec_rec) table.

The billing program translates the assessment as follows. The billing program uses the charge code "COMP," and the charge units are the actual number of courses for which a student is registered with the fee code of "COMP." The break units are the same value as the charge units.

The charge level selected is the third level, because no matches exist for levels one and two. The fee is a rate of $30.00, multiplied by the charge units value.

Example Assessment and Charge Tables: Drop/Add Fees The following is an example of how you can set up the Assessment and Charge tables for drop/add fees:

Your institution charges students $10.00 to add or drop each course. The regent program maintains the database field used in the assessment that contains the number of added or dropped courses. This assessment does not use a refund schedule, because the charge units are not accumulator keywords. The system ignores any refund schedule specified and refunds the student at 100 percent. In this example, the charge code that calculates and posts the fee is "ADRP." The value in the stu_acad_rec field calculates the rate. If the value in this field is "0," there is no charge (10.00 * rate of 0 = 0).

Example Assessment and Charge Tables: Dorm Fees The following is an example of how you can set up the Assessment and Charge tables for dorm fees. Your institution sets up the dorm charge to use a Charge table with a charge code that


equals the dorm code. This method allows your institution to attach a separate fee to each dorm, with each dorm's fee in a unique total code for reporting purposes. In addition, the actual fee calculated depends on the number of students that can occupy the room.

The following example describes how one assessment can reference multiple Charge tables depending on a value in a database field.

In this example, the assessment code is not the same as the charge code. The link from the assessment to the charge is the code determined by the primary or secondary Charge table fields. In the Charge table for example, the "HOPE" dorm charges $500 for a double, $750 for a single room, and $800 for a room with three or more students. The occupancy is defined in the Facility table (facil_table).

When the billing program translates the assessment, billing attempts to locate a Student Services record (stu_serv_rec) for the "FA" session and the "191998" year. If the billing program cannot locate the record, or if the Dorm Identifier field is blank, then billing does not charge the student. The charge units and break units are based on the Maximum Occupancy field in the Facility table that corresponds to the dorm, campus, and building codes in the stu_serv_rec.

Example Assessment and Charge Tables: Tuition Charges The following example describes a tuition assessment that distinguishes between in-state and out-of-state fees. The example also shows how the Charge table break levels are used to calculate part-time and full-time fees.

For in-state students, tuition is $250 per credit hour for part-time students (students taking fewer than 12 hours), and $3300 for full-time students (students taking 12-18 hours). Students that carry over 18 credit hours are charged an additional $100 per hour over 18 hours. Out-of-state students are charged $400 per credit hour for full- or part-time students.

If the res_st field in the Profile record (profile_rec) contains the value "OH," billing uses the primary side to charge the student. If the Profile record cannot be found for a student or if the value in the res_st field does not equal "OH," billing uses the secondary side to charge the student. The primary side uses a charge code of "OTUI" and calculates the charge units as the total number of registered hours. The secondary side uses a charge code of "NTUI" and the charge units are also the total number of registered hours.

Example Assessment and Charge Tables: Meal Plan Charges In the following example, a meal plan charge is based on a full-time or part-time rate of $700.00 or $400.00. A field in the Student Services record (stu_serv_rec) containing the meal plan code determines the meal plan rate. If the meal plan code is not "F" or "P," billing does not charge the student.

The charge break level determines the meal plan type. The secondary break code references the stu_serv_rec and causes billing to locate the program and session in the stu_serv_rec and read the contents of the Meal Plan Identifier field (meal_plan_type). If billing cannot locate the stu_serv_rec, the student is not charged. The secondary charge unit must contain a valid value, even though it is not needed to calculate a rate in the Charge table. The "UNIT" code of 1 is ignored by the charge calculation because the rate is zero.

Example Assessment and Charge Tables: Course Audit Fees Audit fees are charged only for part-time students or for any non-resident student. The fee is $65.00 per course audited for resident part-time students, and $85.00 per course for any non-resident student.

In the assessment, the primary test is used to test for all students registered for fewer than 12.0 hours or students who are non-Ohio residents. If neither of these conditions are met, the secondary side is used by billing to charge the student. Since the secondary side does not have any information, no charge is calculated if the primary test conditions are not met. The charge units are the total number of audited courses, and the break code is the value in the Profile


record (profile_rec) for resident state. If there is no Profile record, the student is not charged an audit fee.

The Charge Table uses the break code levels to determine the fee amount. If the res_st field is blank, there is no charge; if the field contains an "OH," there is a $65.00 charge; and if the field is anything other than blank or "OH," there is an $85.00 fee. In the latter case, the code specified in the third break level is irrelevant because this value is always the default level when there is no match in the first or second level break codes.

Example Assessment and Charge Tables: Pre-Payment Credits Billing can automatically apply the balance of a subsidiary pre-payment-type account to the student's account. An example of this is a student who prepays a $150.00 payment, which is then automatically credited to the student's bill when charges are posted through the billing program.

This example describes how to set up the Charge and Assessment tables using a subsidiary code of "PRE." Note that the subsidiary code and the charge code must be the same value. Using this method, Billing credits the entire amount in the pre-payment subsidiary to the student accounts subsidiary and debit the pre-payment subsidiary to clear the balance for a student. If the "PRE" subsidiary balance is zero for any student, no credit can be applied to the student's account.

In the assessment, the secondary charge code file value is "SUBS." The charge code is the subsidiary code specified in the field, (e.g., "PRE"). The charge units are set to zero because there is no rate or amount specified for the charge. The billing program refunds the "PRE" subsidiary balance, because the charge fee calculation results in a zero fee.

Example Assessment and Charge Tables: holding accounts Non-student account subsidiaries can be used as holding accounts. For example, a graduation fee of $50.00 is required from all seniors. This fee is held until graduation. If students do not have $50.00 in the account, a charge is generated to bring the graduation subsidiary balance up to $50.00. If the graduation subsidiary balance is over $50.00, any amount over $50.00 is refunded to the student. For example, you can use a subsidiary code of "GRAD" in the Code field.

The assessment searches for students with a classification code of SR in the Program Enrollment record. If this record does not exist or the classification code is not SR, the student is refunded the balance in the GRAD subsidiary.


Evaluating and Implementing Special Student Billing Features

Introduction To implement some Student Billing features, you must ensure that certain values are established either in your institution’s macros/custom/financial file, Configuration table (config_table), or include/util/libbill file. Values in these system locations control the ability to use several general processing options and also define standard values (i.e., defaults) you want to use throughout Student Billing.

Macro Values Student Billing macros include:

“Display_ACCEL_DEGREE_CHARGES" If enabled, then all charges are displayed within Bursar, Test Billing, and Pre-Billing Proof report regardless of what will be effectively posted to the student accounts based upon the billing date within the Section record. This macro works in conjunction with the enabling of the Accelerated Degree feature within Student Billing.

“ENABLE_FEAT_CASHIER_AC" This macro has been included in the macros/custom/financial file to support future development and must be defined as delivered with the default of N.

"BILL_OLD_REFUND_TOT" This macro allows for modifications to Fee Collection to work more effectively with the bursar program. It must not have the same defined value as the BILL_REFUND_TOT macro, which is also located in the macros/custom/financial file. If your institution has previously defined the value of the macro BILL_REFUND_TOT to "RFND", change the default value of the BILL_OLD_REFUND_TOT macro to an unused code (e.g., “XXXX”). If, however, the value of BILL_REFUND_TOT is set to some other value, you can retain the delivered value of “RFND” for BILL_OLD_REFUND_TOT.

"CASH_REFUND_TYPE_SA2SR" This macro specifies the entry type to be used in the automated cash refunding portion of the Student Account to Student Refund program (sa2sr). This macro applies only to institutions using Fee Collection. An entry with a code of "RFND" must be defined in the Entry table with a Subsidiary Post value of "PAY" that can be used by an "SA" journal, if one does not already exist.

Configuration Table Entries Student Billing features controlled through Configuration tables include:

• Distribution of posted financial aid (not awarded) • Production of consolidated statements • Computation of total amounts due before issuing refunds

Table Entries Relating to the Distribution of Financial Aid by Fee Collection The following Configuration table entries relate to the interaction between Financial Aid and Student Billing:

IF_FINAID_POSTED If set to “Y”, causes the Fee Collection component of Student Billing to distribute financial aid only after aid has been posted. If your Configuration table does not contain this entry, or if set to “N”, Fee Collection will distribute financial aid even if it is not posted. This table entry works in conjunction with ENABLE_EXACT_POST_AID.

ENABLE_EXACT_POST_AID


If set to “Y”, causes Fee Collection to distribute the exact amount of only the financial aid that has been posted. This feature is relevant when the student’s financial aid award has been adjusted. (See the Example of Configuration Table values in Implementing Fee Collection.) Fee Collection uses this Configuration table entry only if the IF_FINAID_POSTED value is “Y”.

Table Entries Relating to Consolidated Statements The following Configuration table entries relate to producing consolidated financial statements:

ENABLE_MULTI_STMT_SUBS If set to “Y”, causes the Statement Parameters screen (or window) to include an option for producing statements for multiple subsidiaries. For example, if your institution maintains tuition charges in the Student Accounts subsidiary, and dining hall charges in the Housing and Board subsidiary, you can use this feature to produce a statement showing both types of charges. If set to “N”, the Statement Parameters screen will not include an option for consolidated statements.

MULTI_STMT_SUBS Defines all the subsidiaries you want to consolidate on statements (e.g., Student Accounts and Housing and Board). The Statement program uses this Configuration table entry only if the ENABLE_MULTI_STMT_SUBS value is “Y”.

MULTI_STMT_SUBS_TXT Required if ENABLE_MULTI_STMT_SUBS is set to Y, contains the text or title you want to display on student statements.

Table Entries Relating to Financial Aid Refunding using Multiple Subsidiaries The following Configuration table entries relate to processing refunds through multiple subsidiaries:

ENABLE_NET_CHECKS If set to “Y”, causes net check processing, in which all bal_act amounts in each of the students’ Subsidiary Account records (suba_rec) are accumulated and compared to the amount of refundable financial aid. By enabling this feature, you ensure students do not receive refunds when they have outstanding balances in any subsidiary. The Student Accounts to Student Refund program within Fee Collection uses this Configuration table entry.

NET_CHARGE_SUBS Defines all the subsidiary balances you want to consider before issuing a financial aid refund to a student (e.g., Student Accounts and Housing and Board). The Student Accounts to Student Refund program uses this Configuration table entry only if the ENABLE_NET_CHECKS value is “Y”.

Include Relating to Display of Pending Financial Aid on Statements The following include controls the amount of pending financial aid displayed on a student's statement:

DISPLAY_AMT_LIMIT Defines the percentage amount of pending financial aid to show on a student's statement. For example, if your institution charges 3% as an administrative fee for processing a Pell grant and a student receives a $1000 grant, the amount the student actually receives is $970. To ensure the student's statement shows $970 in aid instead of the original $1000 amount, set this include to .97. The default for this value is 1.0. To enact a change to this include, check out the include file, make the change, reinstall the include file, reinstall src/Lib/libbill, and then reinstall all the programs that use libbill. In the standard CARS Solution, the programs to reinstall are:

• acctspay • acquery


• approval • batchfee • bursar • cashier • defrec • dsplstmt • faentry • faneed • feetest • forment • invdef • massinv • purchase • recurent • regent • requisition • sa2sr • sdsbatch • stmt • stmtid


Calculating Interest on Subsidiary Accounts

Introduction The billing program contains an interest calculation mode that allows you to post interest charges to any type of subsidiary account. The information on these pages describes the various interest calculation methods available and the tables necessary to generate interest charges.

Prerequisites Complete the following tasks before you calculate interest on subsidiary accounts:

• Ensure that your institution has implemented the CARS Solution General Ledger module. • Automatically or manually post the previous balances or charges to the subsidiary

account(s) on which you want to charge interest.

Student Billing Charges vs. Interest Charges Following are the differences between running Student Billing for student billing charges and running Student Billing for interest charges.

• You can rerun student billing posting, but you cannot rerun interest posting. • If an error occurs that terminates the interest posting before the posting is complete, or if an

error exists in the interest amounts that are being posted, terminate the journal used to post the interest charges. After you terminate the journal, correct the error and rerun the interest posting process.

• You can waive interest on any individual's subsidiary account or on any Subsidiary Balance record (subb_rec). The Subsidiary Account record (suba_rec) contains an Interest Waived field (suba_int_wvd). Setting this field to "Y" allows you to waive the interest on an entire account balance.

• In addition, if you want to waive interest on any transactions posted to a specific Subsidiary Balance record, set the Interest Waived field (subb_int_wvd) in this record to "Y." If you want to waive interest globally on Subsidiary Balance records with a certain balance code (subb_code), set the Interest Waived field (tsubb_int_wvd) in the Subsidiary Balance table to "Y."

Tables Used for Interest Calculations The following table contains descriptions of each of the tables that you must set up to define the parameters for calculating interest.

Billing Parameters Contains the interest parameters and defines the dates used to calculate account balances and to define the necessary posting information.

Assessment Defines the interest calculation method used to calculate account balances for individuals.

Note: Although the Assessment table for student billing allows data to be used in other student records, the interest posting only allows information from the ID record (id_rec) and the Subsidiary Account record (suba_rec) to be used in the Assessment table.

Charge Defines how to calculate the charge based on the account balance determined by the information in the Assessment table.

Note: When you set up the Charge table, use blank program and subsession codes. Also, use session and year codes that match the session and year codes in the Assessment and Billing Parameters tables.

Subsidiary Total


Contains entries for subsidiaries that use Subsidiary Balance and Subsidiary Total records.

Note: Use the Subsidiary Total and the Subsidiary Association tables only if the subsidiary uses Subsidiary Balance and Subsidiary Total records.

Subsidiary Association Contains entries for subsidiaries that use Subsidiary Balance and Subsidiary Total records.

Note: Use the Subsidiary Total and the Subsidiary Association tables only if the subsidiary uses Subsidiary Balance and Subsidiary Total records.

Types of Interest Calculation Methods The Billing program calculates interest for any subsidiary using one of the following methods:

• Balance Type (BALS) calculations • Invoice Type (INV) calculations

Each of these methods allows the billing program to determine an account balance for a specified date by checking when the entry for the journal dates was posted, or by checking invoice due dates. Once the billing program determines the balance, it calculates the interest charge according to the information in the Charge table.

Balance Type Calculations The balance type of interest calculations is used for subsidiaries that are not invoice-mode subsidiaries (where tsubs_mode = "S"). The "S" mode indicates a standard non-invoice, and the "I" mode indicates an invoice. This method determines account balances as of any given date by looking at the journal dates on which the billing program posted subsidiary entries.

Within the balance type method, four types of interest calculation methods are available. There are three variations to each of these methods. The first variation calculates the balance based on the subsidiary account balance. The other two variations calculate the balance based on transactions posted to Subsidiary Balance records.

The following list describes each of the four interest methods.

Beginning balance Calculates the balance as of a given beginning date.

Ending balance Calculates the balance as of a given ending date.

Average daily balance Calculates a weighted daily balance based on the dates on which entries were posted between a beginning and ending date.

Balance minus credits Calculates the balance on a given beginning date and subtracts all credits posted between a given beginning and ending date.

Sample Data Used The following lists the sample data used in the pages that follow to describe each of the balance type methods.

Beginning date 09/01/1998

Ending date 09/30/1998

Interest rate 1%

The following lists the transaction information used in the pages that follow to describe each of the balance type methods.


06/01/1998 100.00 100.00 charged

08/18/1998 230.00 130.00 charged

09/16/1998 270.00 40.00 charged

09/26/1998 180.00 90.00 cash payment credit

10/05/1998 120.00 60.00 cash payment credit

Beginning and Ending Balance Methods The beginning balance and ending balance methods calculate a balance based on the sum of transactions posted as of a specified date. The beginning balance method uses the Beginning Date field (pbill_beg_date) in the Billing Parameters record to determine the balance for interest calculations. The ending balance method uses the Ending Date field (pbill_end_date) in the Billing Parameters record. These two methods are identical except for different date fields in the Billing Parameters record.

The following list contains an example interest calculation for both the beginning and ending balance methods using the sample data (see Sample data used for each balance type method in this section).

Beginning Balance Ending Balance Balance date 09/01/1998 09/30/1998Account balance interest rate

230.00x 0.01

$180.00x 0.01

Interest charge $2.30 $1.80

Codes Beginning and Ending Balance The following list describes valid beginning and ending balance method codes for the Assessment table.

AAB Account Beginning Balance for all sessions. ABB is the calculated account balance based on adding subsidiary transactions posted prior to the date in the Beginning Date field.

CBB Current Beginning Balance for the current session only. CBB is the balance for a designated current period or session, excluding all transactions posted to other periods or sessions. For example, use this method to charge interest only on the outstanding balance posted to the FA1998 session. The system determines the calculated balance by adding all transactions posted to the designated subsidiary balance prior to the date in the Beginning Date field. The Interest Bal Code (pbill_int_bal_code) and the Interest Bal Period (pbill_int_bal_prd) fields must contain the subsidiary balance that is to be charged interest. The system ignores all transactions posted to other Subsidiary Balance records prior to the date in the Beginning Date field.

PBB Previous Beginning Balance that excludes the current session. PBB is the previous balance of an account that excludes all transactions posted to the designated subsidiary balance.


The values in the Interest Bal Period and the Interest Bal Code fields identify the transactions posted to the designated subsidiary balance. The calculated balance is based on the sum of all transactions posted prior to the date in the Beginning Date field to any Subsidiary Balance record other than the one identified in the Interest Bal Code and Interest Bal Period fields. The system ignores transactions posted to the designated subsidiary balance.

AEB Account Ending Balance for all sessions. AEB is the calculated account balance based on adding subsidiary transactions that were posted prior to the date in the Ending Date field.

CEB Current Ending Balance for the current session only. CEB is the balance for a designated current period or session that excludes all transactions posted to other periods or sessions. For example, use this method to charge interest only on the outstanding balance posted to the FA1998 session. The system determines the calculated balance by adding all transactions posted to the designated subsidiary balance prior to the date in the Ending Date field. The Interest Bal Code (pbill_int_bal_code) and the Interest Bal Period (pbill_int_bal_prd) fields must contain the subsidiary balance that is to be charged interest. The system ignores all transactions posted to other Subsidiary Balance records prior to the date in the Ending Date field.

PEB Previous Ending Balance that excludes the current session. PEB is the previous balance of an account that excludes all transactions posted to the designated subsidiary balance. The values in the Interest Bal Period and the Interest Bal Code fields identify the transactions posted to the designated subsidiary balance. The calculated balance is based on the sum of all transactions posted prior to the date in the Ending Date field to any Subsidiary Balance record other than the one identified in the Interest Bal Code and Interest Bal Period fields. The system ignores transactions posted to the designated subsidiary balance.

Average Daily Balance Method The average daily balance method calculates the interest charge based on the sum of weighted balances. The system calculates the weighted balances for each day it posts a transaction between a beginning and an ending date.

The following lists and describes the process by which the system calculates an account balance using the average daily balance method.

1. Count the number of days between the beginning and ending dates.

2. Determine the balance of the account on the beginning date and on each day that the system posts a transaction between the beginning and ending dates.

Note: Calculate the number of days between each transaction date and the beginning date for each balance calculated in phase 2, and divide each number of days by the total number of days in the period. This phase provides a weight factor for each balance calculated in phase 2.

3. Multiply each balance calculated in phase 2 by the weight factor determined in phase 2 to obtain the weighted balance.

4. Add the weighted balances calculated in phase 4 to obtain the balance on which interest is to be charged.

Example of the Average Daily Balance Method The following table contains an example interest calculation for the average daily balance method using the sample data (see Sample data used for each balance type method in this section).

Dates Balance Days Weight Weighted balance

09/01/1998 - $230.00 15 0.500 $115.00


09/18/1998 09/16/1998 - 09/29/1998

$270.00 10 0.333 $89.91

09/26/1998 - 09/30/1998

$180.00 5 0.167 $30.06

30 1.000 $234.94 Interest Charge = $234.97 x 0.01 = $2.35

Assessment Table Codes for the Average Daily Balance Method The following list contains descriptions of the codes that you can use in the Assessment table for each of the variations of the average daily balance method. Each formula calculates the average daily balance based on transactions posted between the dates in the Beginning and Ending Date fields of the Billing Parameters record.

AADB Account Average Daily Balance. The system uses all transactions posted to the subsidiary account to calculate the average daily balance.

CADB Current Average Daily Balance. The system calculates the average daily balance using transactions posted to a current subsidiary balance. The Interest Bal Code and the Interest Bal Period fields in the Billing Parameters record identify the transactions posted to a current subsidiary balance.

PADB Previous Average Daily Balance. The system calculates the interest based on a balance posted to previous balances. The system uses all transactions posted to any subsidiary balance other than the one identified in the Interest Bal Code and Interest Bal Period fields.

Balance Minus Credits Method The balance minus credits method determines a balance for charging interest by taking the balance as of a beginning date and subtracting any credits made between the beginning and ending date.

The following table contains an example interest calculation for the balance minus credits method using the sample data.

Component Sample value Beginning balance as of 09/01/1998 Total credits posted through 09/30/1998

$230.00-90.00

Balance Interest rate

$140.00x 0.01

Interest charge $1.40

Codes: the Balance Minus Credits Method The following list contains descriptions of the codes that you can use in the Assessment table for the balance minus credits method.

ABMC Account Balance Minus Credits. The system obtains the account balance by adding all of the transactions posted prior to the beginning date, then subtracting all credit transactions posted between the beginning and ending dates.

CBMC Current Balance Minus Credits. The system calculates this balance by using transactions posted to a current subsidiary balance. The Interest Bal Code and the Interest Bal Period


fields identify the transactions posted to a current subsidiary balance. The system ignores all transactions not posted to the subsidiary balance.

PBMC Previous Balance Minus Credits. The system calculates a previous balance minus credits balance based on all transactions posted to any subsidiary balances other than the one designated in the Interest Cal Code and Interest Bal Period fields.

Invoice Type Calculations Invoice-mode subsidiaries, in which tsubs_mode = "I," use sequential Subsidiary Balance or Invoice records and do not use Subsidiary Total records. The only method available on these type of subsidiaries is the SUM method. The SUM method represents the summary total of all invoices due before the due date. This method looks at invoice due dates rather than transactions. The SUM method obtains the account balance on which interest is charged by adding together all invoices due before a beginning date.

The following lists all of the invoices that an individual has on the individual's account. The invoice number is bolded with the amount and due date listed directly below..

0001 0.00 06/30/1998

0002 750.00 06/30/1998

0003 -45.00 07/30/1998

0004 0.00 07/15/1998

0005 10.00 08/30/1998

0006 340.00 09/15/1998

The following example shows that an individual will be charged interest at the rate of 1.5% on all invoices past due as of 09/01/1998.

Sum of all invoices due before 09/01/1998 $715.00

Interest rate 0.015

Interest charge $10.73

How to Run the Interest Program The following lists the steps to follow for running the Interest program.

CAUTION: Use "INT" as the billing code in the Interest Parameter record so that the system will not double charges and aid.

1. Set up or modify the following Student Accounts/ Billing tables as needed: • Assessment • Charge


• Interest Parameters • Subsidiary Total • Subsidiary Association

2. Is your institution running monthly interest? • If yes, update the Beginning and Ending Date fields in the Interest Parameters screen

and go to step 3. • If no, go to step 3.

3. Verify that the codes in the Session, Year, and Bal Period fields are correct.

Note: Also verify that the code in the Interest Bal Period field is correct, if your institution uses this field.

4. Define the Interest Waived flag in the Subsidiary Account record by selecting Subsidiary Account Record from the Student Accounts/Billing: Interest menu and setting the Interest Waived flag to "Y" on the individuals for whom the system should not compute or charge interest.

Note: You can also enter a "Y" in the Waive Int field to the Subsidiary Balance Table screen to turn off interest for a particular balance code for every individual in that subsidiary.

5. Verify the Interest Waived flag in records by performing the following tasks: • Access the Fiscal Management: Main Menu. • Select Accounting. • Select Reports Menu. • Select Subsidiary Menu. • Select S/L Account Balances and run this report; enter a "Y" when the system

prompts you with the subsidiary information question.

6. Test interest charges on a few individuals prior to posting by selecting Test Interest Charges from the Student Accounts/Billing: Interest menu to randomly test interest charges.

7. Verify interest charges on all individuals prior to posting. Select Pre-Interest Proof Report from the Student Accounts/Billing: Interest menu to verify interest charges and run this report in the background mode.

8. Post the interest charges. • If the interest test and verification are correct, select Post Interest Charges from the

Student Accounts/Billing: Interest menu to calculate and post charges creating an SB journal. After the process is finished, the system sends you electronic mail indicating that the process is finished and providing you with the journal code (SB) and number. Write down the journal code and number.

• The Interest program charges additional interest charges each time you run the program. Unlike the Billing program, you cannot rerun the Interest program. If the charges are incorrect the first time and you want to correct the tables or records and rerun the Interest program, terminate the first SB journal. Select Terminate A Journal from the Accounting: Journal Maintenance menu to terminate the first SB journal. The system voids all the entries, but does not remove the entries.

9. Run the following SB Journal reports: • General Ledger report (contains information on transactions posted to general

ledger accounts) • Subsidiary Ledger report (contains information on transactions posted to subsidiary

ledger accounts by ID)

Note: This step is optional.

10. Verify interest posting by using S/L Account Query or Bursar Query to select a student ID for which the system posted interest. Go to the statement level, detail level, or total level to view an entry or transaction for interest.

Note: This step is optional.


Calculating Minimum Payment

Introduction When your institution sets up the deferred payment tables, you should know exactly how Statement computes minimum payments. The information on the following pages explains the calculations that Statement computes for minimum payments, past amounts, and current amounts due.

The Deferred Payment Table The Deferred Payment table (defpay_table) and the Payment Terms table (pay_term_table) control the computation of deferred payments for any given subsidiary balance. For example, if the DEFER field in the Payment Terms table contains the code "INCR," that value refers to the entries in the Deferred Payment table that control the computations of deferred payment plans.

Sample Data Used for Deferred Payment Table The following table lists sample entries in the Deferred Payment table. Refer to this data for the Deferred Payment table examples on the following pages.

tdefpay_tbcode tdefpay_mo tdefpay_day tdefpay_pct tdefpay_min tdefpay_inc -------------- ---------- ----------- ----------- ----------- ----------- 1. INCR -1 0 25 $25.00 $10.00 2. INCR 1 31 50 $25.00 $10.00 3. INCR 2 31 75 $25.00 $10.00 4. INCR 3 31 100 $0.00 $0.00 5. INCR 4 31 100 $0.00 $0.00

The first entry with the payment month value of -1 and the payment day value of 0 produces a minimum payment of 25 percent on the subbalance due date (subb_due_date). (Subbalance is a session balance.)

Entries 2, 3, and 4 have higher payment percentages due on the last day of the next three months. The entire balance is due on the last day of the third month. Note that the values for the Minimum Payment field (tdefpay_min) and the Minimum Left on Account (tdefpay_inc) field are 0 for the fourth Deferred Payment table entry. The values in these fields are irrelevant because 100 percent of the balance is due at that time.

The last entry in the Deferred Payment table determines when the Statement program considers the total amount past due. Without the last entry, Statement does not know when to move the last 25 percent of the balance due from the status of "current due" to "past due."

Statement uses the program run date instead of the statement end date to determine the minimum payment due. For example, you run the Statement program on 10/05/1998 with a statement beginning date of 09/01/1998 and a statement ending date of 09/30/1998. Any charges, credits, or financial aid to that individual's account from 10/01/1998 to 10/05/1998 do not appear on the statement, but are considered when computing the minimum payment.

The minimum payment computations cannot easily compute a mix of balances made up of balances without minimum payment plans and balances with minimum payment plans. The system adds the outstanding balance from any non-minimum payment balance to the past due amount for those sessions that have a minimum payment plan.

Month and Day Example Assume that the subbalance due date (subb_due_date) is 08/30/1998, the first day of the Fall session. Students register for the Fall courses, and the system automatically adds their Fall balances with the 8/30/1998 due date. The first entry in the Deferred Payment table produces a statement showing that 25 percent of the balance is due on 08/30/1998.


In the sample Deferred Payment table, the special month code of -1 in the Payment Month field (tdefpay_mo) indicates the number of days until the session balance due date. The days value of 0 in the Payment Day field (tdefpay_day) indicates the session balance due date.

The second entry in the Deferred Payment table becomes effective on 09/30/1998. On this date, 50 percent of the balance is due, and the bill is considered to be past due if the student has not paid the first 25 percent of the bill. On 10/31/1998, 75 percent of the balance is due (with the first 50 percent being past due if it has not already been paid). The rest of the balance (100 percent) is due on 10/30/1998. Any amount that the student owes on 12/31/1998 becomes past due.

Formulas for Computing the Minimum Payment The minimum payment computations use two table entries. The first table entry matches the current date and computes the minimum payment. The second table entry immediately precedes the entry used to compute the minimum payment. The second table entry computes the portion of the balance that is past due.

The following list describes how the minimum payment computations work.

1. Computes the minimum amount due based on the following percentage:

2. Due = ((Charges - Financial Aid) * % from table) - Payments Checks the minimum payment due using the following information: If the minimum payment due is less than or equal to the minimum payment from the table, then the minimum payment due equals the minimum payment.

Note: If payments result in a credit balance in step 1, no payment is due, and the credit amount is applied to other sessions.

3. Performs an incremental check using the following formula: If ((Charges - Financial Aid - Payments) - Amount Due) <= Increment value, then the amount due = Charges - Financial Aid - Payments

Examples of Calculations The following lists each symbol and its corresponding explanation for use in the examples below.

BF Balance forward from the previous month

MO Activity in current month

C Charges

P Payments

F Financial aid posted

Examples of Calculations Note: With the terms of payment, both the SP98 and FA98 balance periods use a DEFER

code that is linked to the INCR code in the Deferred Payment table. The payment due date for each balance period is as follows:

• SP98 - 01/05/1998 • FA98 - 08/30/1998

The following table lists all of the transactions that an institution makes to a student's account from July to October 1998. July. Aug. Sept. Oct.

---------------------------------------------------------------------------

| BF MO | BF MO | BF MO | BF MO


| | | |

C | 200 a | 200 b | |

| | | |

SP98 P | | -200 b | |

| | | |

F | | | |

| | | |

---------------------------------------------------------------------------

| | | |

C | | 0 2000 b | 2000 c 200 c | 2200 d

| | | |

FA98 P | | 0 -300 b | -300 c 0 c | -300 d -725d d

| | | |

F | -100 a | -100 b -50 b | -150 c 0 | -150 d

| | | |

| | | |

The above example covers two balance periods. In the first period, SP98, the student had a previous balance of $200, and the student eventually paid off this balance in July. In the second period, FA98, the institution credited $100 in financial aid to the student's account in July. Charges totaling $2000 were added in August. Payments totaling $300 and financial aid of $50 were also credited to the student's account in August. In September, the institution added another $200 in charges to the student's account and in October the student made a $725 payment. The table does not show any information for November, because there was no activity to the account

The following examples (a-e) show the minimum payment calculation, past due minimum payment calculation, and statement ending balance for each statement from July to November 1998.

July Statement: July 31, 1998

Minimum payment calculation:

SP98 - Formula 1: ((200 - 0) * 100.00%) - 0 = 200

Formula 2: Is (200 <= 25)? Due = 200

Formula 3: Is ((200 - 0 - 0) - 200) <= 10)? Due = 200

FA98 - Formula 1: ((0 - 100) * 0.00%) - 0 = 0

Past due minimum payment calculation:

SP98 - Formula 1: ((200 - 0) * 100.00%) - 0 = 200

Formula 2: Is (200 <= 25)? Past Due = 200

Formula 3: Is ((200 - 0 - 0) - 200) <= 10)? Past Due = 200

FA98 - Formula 1: ((0 - 100) * 0.00%) - 0 = 0

Examples of Calculations Statement ending balance would show 100.00 dr

Past due Current due Minimum payment

200.00 0.00 200.00

Note that although the ending balance gives the student only a $100 debit, the student still owes $200 on the previous balance. The financial aid the student received in July cannot be credited toward the Spring balance, and the entire Spring balance is considered past due.

August statement: August 31, 1998



SP98 - Formula 1: ((200 - 0) * 100.00%) - 200 = 0

FA98 - Formula 1: ((2000 - 150) * 25.00%) - 300 = 162.50

Formula 2: Is (162.50 <= 25)? B = 162.50

Formula 3: Is ((2000 - 150 - 300) - 162.50) <= 10)? A = 162.50


SP98 - Formula 1: ((200 - 0) * 100.00%) - 200 = 0

FA98 - Formula 1: ((2000 - 150) * 0.00%) - 300 = 0

Statement ending balance would show 1550.00 dr


0.00 162.50 162.50

Note that although there is a debit balance of $1550, the student only owes the minimum payment of $162.50.

September statement: September 30, 1998


FA98 - Formula 1: ((2200 - 150) * 50.00%) - 300 = 725.00

Formula 2: Is (725.00 <= 25)? B = 725.00

Formula 3: Is ((2200 - 150 - 300) - 725.00) <= 10)? A = 725.00


FA98 - Formula 1: ((2200 - 150) * 25.00%) - 300 = 212.50

Formula 2: Is (212.50 <= 25)? B = 212.50

Formula 3: Is ((2200 - 150 - 300) - 212.50) <= 10)? A = 212.50



212.50 512.50 725.00

Note that the past due amount was increased by $50, due to additional charges totaling $200 in September. The minimum payment calculations do not consider when your institution adds a charge to the account. All charges made to the account for a given period are due as of the due date for that balance period, regardless of the date the charges were actually added to the account. Although the institution added the $200 charge sometime in September, the calculations still use the August 31 date for computing the minimum payment.

Examples of Calculations October statement: October 31, 1998


FA98 - Formula 1: ((2200 - 150) * 75.00%) - 1025 = 512.50

Formula 2: Is (512.50 <= 25)? B = 512.50

Formula 3: Is ((2200 - 150 - 1025) - 512.50) <= 10)? A = 512.50


FA98 - Formula 1: ((2200 - 150) * 50.00%) - 1025 = 0




0.00 512.50 512.50

The payments made in October paid the past due payment and the September amounts in full.

November statement: November 30, 1998 (No transactions in this month)


FA98 - Formula 1: ((2200 - 150) * 100.00%) - 1025 = 1025.00

Formula 2: Is (1025.00 <= 25)? B = 1025.00

Formula 3: Is ((2200 - 150 - 1025) - 1025.00) <= 10)? A = 1025.00


FA98 - Formula 1: ((2200 - 150) * 75.00%) - 1025 = 512.50

Formula 2: Is (512.50 <= 25)? B = 512.50

Formula 3: Is ((2200 - 150 - 1025) - 512.50) <= 10)? A = 512.50



512.50 512.50 1025.00


Running the Billing Program From the Shell

Introduction The information on the following pages describes the modes of operation for running the billing program either interactively or in batch.

Use the billing program to perform the following tasks: • Test the Assessment and Charge tables for correct billing information using individual

student IDs • Include student billing charges on the student data sheet (SDS) produced by Registration • Verify billing charges that will be posted for all students, prior to posting • Post charges to student accounts • Provide information that is displayed within the bursar program

Prerequisites Your institution must have already set up certain Student Billing tables before you can use billing.

Parameters The billing program can operate in several modes, depending on how you combine parameters. The remaining information in this section explains how to use the parameters for each operational mode.

In any of the parameter combinations described below, generating interest or student billing charges depends on the value of the billing code in the Billing Parameters record.

The billing program calculates interest charges if either of the following conditions is true: • The billing code is "INT." • Any of the values defined in the macro "INT_BILL_CODES" in the macro file located in the

directory path CARSPATH/include/custom/billing are "INT."

If neither of these conditions is true, the system uses student billing charges as the default.

Interactive Mode To run the billing program interactively, use the run code parameter "-r" followed by a valid billing parameter run code. Following is the format and an example for using the "-r" parameter.

Format: billing -r code

Example: billing -r INT

Verify Report Mode The billing program can produce a charge verification report listing student charges and any posting adjustments that are to be made when charges are posted. The following table contains the steps to follow for accessing the Pre-Billing Proof report.

1. Access the Fiscal Management: Main Menu.

2. Select Student Account/Billing from the Fiscal Management: Main Menu.

3. Select Post Billing Charges Menu.

4. Select Pre-Billing Proof Report.

Verify Report Mode The following list contains descriptions of the required parameters for using the verify report mode from the shell.

-r runcode


Specifies the billing session (e.g., SP98).

-v Turns on the verification report mode.

-o output Sends the output to either a file or a printer and must be followed by one of the following: a valid printer name, the word “file,” or an optional name of a file.

The following list contains the command lines you should enter for sending the output file to each of three locations.

Send output to printer “lpr” billing -r code -v -o lpr

Send the output to a default filename called “code out” in your home directory billing -r code -v -o file

Send the output to a file called “myname.code” in your home directory billing -r code -v -o myname

Post Charges Mode or Execute Mode The following list contains descriptions of the parameters for using the post charges mode or the execute mode from the shell.

-r runcode

-e Use this required parameter to generate transactions for posting charges to student accounts. When you use these parameters, billing posts transactions directly through the bgvoucher program to the subsidiary identified in the Billing Parameters record. Following is the format and an example for using the "-r" and "-e" parameters to post charges. Format: billing -r code -e Example: billing -r SP1998 -i 16304 -e

-i Use this parameter followed by one ID number to instruct billing to either post charges or print a verify report for one individual (e.g., one specific ID number).

-d Use this parameter followed by a date to specify at run time an optional journal posting date. This allows the system to post charges to a selected journal posting date rather than using the system date as the default journal posting date. Following is the format for using the "-d" parameter. Format: billing -r code -e -m -B -d date

Process-to-Process (PTP) Modes The regent and bursar programs specify at run time additional parameters to billing because both of these programs use billing.

CAUTION: Do not run billing using any of the parameters in the following table unless the regent or bursar programs are running the billing program.

The following list contains the parameters that you can use to run billing from the regent and bursar programs.

-r session Session code (e.g., FA98).

-y year Year code (e.g., 1998).

-p program


Academic program (e.g., UNDG).

-c bill code Bill code (e.g., SB).

-b Bursar mode activation code.

-g Debug code.

Optional Parameters You can use the "-a" parameter followed by a date in any mode to cause billing to ignore any course adds or drops after the specified date. For instance, the "-a" parameter is useful when you want to generate charges within a session for certain date ranges. The billing program normally calculates charges based on all add and drops within a session regardless of the add/drop dates.

Compilation Values The billing program uses several compile time options that are defined in the following files:

• $CARSPATH/include/custom/billing • $CARSPATH/include/custom/bursar

Both files contain further information on the options available. Reinstall the billing program source if you make any change to either of these two files.

Program Flow The following processing flow shows the logic billing uses to determine the amount of the charge when calculating student billing charges.

1. The billing program loads data for each student from the following records: • Coursework record (cw_rec) • ID record (id_rec) • Profile record (profile_rec) • Program Enrollment record (prog_enr_rec) • Registration record (reg_rec) • Student Billing Custom records (sbcust_rec) • Student Services record (stu_serv_rec) • Subsidiary Account record (suba_rec) • Subsidiary Balance record (subb_rec) • Subsidiary Total record (subt_rec)

Note: A student must have a Program Enrollment record, a Student Academic record, and an ID record for the academic program and session being billed in order for the system to calculate charges.

2. Based on information in the Charge, Assessment, and Refund tables, billing uses the student's data to calculate charges and refunds.

Note: For more information on how to interpret the Assessment and Charge tables, see Setting Up Student Accounts/Billing Tables in this guide.

3. Once calculations are complete, billing compares the charge calculations (displayed in the Fees field on the Test screen) to any posted amount in the Subsidiary Total record (subt_rec). The billing program creates transactions that, when posted, cause the amount in the Subsidiary Total record to equal the charge calculated by billing. For example, if a student was previously charged $25.00 for an activity fee, and billing calculates a new fee amount of $30.00, the system creates a transaction for the additional $5.00. Once the system posts the $5.00, the system adds the $5.00 to the $25.00 balance in the Subtotal record (subt_rec) for the activity fee, resulting in a $30.00 balance.


4. After billing has processed all the information in the Assessment tables for the session and program being billed, any posted charges for which billing could not find a link from the Assessment table to the Charge table can be refunded based on values in the Lost and Post fields.

If the value in the Post field is "B," billing refunds the charge at 100%, or uses the Refund table, if applicable, unless the value in the Lost field is "N." An "N" in the Lost field indicates no refunding on a lost total code. (These leftover charges are called "lost" or "unlinked" totals.) A "Y" in the Lost field indicates to refund the charge if the charge can no longer be supported by other data elements.


Using Reports and Audits to Review a Billing Period

Introduction Using reports and the CARS Solution Audit programs, the bursar or controller at your institution can reconcile student data with the amounts charged and paid in a session. Information from registration, student services, and accounting reports provides your institution with the necessary information to reconcile student data with accounting dollars.

Note: For details about the reports generated from Student Billing, see ACE Reports in this manual.

Accounting Subsidiary Ledger Audits Run the CARS Solution Subsidiary Ledger (S/L) Audit programs at least once each quarter before you run the subsidiary reports. Running these programs verifies that the Subsidiary Total records are reconciled with the general ledger accounts.

The following lists the steps to follow for accessing the Subsidiary Ledger audits.

1. Access the Fiscal Management: Accounting Main Menu.

2. Select G/L Maintenance Menu.

3. Select Audit Menu.

4. Select S/L Report and Update and run the report.

5. Select G/L Control Account Report and run the report.

6. Review the output file and read your electronic mail to determine if any problems exist.

Student Billing and Accounting Reports Use the Student Billing and Accounting reports to perform the following tasks:

• Verify total dollars by session for specific charges • Reconcile the total dollars to general ledger amounts and to other student counts and

information provided by other offices at your institution

The following lists the steps to lists to run a summary report providing numerical information on registration and housing.


2. Select Student Accounts/Billing.

3. Select Student Billing Menu.

4. Select Print Student Information.

Repeat the first two steps in the above table and select Reports Menu from the Fiscal Management: Student Accounts/Billing Main Menu. This menu contains several reports that you can access by entry, transactions, or total codes. These reports provide information about any or all charges or payments to student accounts, whether through the Cashier program, automated billing posting, or manual adjustments. Use the subsidiary ledger reports to assist you with verifying and supporting accounting dollars.

If you think the automated billing charges reported are incorrect, review the Assessment and Charge table entries. Also, use the steps in the following list to verify randomly that your institution is billing students correctly.



3. Select Student Billing Menu.


4. Select Test Billing Charges to verify that your institution is billing students correctly.

Note: You may need to correct the Assessment and Charge tables and select Post Billing Charges again. Use the information in the following tables to select Post Billing Charges.

The following lists the steps to follow for selecting Post Billing Charges.



3. Select Post Billing Charges Menu.

4. Select Post Billing Charges.

Registration Reports To access the registration reports, go to the Student Management Main Menu and select Registrar, then select Reports to access the Registrar: Reports Menu. The reports on the Registrar: Reports Menu contain additional registration data. If this menu is not available to you, contact the Registrar's office for copies of these reports. These reports contain information from the following records:

• Registration record (reg_rec) • Course record (crs_rec) • Section record (sec_rec) • Student Academic record (stu_acad_rec) • Program Enrollment record (prog_enr_rec)

In the Registrar: Reports Menu, use the following three menu options to run reports containing additional registration information:

• Enrollment • External Agencies • Rosters

The following list contains descriptions of the types of registration reports that you can access, depending on which menu option you select from the Registrar: Reports Menu.

Enrollment Reports Menu Information on various categories and classifications of students. Use the information in these reports to estimate tuition figures.

External Agencies Reports Menu Integrated Post-Secondary Education Data System (IPEDS) and other government reporting information.

Rosters Reports Menu Student rosters by various categories and classifications. Use the information in these reports to estimate income from course fees.

Student Services Reports Student services reports provide information on housing, meal plans, waivers, and any additional student situations not related to registration. You can access these reports from the Student Management: Student Services Menu. If this menu is not available to you, contact the Student Services office for copies of these reports.


Report File Information

Introduction CARS Solution contains a variety of reports for easy reporting of Student Billing database information. Some of the reports are ACE reports, and reside in a reports subdirectory. Other reports are generated from the billing program itself.

Report Access and Files The following lists the reports provided with Student Billing. Some reports listed do not appear on the CARS Solution menu system because they are used only in Csh scripts.

1098-T Form Report Displays the information required by the Federal government for the Taxpayer Relief Act of 1997 (Hope Scholarship).

Menu Access: 1098-T Main menu: 1098-T Data Report

File: $CARSPATH/modules/stubill/reports/t1098d

Add/Drop History - Student report Displays the registration history of a student for a specified session and year.

Menu Access: Student Billing Main menu: Add/Drop History - Student

File: $CARSPATH/modules/regist/reports/reghist

Billing Parameter Records Report This report prints the Billing Parameter table.

Menu Access: Table Maintenance Main menu: Billing/Interest Report

File: $CARSPATH/modules/stubill/reports/pbilling

Individual Registration Audit - PRD This report prints the courses and fees for those students who have one or more alternate courses. Should the student’s alternate course change (e.g., the student drops the course), the report will show the reduction in fees owed.

Menu Access: Reports Main menu: Alternate PRD Refund Drops

File: $CARSPATH/modules/stubill/reports/prdaltrfnd

Journal By Entry Displays a listing of a specified journal with related entries and transactions.

Menu Access: • Post Billing Charges Main menu: G/L Journal Reports • Post Financial Aid Main menu: G/L Journal Reports • Interest Main menu: G/L Journal Reports

File: $CARSPATH/modules/accounting/reports/jrnlent

Journal By Subsidiary Entry Displays subsidiary transactions by journal.

Menu Access: • Post Billing Charges Main menu: S/L Journal Reports • Post Financial Aid Main menu: S/L Journal Reports • Interest Main menu: S/L Journal Reports

File: $CARSPATH/modules/accounting/reports/jrnslent

Pre-Billing Proof Report


Prints student charges and any posting adjustments that need to be made when charges are posted.

Menu Access: Post Billing Charges Main menu: Pre-Billing Proof Report

File: $CARSPATH/src/stubill/billing

Pre-Interest Proof Report Runs the billing program in report verification mode.

Menu Access: Interest Main menu: Pre-Interest Proof Report

File: $CARSPATH/src/stubill/billing

Report To Verify Registered/Audit Course Hours Prints one registration form for the individual specified.

Menu Access: Reports Main menu: Registered Hours By Person

File: $CARSPATH/modules/stubill/others/regcw

Student Billing Information Report Displays the billing information of a student for a specified session and year.

Menu Access: Student Billing Main menu: Print Student Information

File: $CARSPATH/modules/stubill/reports/billaudit

Subsidiary Account Balances Report For... Displays subsidiary accounts balance using subsidiary transactions.

Menu Access: Reports Main menu: S/L Account Balances

File: $CARSPATH/modules/accounting/reports/subbalance

Subsidiary Account Session Aging For ... Report Displays the subsidiary accounts balance using subsidiary balance records.

Menu Access: Reports Main menu: S/L Balances by S/L Period

File: $CARSPATH/modules/accounting/reports/subbalprds

Subsidiary Charges and Payments Report For ... Prints the total records for charges and payments by person and by Tot code.

Menu Access: Reports Main menu: Student Charges/Payments

File: $CARSPATH/modules/stubill/reports/pdchgtot

Subsidiary Entries By G/L Period(s) For ... Report Prints the Subsidiary Entries and/or Summary for a subsidiary by a given range of G/L periods.

Menu Access: Reports Main menu: S/L Entries by G/L Period

File: $CARSPATH/modules/accounting/reports/subentprds

Subsidiary Entries By Subsidiary Period For ... Report Prints the Subsidiary Entries and/or Summary for a subsidiary by subsidiary period.

Menu Access: Reports Main menu: S/L Entries by S/L Period

File: $CARSPATH/modules/accounting/reports/subentprd

Subsidiary Entries Report By Date For ... Prints the Subsidiary Detail and/or Summary for Subsidiaries with or without Balances or Totals for the date range you specify.

Menu Access: Reports Main menu: S/L Entries by Date

File: $CARSPATH/modules/accounting/reports/subentdate

Subsidiary History Report


Prints subsidiary transactions by date and additional subsidiary account information.

Menu Access: Reports Main menu: Subsidiary History

File: $CARSPATH/modules/accounting/reports/subtrhist

Subsidiary Transactions By Date For ... Report Prints one student and their transactions for the period entered and is sorted by date.

Menu Access: Reports Main menu: S/L Transactions By Date

File: $CARSPATH/modules/accounting/reports/subtrdate

Subsidiary Transactions By Date/Entry Type For ... Report Prints one student and their transactions for the period entered and is sorted by entry.

Menu Access: Reports Main menu: S/L Transactions By Entry

File: $CARSPATH/modules/accounting/reports/subtrent

Subsidiary Transactions By Tot Type For ... Report Prints students and their transactions for the period parameters.

Menu Access: Reports Main menu: S/L Transactions By Total

File: $CARSPATH/modules/accounting/reports/subtrtot

Total Code Balances Report For... Prints totals for each Total code showing revenue for any subsidiary with totals.

Menu Access: Reports Main menu: Total Balances/Person

File: $CARSPATH/modules/accounting/reports/substot

Total Code Summary by G/L Account Report Prints the total balances for type of total that you specify (e.g., A=Financial Aid, B=Automatic Billing).

Menu Access: Reports Main menu: Total Balances/GL Account

File: $CARSPATH/modules/accounting/others/totbal


Preparing for a New Billing Session

Introduction Your institution should begin preparing for a new billing session four weeks before the session begins. This requires a cooperative effort from the following offices:

• Computer center • Registrar • Financial Aid • Controller • Student Accounts/Billing

Macro Files to Update The following lists the steps to follow for updating the macros in the periodic macro file that are specific to Student Accounts/ Billing.

Note: You must update, translate and install, check in the macro file(s), and reinstall the Student Billing and Accounting screens and menu options, before your institution updates the macro files specific to Student Accounts/Billing.

1. Enter $CARSPATH/macros/custom/periodic at the shell to access the periodic macro file.

2. Update the macro definitions in the SESSYR_OTH macro to include any other session codes that your institution needs.

3. Check to ensure that the BILL_PARAM_VALID macro uses the information in the SESSYR_VALID macro or has its own set of sessions defined.

4. Check to ensure that the macro SUBS_PRD_VALID uses the information in the SESSYR_VALID macro.

Note: The SESSYR_VALID macro uses the information in the SESSYR_OTH macro.

5. Update the following macros using the appropriate values only at the end of a fiscal year:

FS_YR_BEG_DEF

FS_YR_END_DEF

FS_YR_PREV

FS_YR_CUR

FS_YR_NEXT

FS_YR_OTH

Tables Specific to General Ledger The following lists each table that is specific to general ledger. Review and update, if necessary, these tables in the order listed below.

Fiscal Calendar Record Add or verify the entry for the next session.

Subsidiary Total Table Add account numbers to this table after you update the Student Billing tables (see Tables specific to Student Accounts/Billing in this section).

Tables Specific to Student Accounts/Billing The following lists each table that is specific to the Student Accounts/Billing application. Review and update, if necessary, these tables in the order listed below.


For additional information on Student Billing tables, see Setting Up Student Accounts/Billing Tables in this guide.

Billing Parameters Record Update the prior session and add a new entry for each session.

Note: After you select Post Billing Charges from the Student Accounts/Billing: Post Billing Charges menu to finish processing for a given session, access the Billing Parameters table, select the previous session, and update the Bursar Calc field to "N." Updating the Bursar Calc field tells the system not to continue looking up and calculating billing charges for previous sessions when you only want charges for the current session. Any charges for previous sessions remain the same as when they were last posted.

Interest Parameters Record Update this record monthly with new begin and end dates if your institution posts interest monthly. Also, update this record to post to a new session code, if applicable.

Assessment Table Add a new set of entries for the next session by selecting Copy Assess to New Session from the Table Maintenance: Student Billing (A-E) menu and manually updating the appropriate values as needed.

Charge Table Add a new set of entries for the next session by selecting Copy Charge to New Session from the Table Maintenance: Student Billing (A-E) menu and manually updating the appropriate values as needed.

Subsidiary Total and Subsidiary Association Tables Add new table charge codes by selecting After Adding Charges from the Table Maintenance: Student Billing (A-E) menu and verifying that the output file contains "bye" at the end of the file. Review the output file and read your electronic mail to determine if any problems exist.

Note: Any new entries in the Subsidiary Total table that the system added after you selected either After Adding Charges from the Table Maintenance: Student Billing (A-E) menu or After Adding Aid Codes from the Financial Aid: Table Maintenance menu will not contain account numbers.

Subsidiary Total Table Select the new codes and update the information in this table by adding valid general ledger account numbers to enable the student billing posting process to function properly.

• To verify which total codes might be missing account numbers, access the Fiscal Management: Main Menu and select Accounting, then Table Maintenance Menu, then Financial (J-Z).

• You do not need to add a general ledger account number to the PAID total. • Set the CASHIER Post field to "Y" for any manual totals or aid totals in this table

that the Cashier program is to post.

Refund Table Add a new set of entries with the correct dates and percentages for each session.

Fee Cap Table Enter the appropriate data if you have maximum fee limits across combined sessions.

Payment Plan Table Enter values if you want to use the deferred payment plan.

Note: Updating this table is optional.

Deferred Payments Table Enter values if you want to use the deferred payment plan.


Statement Parameters Record


Add a new entry for each batch of statements if your institution plans to send statements.


Deferment and Deferment Application Tables Update these tables as needed if your institution is using the Fee Collection and Third-Party Billing programs.

Other Functions to Review and Update The following lists and describes other processes used for reviewing and updating Student Accounts/Billing records.


2. Select Accounting from the Fiscal Management: Main Menu.

3. Select G/L Maintenance and enter your password.

4. Select Audit Menu from the Accounting: General Ledger Maintenance Menu, then select S/L Report and Update. Check the output for any errors.

Note: If the output contains errors, repeat this step to determine if the system updated the information. If the output contains errors the second time, contact your institution's computer center.

5. Access the Accounting: General Ledger Maintenance Menu and select S/L Balance Status Update.

Note: If you do not select S/L Balance Status Update, the system begins to slow down after a few years when you load student account information, due to the volume of open records.

6. Select Subsidiary Balance Forward from the Accounting: Period End Processing menu to move balances from previous sessions to current sessions.

CAUTION: Running this menu option causes balances that were moved forward to be reflected as balances as of the balance forward journal date, rather than as of the original posting date. You still might want to move balances forward from very old sessions. You should use this menu option to move credit balances forward on a regular basis.

Additional General Ledger Tables The following lists additional general ledger tables that are used by Student Accounts/Billing.

atype_table G/L Amount Types Table

doc_table Document Table

ent_table Entry Table

fnd_table Funds Table

fs_table Financial Statement Table

func_table Function Table

gld_rec Defined Accounts Table

obj_table


Object Table

pay_frm_table Payment Form Table

pay_term_table Payment Terms Table

subs_table Subsidiary Table

vch_table Journal Table


Processing Taxpayer Relief Act Information (1098-T)

Introduction The Taxpayer Relief Act of 1997 included provisions for tax credits for college tuition and other qualifying expenses. The Act requires that qualifying institutions provide the Federal government with name, address, and enrollment information about any students who were enrolled at the institution, starting with the calendar year 1998.

Format of Required Information The Taxpayer Relief Act requires that students be provided with paper documents confirming their enrollment for at least part of the calendar year. These documents are 1098-T forms.

It further requires that institutions forward the necessary information to the Federal government on tape or diskette.

Required Information The Taxpayer Relief Act requires the following information:

• Student name • Student permanent address • Student social security number • Graduate student status (check box) • Part-time student status (check box)

This information exists in various records throughout the CARS Solution. CARS Solution processes collect the required data from these records and format it as mandated by Federal law.

CARS Solution Record Used for Data Collection CARS Solution uses the t1098_rec to collect the necessary information for Taxpayer Relief Act reporting. The schema file for this record (t1098) resides in $CARSPATH/schema/financial. The system creates the t1098_rec for students who have been registered for classes during the year (as either part- or full time-enrollees) in either a graduate or undergraduate program.

Reports from Data Collection The Form 1098-T Report ($CARSPATH/modules/stubill/reports/t1098d) displays the t1098_recs for the specified tax year. The report, sorted by ID, includes ID number and student name, and places an “X” in the appropriately labeled column if the student is Graduate or Part-time (or both).

The 1098-T Audit Report ($CARSPATH/modules/stubill/reports/t1098audit) provides the support information needed to determine if a student will receive a 1098-T form. The report, sorted by ID, includes ID number and student name, and lists all the students who were evaluated during the process of creating the t1098_rec. Those students for whom no t1098_rec was created are flagged with the message “Check this Record.”

Impact of 1098-T Processing on Other Tables and Records Processing 1098-T information impacts the following CARS Solution tables and records:

Program Table The Program table (schema file $CARSPATH/schema/student/tprog) contains the following fields that are relevant to 1098-T processing: undg

A Y/N flag indicating whether the program is considered Undergraduate. If this field is blank, the program is assumed to be neither Undergraduate nor Graduate, and no 1098-T form will be produced for enrollees in the program.

part_time_hrs


A numeric field indicating the number of credit hours in which a student must be enrolled to be considered part-time. The system uses this number to evaluate whether to check the box on the 1098-T for “At Least Half-Time”. If a student is enrolled during the year for at least as many hours as are specified in this field, then the box on his/her 1098-T will contain a check.

ADR Table The ADR table (schema file $CARSPATH/schema/common/tadr) must contain an entry for a runcode of 1098T. The text for this entry is “Tax Payer Relief Act”. Jenzabar provides this table value as part of the standard CARS Solution.

ADR Record The ADR record (schema file $CARSPATH/schema/common/adr) must contain one or more entries for a runcode of 1098T. An example of the required (or suggested) fields and values for the adr_rec follows: id

A value of 0 is required. run_code

A value of 1098T is required, corresponding to the entry in the ADR table. use_prim

A value of Y. lbl_style

A value of F. salut_style

A value of I. name_line_no

A value of 1. use_suffix/use_title

A value of Y for both of these fields. dup

A value of N. priority

A value of 0.

Process Flow for 1098-T Production The following diagram shows the processes and data used to produce 1098-T output:


$CARSPATH/modules/stubill/scripts/t1098

executes ACE report

ACE report$CARSPATH/modules/

stubill/report/t1098creates informer

Informer in /tmpdirectory

id_recstuacad_recprog_table

t1098_rec

$CARSPATH/src/stubill/t1098edit

enables user to editrecords as required

Email containschanges made to

t1098_rec

Paper, tape, ordiskette output?paper

t1098tape processproduces tape ordiskette output

tapeoutput

adr_recid_rec

Email containsresults of script

processing

start

ADRlib obtainsstudents' permanent

addresses

t1098form processproduces file for paper

output

download-able file

FPS process producespaper output

paper output forstudents

tape or diskette


Macro Setup for 1098-T Processing The 1098-T process relies on values you enter in macros to define the contents of the tape or diskette, and then formats the values as specified by the IRS. Therefore, to ensure the tape or diskette you send complies with IRS requirements, you define values in the following macro files:

• $CARSPATH/macros/custom/t1098 • $CARSPATH/macros/custom/periodic

Macros in $CARSPATH/macros/custom/t1098 The following macros are located in the file $CARSPATH/macros/custom/t1098. The macros are listed in the order in which they appear in the macro file.

Note: • Unless otherwise specified, the information provided by these macros is required for

compliance with IRS/ MMR (Magnetic Media Reporting) requirements. • The EMPR_ macros (e.g., EMPR_NAME) expand to provide names and addresses.

You define the values for the EMPR_ macros in $CARSPATH/macros/custom/financial.

m4_define(`T1098_TCC_CODE', `99999') The five-character alphanumeric Transmitter Control code (TCC) assigned by the IRS/MCC. You must have a TCC to file your 1098-T data.

m4_define(`T1098_TRANS_REPLACEMENT_CODE', `') Required for replacement files only, the alphanumeric character which appears immediately after the TCC number on the Media Tracking Slip (Form 9267). The form 9267 accompanies media that has been returned by IRS/MCC because of procesing problems. This field must be blank unless the original submission has been returned. If the file is being replaced magnetically, or if the file was originally sent magnetically, but the replacement is being sent electronically, the information is required in this field.

m4_define(`T1098_TEST_CODE', `') A “T” if the file is a test file; otherwise, a blank.

m4_define(`T1098_TRANS_FOREIGN_ENTITY', `') A “1” if your institution is a foreign entity; otherwise a blank.

m4_define(`T1098_TRANSMITTER_NAME_1', ÈMPR_NAME’) The name of the institution as used in normal business. This value cannot exceed 40 characters. If the value you have assigned to EMPR_NAME exceeds 40 characters, the excess characters will be truncated. If desired, you can use the T1098_TRANSMITTER_NAME_2 macro for characters in excess of 40 characters.

m4_define(`T1098_TRANSMITTER_NAME_2', `') If required, any additional information that may be part of the institution’s name. This value cannot exceed 40 characters.

m4_define(`T1098_COMPANY_NAME_1', ÈMPR_NAME’) The name of the location to which correspondence should be addressed, or to which media should be returned as a result of processing problems. This value cannot exceed 40 characters.

m4_define(`T1098_COMPANY_NAME_2', ÈMPR_NAME’) If required, any additional information that may be part of the location name (i.e., the place to which correspondence should be addressed, or to which media should be returned as a result of processing problems). This value cannot exceed 40 characters.

m4_define(`T1098_COMPANY_MAILING_ADDR', ÈMPR_ADDR1’)


The address to which correspondence should be sent or media should be returned in the event the IRS is unable to process the submission. This value cannot exceed 40 characters.

m4_define(`T1098_COMPANY_CITY', ÈMPR_CITY') The city, town, or post office to which correspondence should be sent or media should be returned in the event the IRS is unable to process the submission. This value cannot exceed 40 characters.

m4_define(`T1098_COMPANY_ST',ÈMPR_ST') The U.S. Postal Service state abbreviation for the state.

m4_define(`T1098_COMPANY_ZIP', ÈMPR_ZIP') The nine-digit zip code assigned by the U.S. Postal Service. If you do not know the 9-digit code, you can define this value with the 5-digit code.

m4_define(`T1098_CONTACT_NAME', ÈMPR_NAME') The name of the institution to contact if the IRS encounters problems with the file or your transmission. This value cannot exceed 40 characters.

m4_define(`T1098_CONTACT_PHONE_EXT', `999-999-9999-99999') The telephone number and extension of the contact person. Format the number as area code-exchange-line number-extension. If no extension exists, you can omit the last hyphen and the last five digits. This value cannot exceed 15 digits (excluding hyphens).

Example: Enter the number 304-263-8700 extension 52345 as 304-263-8700-52345. Enter the number 304-263-8700 without an extension as 304-263-8700.

m4_define(`T1098_MAGNETIC_TAPE', `LS') The letters “LS” if you are filing using magnetic tape; otherwise, blank.

m4_define(`T1098_ELECTRONIC_FILE_NAME', `') Either the original filename or the name of the correction file as assigned by the IRP-BBS (e.g., 12345p01.DAT). Do not enter the replacement file name. If the submission is not an original or correction file, leave the field blank.

m4_define(`T1098_PAYER_NAME_CONTROL', `') The first four characters of the payer’s name, as shown on the mail label from the Package 1099. These characters provide information for the MMR (Magnetic Media Reporting) Package because the MMR mail label does not contain name control. Complete this field if the Package 1099 has been received and the Payer Name Control is known; otherwise, leave the field blank.

m4_define(`T1098_LAST_FILING_YR', `') The number “1” if this is the last year the payer will file. Set this indicator if the payer will not file information returns under this payer name and TIN in the future (either magnetically, electronicallly, or on paper). Otherwise, leave the field blank.

m4_define(`T1098_COMBINATION_FILING', `') The number “1” if the institution is participating in the Combined Federal/State Filing Program; otherwise, blank. The only forms that may be filed under the Combined Federal/State Filing Program are: Forms 1099-DIV, 1099-G, 1099-INT, 1099-MISC, 1099-OID, 1099-PATR, 1099-R, and 5498.

m4_define(`T1098_TYPE_OF_RETURN', `8') The IRS-defined type of return. For 1098-T filings, the code is “8”.

m4_define(‘T1098_AMOUNT_CODE’, ‘120000000000’) Currently not in use.

m4_define(`T1098_ORIGINAL_CODE’, `1') A “1” if the information is original data; otherwise, blank.

m4_define(`T1098_PAYER_REPLACEMENT_CODE', `')


A “1” if the file replaces a previous file that IRS/MCC returned to the transmitter because of errors in processing; otherwise, blank.

m4_define(`T1098_CORRECTION_CODE', `') A “1” if the file contrains corrected information that was previously submitted and processed by IRS/MCC, but contained errors; otherwise, blank.

Note: If you want to submit new, previously omitted information, it must not be added into a correction file, but must be submitted as original.

m4_define(`T1098_PAYER_FOREIGN_ENTITY', ` ') A “1” if the payer is a foreign entity; a blank if the payer is not a foreign entity.

m4_define(`T1098_FIRST_PAYER_NAME', ÈMPR_NAME') The name of the payer. This value cannot exceed 40 characters.

m4_define(`T1098_SECOND_PAYER_NAME', ÈMPR_NAME') Contents based on the value you set for the macro T1098_TRANSFER_AGENT below. If that macro contains a value of “0”, this macro defines a continuation of the name of the payer; if that macro contains a value of “1”, this macro defines the name of the transfer (or paying) agent.

m4_define(`T1098_TRANSFER_AGENT', `0') A “0” (zero) if the entity defined in T1098_SECOND_PAYER_NAME above is a continuation of the payer name; a “1” if the entity defined in T1098_SECOND_PAYER_NAME above is the transfer (or paying) agent.

m4_define(`T1098_PAYER_SHIPPING_ADDR', ÈMPR_ADDR1') Street address of the transfer (or paying) agent (if T1098_TRANSFER_AGENT is set to “0”), or the street address of the payer (if T1098_TRANSFER_AGENT is set to “1”.)

m4_define(`T1098_PAYER_CITY', ÈMPR_CITY') City of the transfer (or paying) agent (if T1098_TRANSFER_AGENT is set to “0”), or the city of the payer (if T1098_TRANSFER_AGENT is set to “1”.)

m4_define(`T1098_PAYER_ST', ÈMPR_ST') State of the transfer (or paying) agent (if T1098_TRANSFER_AGENT is set to “0”), or the state of the payer (if T1098_TRANSFER_AGENT is set to “1”.)

m4_define(`T1098_PAYER_ZIP', ÈMPR_ZIP') Zip code of the transfer (or paying) agent (if T1098_TRANSFER_AGENT is set to “0”), or the zip code of the payer (if T1098_TRANSFER_AGENT is set to “1”.)

m4_define(`T1098_PAYER_PHONE_EXT', `999-999-9999-99999') The telephone number and extension of the payer. Format the number as area code-exchange-line number-extension. If no extension exists, you can omit the last hyphen and the last five digits. This value cannot exceed 15 digits (excluding hyphens).

Example: Enter the number 304-263-8700 extension 52345 as 304-263-8700-52345. Enter the number 304-263-8700 without an extension as 304-263-8700.

m4_define(`T1098_CORRECTED_RETURN', `') A “G” if this is a one-transaction correction or the first of a two-transaction correction, or a “C” if this is the second transaction of a two-transaction correction; otherwise, blank.

m4_define(`T1098_PAYER_OFFICE_CODE', `') The four-character office code of the payer; otherwise, blank. For payers with multiple locations, this field may be used to identify the location of the office submitting the return.

In addition, the following enable macros exist in the $CARSPATH/macros/custom/t1098 file:

m4_define(‘ENABLE_T1098_NAME_SORT’, ‘N’) m4_define(‘ENABLE_T1098_SSN_SORT’, ‘N’) m4_define(‘ENABLE_T1098_ZIP_SORT’, ‘N’) m4_define(‘ENABLE_T1098_ZIP_NAME_SORT’, ‘Y’)


The means to control the sorting of 1098-T output. You can sort by name, social security number, zip code, or by a combination of zip code and name. As delivered, the last of these four macros is set to Y, and the others are set to N, causing the output to sort first by zip code, then by name (i.e., by name within zip code). Only one of these macros can be set to Y; if none is set to Y, the default sort criteria is the ID. Includes stored in $CARSPATH/include/custom/t1098 work with these macros and should not be changed.

Macros in $CARSPATH/macros/custom/periodic The following macros are located in the file $CARSPATH/macros/custom/periodic. These macros provide default dates for 1098-T processing.

m4_define(`T1098_PAY_YR_BEG_DEF', `01/01/1998') The beginning date of the 1098-T payment year.

m4_define(`T1098_PAY_YR_END_DEF', `12/31/1998') The ending date of the 1098-T payment year.

m4_define(`T1098_PAY_YR_PREV', `1997') The previous year as used for 1098-T processing.

m4_define(`T1098_PAY_YR_CUR', `1998') The current year as used for 1098-T processing.

m4_define(`T1098_PAY_YR_DEF', `T1098_PAY_YR_CUR') The default for the current payment year.

m4_define(`T1098_PAY_YR_VALID', `T1098_PAY_YR_PREV,T1098_PAY_YR_CUR') The years for which 1098-T processing is valid.

m4_define(`T1098_PAY_YR_INCL', ìnclude=(T1098_PAY_YR_VALID), upshift') The years for which 1098-T processing is valid.

Other 1098-T Macros that Do Not Require Modification Macros in the following files are required for 1098-T processing, but do not require modification during implementation or maintenance.

• $CARSPATH/macros/custom/comment • $CARSPATH/macros/user/prompt • $CARSPATH/macros/user/inc

Macros in $CARSPATH/macros/custom/comment The following macros are located in the file $CARSPATH/macros/custom/comment. These macros provide the comments that display on the comment line of program screens.

m4_define(`COMMENT_PAY_YR',Ènter the payment year.') m4_define(`COMMENT_PAY_YR_DATE_BEG',Ènter the payment year beginning date.') m4_define(`COMMENT_PAY_YR_DATE_END',Ènter the payment year ending date.')

Macros in $CARSPATH/macros/user/prompt The following macros are located in the file $CARSPATH/macros/user/prompt. These macros provide prompts that display on program screens.

m4_define(`PP_PAY_YR',`Payment Year...................') m4_define(`PP_PAY_YR_DATE_BEG',`Beginning Payment Year Date....') m4_define(`PP_PAY_YR_DATE_END',Ènding Payment Year Date......')


Macro in $CARSPATH/macros/user/inc The following macro is located in the file $CARSPATH/macros/user/inc. This macro enables includes and screens to read other macros.

m4_include(M4PATH/custom/t1098.m4)

Menu Options for Data Collection and Formatting The main 1098-T menu provides access to all the steps required to collect and process Taxpayer Relief Act information. The menu description file for the menu is located in $CARSPATH/menusrc/fiscal/stubill/billing/t1098/menudesc.

The following menu options exist for 1098-T processing:

Initialize Data Collects and stores data needed for the 1098-T form, using the year specified in the last four digits of the Beginning date parameter.

Accesses: $CARSPATH/modules/stubill/scripts/t1098 and $CARSPATH/modules/stubill/reports/t1098

Menuopt File: $CARSPATH/menuopt/stubill/scripts/t1098

Parameters Passed: • Payment Year (required) • Beginning Payment Year Date (required) • Ending Payment Year Date (required) • ID (optional; for collecting data for a single ID) • Site (optional; for collecting data for a single site)

Edit Data Enables the user to edit 1098-T form data for a given tax year.

Accesses: $CARSPATH/modules/stubill/progscr/t1098 and $CARSPATH/src/stubill/t1098edit

Menuopt File: $CARSPATH/menuopt/stubill/programs/t1098fm.e

Parameters Passed: • Payment Year (required)

Prepare Forms Performs an intermediate step to creating the 1098-T data files for the Forms Processing System (FPS) process. The form is located in $CARSPATH/modules/stubill/forms/f1098form/f1098_T

Accesses: $CARSPATH/src/stubill/t1098form

Menuopt File: $CARSPATH/menuopt/stubill/programs/t1098fm

Parameters Passed: • Payment Year (required) • ID (optional; for preparing data for a single ID) • ADR runcode (optional) • Ignore holds (optional; for causing the program to process 1098-T information

regardless of the existence of any student holds)

Print Forms Prints the individual forms using FPS. The actual form printed is $CARSPATH/modules/stubill/forms/1098forms/1098_T

Accesses: $CARSPATH/src/util/fps

Menuopt File: $CARSPATH/menuopt/utilities/programs/fps.1098t

Parameters Passed:


• None

Prepare Tape Performs an intermediate step to creating the 1098-T data tape.

Accesses: $CARSPATH/src/stubill/t1098tape

Menuopt File: $CARSPATH/menuopt/stubill/programs/t1098t

Parameters Passed: • Year (required) • Disk (optional; for causing the program to generate diskette data; if blank, the

program assumes you want to create a tape)

Write Tape Writes the 1098-T data onto a tape.

Accesses: $CARSPATH/src/stubill/t1098tape

Menuopt File: $CARSPATH/menuopt/stubill/programs/t1098tp

Parameters Passed: • None

Verify Tape Prints the tape information to the screen for format verification.

Accesses: $CARSPATH/src/util/single/taperead.c

Menuopt File: $CARSPATH/menuopt/utilities/programs/tprd

Parameters Passed: • None

Prepare Diskette File Creates a file of 1098-T information in the user’s UNIX home directory. This file must be downloaded to a diskette for submission to the Federal government

Accesses: $CARSPATH/src/stubill/t1098form

Menuopt File: $CARSPATH/menuopt/stubill/programs/t1098disk

Parameters Passed: • Payment Year (required) • Disk (required; causes the program to produce diskette output)

Menu Options for Reporting The 1098-T Reporting menu provides access to the reports that help you process Taxpayer Relief Act information. The menu description file for the report menu is located in $CARSPATH/menusrc/fiscal/stubill/billing/t1098/reports/menudesc

The following menu options exist for 1098-T reporting:

1098-T Audit Report Generates a report of the students evaluated during the creation of the t1098_rec for the specified year.

Accesses: $CARSPATH/modules/stubill/reports/t1098audit

Menuopt File: $CARSPATH/menuopt/stubill/reports/t1098audit

Parameters Passed: • Payment Year (required)

1098-T Data Report


Generates a report of the contents of the t1098_rec for the specified year. It displays ID information for those who are enrolled as over half-time students.

Accesses: $CARSPATH/modules/stubill/reports/t1098data

Menuopt File: $CARSPATH/menuopt/stubill/reports/t1098.d

Parameters Passed: • Payment Year (required) • ID (optional; for producing a report for a single ID)

INDEX $ $CARSPATH/macros/custom/comment, 50 $CARSPATH/macros/custom/periodic, 50 $CARSPATH/macros/custom/t1098, 47 $CARSPATH/macros/user/inc, 51 $CARSPATH/macros/user/prompt, 50

1 1098-T Form Report, 37 1098-T processing

macros, 44, 47

A accounting subsidiary ledger audits, 35 ACE reports, 37 Add/Drop History - Student report, 37 Assessment table, 41. See Assessment and

Charge tables accumulated hours keywords, 7 conditions fields, 4 courses keywords, 7 database file keywords, 7 examples

course audit fees, 13 dorm fees, 12 drop/add fees, 12 holding accounts, 13 lab fees, 11 meal plan charges, 13 pre-payment credits, 13 tuition charges, 12

fields, 3, 5, 6 keywords, 6 other keywords, 8 primary section, 4 refund section, 6 secondary section, 4

audits accounting subsidiary ledger, 35

average daily balance, 22 codes, 22 interest calculation methods, 21

average daily balance method

example, 22

B balance codes

average daily, 22 balance minus credits codes, 22 balance type calculation methods

average daily balance, 19 balance minus credits, 19 beginning balance, 19 ending balance, 19 sample data, 19

beginning balance codes, 20 BILL_OLD_REFUND_TOT, 15 BILL_REFUND_TOT, 15 Billing Parameter Records Report, 37 Billing Parameters record, 41 Billing Parameters Record

fields, 1 Billing program

introduction, 1 program flow, 33

billing sessions macros to update, 40 new, 40

C calculating interest

prerequisites, 18 student billing vs. interest, 18

Calculating Interest. See interest calculation methods

calculating interest on subsidiary accounts running the Interest program, 24

calculating minimum payment, 26 Deferred Payment table, 26

CASH_REFUND_TYPE_SA2SR, 15 Charge and Assessment tables

sample data, 26 Charge table, 8, 41. See Assessment and

Charge tables break definition fields, 9 calculation fields, 10 examples

course audit fees, 13


dorm fees, 12 drop/add fees, 12 holding accounts, 13 lab fees, 11 meal plan charges, 13 pre-payment credits, 13 tuition charges, 12

fields, 8 charges

student billing vs. interest, 18 Classification table, 11 codes

average daily balance, 22 balance minus credits, 22 beginning balance, 20 ending balance, 20

compilation values Billing program, 33

computing minimum payments formulas, 27

conditions fields Assessment table, 4

Configuration table entries ENABLE_EXACT_POST_AID, 15 ENABLE_MULTI_STMT_SUBS, 16 ENABLE_NET_CHECKS, 16 IF_FINAID_POSTED, 15 MULTI_STMT_SUBS, 16 NET_CHARGE_SUBS, 16

consolidated statements, 16

D Deferment Application table, 42 Deferment table, 42 Deferred Payment table, 26

sample data, 26 Deferred Payments table, 42 DISPLAY_AMT_LIMIT, 16

E ENABLE_EXACT_POST_AID, 15 ENABLE_FEAT_CASHIER_AC, 15 ENABLE_MULTI_STMT_SUBS, 16 ENABLE_NET_CHECKS, 16 ending balance codes, 19, 20 enrollment reports, 36 Entry table, 11 evaluating Student Billing features, 15 example

Assessment and Charge tables course audit fees, 13 dorm fees, 12 drop/add fees, 12 holding accounts, 13 meal plan charges, 13 pre-payment credits, 13 tuition charges, 12

average daily balance method, 22

Charge and Assessment tables lab fees, 11

month and day, 26 external agencies reports, 36

F Fee Cap table, 41 Fee Collection program, 15 fields

Assessment table, 3 conditions, 4 primary section, 5 refund section, 6 secondary section, 6

Billing Parameters record, 1 Charge table

calculation, 10 definition, 9

Charge table, 8 Fiscal Calendar record, 40 formulas

for computing the minimum payment, 27

G General Ledger tables, 40

Fiscal Calendar record, 40 Subsidiary Total table, 40

H Hope Scholarship processing, 44–52

I IF_FINAID_POSTED, 15 implementing Student Billing features, 15 include

DISPLAY_AMT_LIMIT, 16 pending financial aid on statements, 16

Individual Registration Audit - PRD, 37 interest calculation methods, 19

average daily balance, 21 balance minus credits, 22 balance type calculations, 19 beginning, 20 ending, 20

interest calculation tables, 18 Assessment, 18 Billing Parameters, 18 Charge, 18 Subsidiary Association, 19 Subsidiary Total, 18

Interest Parameters record, 41 interest program

running, 24 invoice type calculations, 23

J Journal By Entry, 37


Journal By Subsidiary Entry, 37

K keywords

Assessment table, 6 accumulated hours or courses, 7 database file, 7 other keywords, 8

M macros, 15. See Configuration table entries

in $CARSPATH/macros/custom/comment, 50 in $CARSPATH/macros/custom/periodic, 50 in $CARSPATH/macros/custom/t1098, 47 in $CARSPATH/macros/user/inc, 51 in $CARSPATH/macros/user/prompt, 50 updated for billing sessions, 40

menu enrollment reports, 36 external agencies reports, 36 rosters reports, 36

minimum payment formulas, 27

modes Executive mode, 32 Interactive mode, 31 optional parameters, 33 post charges mode, 32 process-to-process modes, 32 PTP modes, 32 verify report mode, 31

MULTI_STMT_SUBS, 16

N NET_CHARGE_SUBS, 16

P parameters

optional, 33 running the Billing program from the shell, 31 verify report mode, 32

Payment Plan table, 41 Pre-Billing Proof Report, 38 Pre-Interest Proof Report, 38 preparing for a new billing session, 40 prerequisites

running the Billing program from the shell, 31 primary section

Assessment table, 4 primary section fields, 5 procedure

running the Interest program, 24 program

interest program, 24 program flow, 33 programs

Billing program, 1

Fee Collection, 15 Statement, 16 Student Accounts to Student Refund, 16

R records. See tables

Billing Parameters record, 1 refund section fields, 6 Refund table, 11, 41 registration reports, 36 Report To Verify Registered/Audit Course

Hours, 38 reports

1098-T Form Report, 37 Add/Drop History - Student report, 37 Billing Parameter Records Report, 37 Individual Registration Audit - PRD, 37 Journal By Entry, 37 Journal By Subsidiary Entry, 37 Pre-Billing Proof Report, 38 Pre-Interest Proof Report, 38 registration, 36 Report To Verify Registered/Audit Course

Hours, 38 student billing and accounting, 35 Student Billing Information Report, 38 student services, 36 Subsidiary Account Balances Report For..., 38 Subsidiary Account Session Aging For ...

Report, 38 Subsidiary Charges and Payments Report For

..., 38 Subsidiary Entries By G/L Period(s) For ...

Report, 38 Subsidiary Entries By Subsidiary Period For ...

Report, 38 Subsidiary Entries Report By Date For ..., 38 Subsidiary History Report, 39 Subsidiary Transactions By Date For ...

Report, 39 Subsidiary Transactions By Date/Entry Type

For ... Report, 39 Subsidiary Transactions By Tot Type For ...

Report, 39 Total Code Balances Report For..., 39 Total Code Summary by G/L Account Report,

39 reports and audits

reviewing a billing period, 35 reviewing a billing period

using reports and audits, 35 rosters reports menu, 36 running the Billing program from the shell, 31

Execute mode, 32 Interactive mode, 31 parameters, 31 post charges mode, 32 prerequisites, 31


process-to-process mode, 32 verify report mode, 31 verify report mode parameters, 32

running the Interest program, 24

S secondary section

Assessment table, 4 secondary section fields, 6 special features

Student Billing, 15 special Student Billing features

evaluating and implementing, 15 Statement Parameters record, 42 Statement program, 16 Student Accounts to Student Refund program,

16 student accounts/billing, 41 Student Accounts/Billing

functions to review/update, 42 Student Accounts/Billing tables

Assessment table, 41 Assessment Table, 2 Billing Parameters record, 1, 41 Charge table, 41 Charge Table, 8 Classification table, 11 Deferment Application table, 42 Deferment table, 42 Deferred Payments table, 42 Entry table, 11 Fee Cap table, 41 Interest Parameters record, 41 Payment Plan table, 41 Refund table, 41 Refund Table, 11 Statement Parameters record, 42 Subsidiary Association table, 41 Subsidiary Total table, 11, 41

student billing and accounting reports, 35 Student Billing Information Report, 38 student services reports, 36 Subsidiary Account Balances Report For..., 38 Subsidiary Account Session Aging For ...

Report, 38 subsidiary accounts

calculating interest, 18 Subsidiary Association table, 41 Subsidiary Charges and Payments Report For

..., 38 Subsidiary Entries By G/L Period(s) For ...

Report, 38 Subsidiary Entries By Subsidiary Period For ...

Report, 38 Subsidiary Entries Report By Date For ..., 38 Subsidiary History Report, 39 Subsidiary Total table, 11, 40, 41

Subsidiary Transactions By Date For ... Report, 39

Subsidiary Transactions By Date/Entry Type For ... Report, 39

Subsidiary Transactions By Tot Type For ... Report, 39

T table setup

Students Accounts/Billing, 1 tables

Assessment table, 2, 41 examples, 11, 12, 13

Billing Parameters record, 1, 41 Charge table, 8, 41

examples, 11, 12, 13 Classification table, 11 Deferment Application table, 42 Deferment table, 42 Deferred Payment table, 26 Deferred Payments table, 42 Entry table, 11 Fee Cap table, 41 Fiscal Calendar record, 40 for interest calculations, 18

Assessment, 18 Billing Parameters, 18 Charge, 18 Subsidiary Association, 19 Subsidiary Total, 18

General Ledger, 40 Interest Parameters record, 41 Payment Plan table, 41 Refund table, 11, 41 Statement Parameters record, 42 Student Accounts/Billing, 41 Subsidiary Association table, 41 Subsidiary Total table, 11, 40, 41

Taxpayer Relief Act, 44–52 Total Code Balances Report For..., 39 Total Code Summary by G/L Account Report, 39

U using reports and audits

reviewing a billing period, 35

Student Billing Implementation Guide · Student Management 1 Implementing Student Billing Setting...

Documents

Transcript of Student Billing Implementation Guide · Student Management 1 Implementing Student Billing Setting...