Business Process Modeling Banner Accounts Receivable · Business Process Modeling Banner Accounts...

Business Process Modeling Banner Accounts Receivable

INTERNATIONAL TURNKEY SYSTEM

P.O. BOX: 4627, Riyadh 11412 Kingdom of Saudi Arabia

Date: Tuesday February 5, 2008 Version 1.3

PRINCE MOHAMMAD BIN FAHD UNIVERSITY Business Process Modeling

Banner Accounts Receivable

International Turnkey Systems Confidential

Version 1.3 Page 2 of 27


I. Document Version Control ................................................................................................................. 3

Modification History................................................................................................................................... 3 Reviewers.................................................................................................................................................... 3 Distribution List.......................................................................................................................................... 3

II. Scope & Purpose .................................................................................................................................. 4

III. Next Steps......................................................................................................................................... 4 Banner Accounts Receivable Process Flow: .............................................................................................. 5 First: Fee Assessments ............................................................................................................................... 6 Second: Establish Student Accounts Receivable Controls:......................................................................... 9 Enter/Update/Review Account Detail ....................................................................................................... 12 Maintain Third Party Contracts and Exemptions..................................................................................... 13 Maintain Installment Plans....................................................................................................................... 15 Enter Student Payments ............................................................................................................................ 17 a) Student Payment Form (TSASPAY)............................................................................................. 17 b) Print Receipts.............................................................................................................................. 18 c) Display/Reprint Receipt .............................................................................................................. 18 d) Returned Checks ......................................................................................................................... 18 Application of Payment Procedure........................................................................................................... 19 Cashiering Procedure: ............................................................................................................................. 20 Billing: 22 a) Bill Student Accounts:................................................................................................................. 22 b) Third Party Billing:..................................................................................................................... 22 c) Schedule/Bill Procedure and Processing:................................................................................... 23 Produce Aging Reports............................................................................................................................. 24 Processing Holds/Releases Automatically................................................................................................ 24 Assess Penalty/Interest Charges ............................................................................................................... 25 Contract/ Exemption Roll Process (TSRROLL)........................................................................................ 25





I. Document Version Control

Modification History Date Version Prepared By Comments 0.0 ITS Higher Education Template 19-01-2008 0.1 Eihab Asa'd First Draft 28-1-2008 1.0 Shawki M. Abderrahman 5-2-2008 1.1 Eihab Asa’d 5-2-2008 1.2 Shawki M. Abderrahman Final 3-5-2008 1.3 Eihab Asa’d User’s Review

Reviewers Date Version Reviewed By: Comments 26-1-2006 0.1 Shawki M. Abderrahman 5-2-2008 1.1 Shawki M. Abderrahman

Distribution List

Date Version Distributed To: Location 1.2 ITS PMU-Project Manager PMU





II. Scope & Purpose This document will govern the implementation of Banner Accounts Receivable Module at PMU. The document lists the processes, the related tasks (or steps) and the associated banner objects (forms, reports, jobs, etc.) that handle these tasks in a specified operation order.

III. Next Steps The implementation governed by the final version of the Accounts Receivable document will include:

1- Review and discuss the functionality of the forms (Screens) presented in this document. In addition to setting up the authorization rules required per each screen for different types of users

2- Build the validation tables and rule forms on the production database

3- Review the reports provided within Banner

4- Go Live.





Banner Accounts Receivable Process Flow:





First: Fee Assessments Please See Banner Fee Assessment BPM version 1.0 for more details about Fee Assessments. Following a small review regarding PMU Fee Assessments: 1. Establishing Rules for Fee Assessment (SOATERM):

Registration Fee Assessment Section:

The following fields in the Registration Fee Assessment section of the Term Control Form (SOATERM) are used in fee assessment:

• On-line Assessment – Check this field 'ON' to indicate that the fee assessment can be initiated on-line from the Registration Form (SFAREGS). "Y"-allow on-line fee assessment.

• Refund by Total – Check this field 'ON' in case of building the fee rules on (SFARGFE) using the Flat Charge Amount. In order for the Refund by Totals Method to work, the following steps must also be taken when there is a 'Y' in this field:

1. Check the “Withdraw” indicator 'OFF' for the withdraw Statuses in STVESTS and STVRSTS. And keep the “Count in Assessment” indicator in STVRSTS.

2. Establish refund periods on the Charge/Payment Detail Source Validation Form (TTVSRCE), if needed.

3. Establish detail codes to be used as Tuition and Fee Clearing Accounts on the Detail Code Control Form. (TSADETC).

4. Establish refund rules on the Refund Control Form (SFARFND). The start and end dates established on these rules should encompass the start and end dates of when one can use the Enrollment status codes defined on SFAESTS for the term.

Important Note: When using the ‘Refund by Total’ option in (SOATERM), Banner will choose one of the refund periods defined in (TTVSRCE) as the source of the refund transaction when the student withdraw one or more courses, instead of ‘R’ (Registration Module). So if the student reregisters this course again, Banner will add a full course charge regardless the refunded amount before because the source for the new transaction will be ‘R’.

Check the “Withdraw” indicator 'Off' for the withdraw Statuses in SFAESTS and SFARSTS. And keep the “Count in Assessment” indicator if the refund amount always (0%) for the "Withdraw" transaction.





Web Self –Service Section: The following fields in the Web Self – Service Section of the Term Control Form (SOATERM) are used in fee assessment:

• On-line Assessment Indicator - When checked, records will be inserted in

both the Batch and Collector tables and the value stored will be Y. • Batch Only Indicator - When checked, records will only be inserted in the

Collector table and the value stored will be N. • Batch for Update Indicator - When checked, records will be inserted in both

the Batch and Collector tables and the value stored will be B. • Not Available Indicator - When checked, records will only be inserted in the

Collector table and the value stored will be null. 2. Defining Fee Assessment Rules (SFARGFE):

PMU’s tuition and fee policy is built for a registration term using the Registration Fee Assessment Rules Form (SFARGFE). This form allows PMU to define the rules to be used in the registration fee assessment.

• The rules provide you with the ability to assess fees based on student criteria of campus, residency, level, college, major, class, rate, department, student attribute, student type, degree code, admit term, program, and/or course criteria of part of term, grade mode, schedule type, and instructional method.

• Rule can be further limited by range of billing hours for the minimum and maximum charges for the rule, original registration dates, and flat hour ranges.

• In addition, the rules or charging can be grouped by course level, course campus, and course attributes using all of the above criteria.

• Use STUDENT Rule Type since all of PMU’s rules doesn’t depend on the Course Level, Attribute or Campus.

• Use Regular in the Entry Type field. • Following suggested rules fitting the current PMU’s fee rules:

Detail Code

Per Credit Charge

Min. Charge

Max. Charge

Student Level

Stud. Attrib.

Liable Billing Hours From

Liable Billing Hours

To

Flat Charge Hours From

Flat Charge Hours

To

Flat Charge AMT

Course Overload

Start Hours

Tuition 1875 0 999999 UG 0 11.99 Tuition 1875 0 999999 UG 12 999 12 999 22500 18 Tuition -1875 -999E 999999 UG Prep 12 999 12 999 0 18

3. Registration Additional Fees Control Form (SFAAFEE)

The Registration Additional Fees Control Form provides the fee codes and the amounts that can be used in the Registration Additional Fees Form (SFAEFEE), which may be accessed through the Student Course Registration Form (SFAREGS).





These codes and amounts will be included in registration fee assessment. Prior to entering information on this form, the fee codes must be entered on the Detail Code Control Form - Student (TSADETC). Only a charge code may be used on this form.

4. Registration Fees Min/Max Charge Control Form (SFAFMAX) The Registration Fees Min/Max Charge Control Form provides maximum and minimum amounts, by fee code, that the registration fee assessment can calculate. To review the rules as they apply to a student without updating the database, you may use the Student Course/Fee Assessment Query Form (SFAREGF).

5. Defining Refund Rules for a Term

Enrollment Status Form (SFAESTS) Used to build student enrollment statuses and refund policies by term. No refund rules should be defined her when using the Refund by Total policy on (SOATERM).

Course Registration Status Form (SFARSTS) Used to build course statuses and refund policies by term: • No refund rules should be defined her when using the Refund by Total policy

on (SOATERM). • If the rules should be defined her, make sure to define a rule of 0% in the

Tuition and Fee refund fields for each status has the ‘Withdrawal Indicator’ in STVRSTS, otherwise the system will refund 100% of the Tuition and Fee Charges when the student withdraws.

6. Defining section fees: You can establish and apply rules assigned to individual courses using the course fees information (in the Fee Code/Degree Program Attribute window of SCADETL) or the sections fees information (in the Section Fees/Degree Program Attribute window of SSADETL).

7. Registration fee Assessments Process: This process is used to run batch processing of registration fee assessments. SFRFASC allows you to do the following:

• Use a population selection. • Process assessments for a single ID or a list of IDs. • Use an enrollment status (E) or collector mode (C). • Print audit records (A), student accounting records (T), or both (B). • Use separate date parameters for refunding by total versus effective dating

of assessments. • Run the process in audit or update mode.





SFRFASC runs in conjunction with the settings of the Registration Fee Assessment On-line (Indicator) and the Web Self- Service and Voice Response Assessment On-line (Radio Group) on SOATERM.

• If registration records are processed through self- service as well as through SFAREGS, and the Registration Fee Assessment On-line (Indicator) is unchecked (set to N) and/or the Web Self-Service and Voice Response Assessment Online (Radio Group) is set to Not Available (meaning no assessment information has been recorded), then this process should be run for all students within a term.

• If the Registration Fee Assessment On-line (Indicator) is checked (set to Y), indicating that online fee assessment is available, then this process should be run in collector mode, in case online assessment has been deferred due to the process option setting of the Fees field on SFAREGS being changed to N (Batch for Updates) or B (Batch Only), instead of using the default setting of Y (Immediate).

Second: Establish Student Accounts Receivable Controls:

Before accounts are established and charges and payments entered, a series of controls must be set up: Receivable Procedures 1. Set Banner Accounts Receivable Validation Forms (STV’s or TTV’S) listed in

Appendix (A). 2. Each charge and payment entered on an account must first be established as a detail

code on the Detail Code Control Form - Student (TSADETC). On this form, a code is identified as a charge or payment, financial account information is entered, and any default values are established. 2.1. Identify the detail code as a charge (C) or payment (P). 2.2. Define the category to which the detail code belongs (for example, Tuition,

Cash, or Installment). 2.3. Define the priority of the detail code for use in the application of payments

process. 2.4. Check the Receipt field if a receipt number should be automatically generated

when the detail code is entered on an account (For example, Cash, Checks and Bank deposits).

2.5. Check the Like Term field if a detail code can only be applied to a detail code in the same term in the application of payment process.

2.6. Check / Uncheck the Active field to active / deactivate detail codes. 2.7. Define the default values for the fields (Amount, Term and Effective date) if

desired for fixed charge detail codes like (Application fee, 500 SAR). This default values could be changed when entering the transaction.





Following a suggested detail codes that should be defined at PMU as an example:

Detail Type Category Undergraduate Tuition C Registration Tuition Bus Service Charge C Fees Installment Plan Payment Due C Installment Plans Contract Charge C Contracts Cash P Cash, Checks Check P Cash, Checks Installment - Plan Deferred P Installment Plans Bank Deposit Note P Deposit Contract Payment P Contracts

3. The user IDs must be established on the User Profile Definition Form (TGAUPRF).

This form: 3.1. Identifies a user ID. 3.2. Indicates security for the user:

3.2.1.Security restrictions are established on the Detail Categories defined on Category Code Validation Form (TTVDCAT).

3.2.2.A user can be restricted within a category code to charges, payments or both. 3.2.3.Security may also be established to restrict a user to any charge or any

payment, regardless of category code. 3.3. Identifies the user as a supervisor for cashiering purposes 3.4. Assigns the cashier to a supervisor.

4. Information on how an institution plans to use the Accounts Receivable module is set up on the Accounts Receivable Billing Control Form (TGACTRL). An institution can identify:

• If receipts are to be printed automatically. • If restrictions are to be enforced. If the Enforce Restrictions on User

Profile Form check box is selected, then the restrictive category codes may be established for each user ID on the User Profile Definition Form (TGAUPRF).

• Whether cashiers are assigned to supervisors. If the Assign Cashiers to Supervisor check box is selected, then cashiers may be associated with supervisors on the User Profile Definition Form (TGAUPRF) for the supervisor.

• Whether to process prior-dated transactions based upon the transaction date or the system date.

• The password to be used to override Accounts Receivable holds. • The invoice prefix which will prefix all system generated invoices. For

student account receivables you can use ‘S’. Following suggested values for the TGACTRL control form:

Field Value Automatic Receipt Print Yes





Restrictions on User Profile Form Yes Assign Cashiers to Supervisor Yes Accounts Receivable holds Override Password To be set

5. Customer profiles must be established on the Customer Profile Definition Form

(TGACPRF) if needed. 6. Information on how student accounts are processed on the Student Payment Form

(TSASPAY), contract and exemption parameters, and other controls are set up on the Student Billing Control Form (TSACTRL). An institution can identify:

• The process order to be used when processing contracts and exemptions on the Student Payment Form (TSASPAY).

• Whether the effective date for the term charges on TSASPAY should be the charge date or the current date.

• Whether to roll contracts and related students since contracts should be defined every term.

• Whether to roll exemptions and related students since exemptions should be defined every term.

• Whether to process contracts or exemptions first. • Whether student authorization is required for contracts on the Contract

Authorization Form (TSACONT). • Whether to allow pre-authorized entry of authorization numbers on

TSACONT. When the Automatically Assign Installment Plans on TSAISTP, TSICSRV, Self Service and VR check box is checked, the system assigns a student automatically to a plan for which they qualify.

When the Automatically Calculate Installments on TSAISTP, TSICSRV, Self Service and VR check box is checked, the system calculates installment payments dynamically for the assigned students, but it will not be established unless you run the process (TSPISTT)

7. The detail codes representing returned checks are identified to the system on the

Returned Check Code Control Form (TGARETC). A penalty may be assigned to a returned check. This Form allows the user to define the detail charge codes used to reinstate a charge paid by a returned check, and to define whether a penalty charge should be assessed for a returned check. If a penalty code is associated with the returned check code, a charge will automatically be assessed using the amount in the Penalty Amount field of this form. Entry of a returned check detail code onto an account will cause the NSF (Non-Sufficient Funds) flag to be incremented.

8. Messages to be printed on invoice and statements are set up on the Billing Message Form (TGAMESG). Messages may be general or specific to certain accounts. They may also be specific to an installment plan, delinquency code, or collection agency.





9. Installment plans are established on the Installment Plan Control Form - Student (TSAISTC). The installment plans defined in this form are used in the Installment Plan Form (TSAISTL) to grant loans and time payments. The Interest Detail Code and Interest Rate and the Service Charge Detail Code and Service Charge Amount must either both be entered or both be null. Use this form to define the following detail codes:

Detail Code Description Payment / Charge Plan Detail Code The detail code which will credit

the student the same amount as the total charges.

Payment

Principal Detail Code The detail code used to charge the student in future dates.

Charge

Interest Detail Code Any interest will be charged to the student using this detail code.

Charge

Service Charge Detail Code

The student will be charged for this amount or percentage once using this detail code.

Charge

Enter/Update/Review Account Detail 1. The Account Detail Review Form - Student (TSAAREV) is used to enter and

review charge and payment information about an account. The balance of the account and the current amount due are calculated and displayed on the last line of this form. Any changes to the account information will modify these balances.

Security by category code may be invoked on this form by establishing security restrictions by User ID on the User Profile Definition Form (TGAUPRF) and enforcing the restrictions on the Accounts Receivable Billing Control Form (TGACTRL).

2. The Registration Fee Assessment Audit History Form (SFAFAUD) is used to assist in fee assessment processing and to record fee assessment records by ID and term. This allows you to see how the charge was placed on a student's accounting record. Fee assessment creates audit records and an audit history.

The Detail Audit Information window separates assessments into per credit, flat, and overload charges, and allows you to see the billing hours used, as well as overload starting hours and the per credit charges applied. Charges applied as a result of assessments from section fees and additional fees are displayed in the Note field. If the minimum or maximum restrictions from the rules or





from SFAFMAX have affected the assessment, this is also displayed in the Note field.

3. The Student Account Detail Form (TSADETL) is used to review and enter

information for an account. You may enter charges, payments, deposits, and memo items on this form. The balance of the account and the current amount due are calculated and displayed on this form. Any changes or payments to the account information will modify these balances. Dates/Invoice page: Shows Information about Billing process, Invoice Date and Number. Cross Ref page: Shows the ID of the third party, detail code or category in case the student is assigned to a contract. In case of exemptions, it shows details about the exemption.

4. The Foreign Currency Detail Form - Student (TSADETF) is used to enter charges and payments to an account in a currency other than the base currency.

5. The Billing Mass Data Entry Form - Student (TSAMASS) is used for quick entry

of charges, payments, deposits, and memos to multiple accounts. It is designed to easily enter like charges for a specific entry. Once the information is entered, the appropriate account detail is updated. Note: This form could be used to enter students’ Open Balances debit or credit.

Maintain Third Party Contracts and Exemptions Third party Contracts: 1. The Contract Authorization Form (TSACONT) is used to establish third party

contract authorizations for student accounts. A contract exists in the system as an ID number and a person / non-person name which should be established first on the Person Identification Form (SPAIDEN).

2. Each contract ID may have multiple contracts associated with it. 3. A contract exists as an account level, category code level, or detail level contract.

3.1. At the account level, the contract pays a percentage of charges assessed by the specified sources (for example, ‘R’: Registration.).

3.2. At the category code level, percentages of all charges associated with a certain category code (for example, “tuition”) will be paid.

3.3. At the detail code level, percentages of charges associated with a certain detail code (for example, “Undergraduate Tuition”) will be paid.





Notes:

• For each contract, you can create authorizations at the account, detail code, or category code level. You cannot create authorizations for more than one level per contract.

• The Source indicator values are: A = All, I = Include and E = Exclude.

4. Contracts Roll Options overrides the Rolling options defined in TSACTRL. 5. Minimum Amount field indicates the minimum amount the student must pay of the

designated charges on a student’s account that the third party doesn’t cover. 6. Maximum Amount Field indicates the maximum amount the third party will pay. 7. Students are assigned to the contract in the person assignment window.

7.1. The Priority Field indicates the priority of the contract for the student if the student is authorized for more than one contract.

7.2. Use ‘D’ in the Delete field to indicate that the student is not authorized to the contract any more and to keep record history instead of deleting the record.

Contract Base Information:

Detail Code Description Payment / Charge Payment Detail Code The detail code which will credit

the student the same amount as the total charges sponsored by the third party.

Payment

Charge Detail Code The detail code used to charge the third party.

Charge

8. The Contract Person Authorization Form (TSACONP) is used to assign students

to a contract. You can also use this form to remove students from a contract, and to maintain contract assignment information for students.

9. The Contract Person Query Form (TSICONT) is used to perform specific queries

about individuals assigned to a third party contract. This form helps you determine whether a particular person has been assigned to a third party contract.

Exemptions: 1. All the above notes are the same for the exemptions. 2. Since no one should be charged for the claim, there is no Charge detail code will be

defined on the Exemption Authorization Form (TSAEXPT). 3. The Exemption person Authorization Form (TSAEXPP) is used to assign students

to an exemption. You can also use this form to remove students from an exemption, and to maintain exemption assignment information for students.





4. The Exemption Person Query Form (TSIEXPT) is used to perform specific queries about individuals assigned to an exemption. This form helps you determine whether a particular person has been assigned to an exemption.

Maintain Installment Plans 1. The Installment Plan Code Control Form (TSAISTC) defines the characteristics

and default entry information for loans and time payments for the institution. Only those installments defined by this form may be granted.

2. The Installment Plan Form (TSAISTL) is used to establish installment payment

plans for an account. You can also use this form to delete assignment of automated installment plans, if no installment payments and charges have been posted to the account. In addition, you can use this form to add installment plans manually to a student’s account. 2.1. In the main menu identify the Plan code and Term that will be assigned to the

selected account. 2.2. Choosing the Plan Code will default many of the fields if defined in the

TSAISTC. 2.3. Make sure to choose the Plan detail code and Principal Detail code. 2.4. The Installment Due field is used to determine when installments will be due:

2.4.1. Fixed Day: Installments are due the same day each month. 2.4.2. Last day of Month: Installments are due the last day of the month. 2.4.3. Use Pay Period: Installments are due according to pay period

specified. 2.5. Pay Period field indicates the number of days within the payment periods. 2.6. Repayment Schedule Summary Window displays a specific account's

repayment schedule for a time payment or loan summarized by the Effective Date.

2.7. Repayment Schedule Detail Window displays all repayment schedules for a time payment or loan for a specific account.

Automated Installment Plans: 1. The Plan code should be defined as Auto Installment Plan in TSAISTC. Priority

should be defined also in case the student is eligible for more than one Auto Plan. 2. The Automated Installment Plan Assignment Rules Form (TSAISTA) enables

you to create rules that automatically assign a student to an installment plan for a given term.

3. Assignment rules are based on student attributes and allow you to indicate the level, college, campus, degree, major, and rate code (from the general student record) used to determine how students are assigned to an installment plan. You can specify only (I)nclude or (E)xclude criteria for each of the attributes.





The combination of the priority on the Installment Plan Control Form (TSAISTC) and Include/Exclude rules determines the plan to which a student is assigned. For each of six student attributes, choose one of the following options:

• Use (I)nclude to indicate that only students who match the criteria are to be selected for this plan.

• Use (E)xclude to indicate that a student who matches the criteria may not be selected for this plan.

• Enter no criteria, so students are eligible for this plan no matter what value they have for this attribute.

4. The Automated Installment Plan Rules Form (TSAISTR) enables you to define variables used to calculate the Installment principal amount. • In the Base Plan Rules for Term block, indicate how payments will be

calculated for this plan by selecting either the Equal Payments by Date radio button or the Percentage Payments radio button. If you are using equal payments, specify the start date (First Payment Due Date), Number of Payments, and Pay Period. If you are using percentage payments, indicate the payment dates and percentage of the total due on each date.

Example:

Percentage Payments Example: Equal payments By Date Example: First Payment Due Date = 1-Feb-2008.

Due Date Payment Percent

Number of payments = 3. 1-Feb-2008 70% Pay Period = 30 days. 1-Mar-2008 30%

Amount = 22500. Amount = 22500 Effective Date Amount Effective Date Amount

1-Feb-2008 7500 1-Feb-2008 15750 1-Mar-2008 7500 1-Mar-2008 6750 1-Apr-2008 7500

• Indicate the Minimum Amount for which a plan will be created. If the minimum

amount is not met, installment transactions will not be created even if a student is assigned to the plan.

• On the Installment Payment Plan Rules window, indicate those Category Codes to be included in the calculation, Detail Codes to exclude from a Category, and other Detail codes to include. For example, you can define TUI (tuition) as a category code to be included in installment payment calculations and, in the second block, exclude tuition detail codes used for continuing education classes. In the third block, you can define detail codes to include that are not in the tuition category code (such as a lab fee).





5. The Assign Installment Plan Process (TSPISTA) is used to assign students to an installment plan. For mass assignment, a student will only be added to an installment plan through this process if he is registered for a term (thus having a valid SFBETRM record), meets the rules defined on TSAISTA, and does not already have an installment plan for the term.

If a Population Selection, Term, and Plan Code are used, TSPISTA can assign a student to multiple installment plans for a given term, whether or not the student is registered for the term.

6. The Create Installment Transaction Process (TSPISTT) is used to create the installment plan transactions. Rules created on the Installment Plan Rules Form (TSAISTR) are used for processing. You may run this process for a specific student or for all students.

Enter Student Payments

a) Student Payment Form (TSASPAY) The Student Payment Form (TSASPAY) is used to determine the current status of a student's account for the term. The status of the account is based on the incurred charges (registration, housing, room, meal, or phone).

• The form is term-specific. • The current term balance and any calculated credits for the term, in addition to an

authorized financial aid balance and a memo item balance, are displayed on this form. Credits for the term include deposits, contracts, and exemptions which are calculated and displayed in the Cashier Data section.

• This form reflects contract and exemption information prior to the student paying the bill. Banner automatically calculates contract and exemption information for a student, so that when the student wants to make a payment, the charges to his/her account will reflect any third party contracts or exemptions.

• You may enter charges and payments for a student's account on this form. The balances displayed reflect all outstanding charges (past, present, and future) on the account and detail for the balances may be viewed on request. Receipts may be generated on request from this form.

• Scroll through the cashier data using the horizontal scroll bar to view document numbers, invoice paid numbers, payment numbers, and credits/charges/payments descriptions.





• Access the Student Payment Detail Query Form (TSIQACT) from this form if additional detailed information is required for the balances which appear on the bottom line.

• AR Holds will prevent any transaction for the student in this form. It could be overridden using the Hold Password defined in the TGACTRL.

• Payments are entered in Cashier Data Block: o Detail Code and Amount should be defined. o Trans Paid could be used in application of payment to force this

transaction to be applied to a specific transaction on the account. o Cross Reference Info. Shown in case of contracts and exemptions. o Invoice Number Paid is used in application of payment to force a

payment to be applied to a specific group of charges. o Use Payment Number field to record check or credit card number. o If the detail code used in the transaction has ‘Receipt’ indicator in

TSADETC, then auto receipt number will be generated into the Receipt Number field.

o

b) Print Receipts • If the TGRRCPT process is running in the sleep/wake mode, then the receipt will

be printed automatically. • This process should be run for each cashier’s network printer or it could be run for

all printers by choosing the ‘%’ sign in the printer parameter field. • Each cashier should choose the receipts printer for each logon session. Assigning

the session printer window will pop up only once in many pages, especially the (TSASPAY).

• To set / change the receipts printer, use the (TOADEST) form. • To stop the (TGRRCPT) process or any sleep/wake process, use the form

(GJASWPT), choose ‘N’ in the ‘Continue to Run’ field for the specific Process/Printer.

c) Display/Reprint Receipt The Receipt Form (TGARCPT) is used to display and reprint previously processed receipts. Any receipt created may be displayed on this form. This form may also be accessed from the Student Payment Form (TSASPAY), the Account Detail Form (TSADETL), the Student Foreign Currency Detail Form (TSADETF), and the Account Detail Review Form (TSAAREV) when a receipt number is generated.

d) Returned Checks The Returned Check Code Control Form (TGARETC) allows the user to define the detail charge codes used to reinstate a charge paid by a returned check, and to define whether a penalty charge should be assessed for a returned check. If a penalty code is associated with the returned check code, a charge will automatically be assessed using the





amount in the Penalty Amount field of this form. Entry of a returned check detail code onto an account will cause the NSF (non-sufficient funds) flag to be incremented. Type C (Charge) codes are used for returned check detail codes and returned check penalty codes.

Application of Payment Procedure The Banner Application of Payment Process is a method which allows an institution to determine which payments apply to which charges and to decide the order in which payments should be used and charges should be paid. Only payments with a balance in the Balance field on the Account Detail Form (TSADETL) will be used to pay charges with a balance. A balance for a charge or payment indicates that the charge or payment has not yet been applied and can be processed through application of payments. Future dated transactions will be handled in one of two ways, depending on the status of the Feed Future Effective Transactions check box on the Accounts Receivable Billing Control Form (TGACTRL). If this check box is selected, the effective date is not used, i.e., all transactions are candidates for application of payments. If this check box is cleared, application of payments will only apply to transactions that have a current or less than current effective date. Future charges or payments will not be applied until they become effective. The following is a step-by-step procedure for processing application of payments and a series of rules for establishing priorities for each detail code on the Detail Code Control Form (TSADETC). 1. Set up priorities on each charge and payment on the Detail Code Control Form

(TSADETC). Priority is a three-digit field. • Any position that is non-zero in the payment priority must match the charge

priority exactly. • Zero in any position is a wild card. • Payment priority of 999 used first. • Charge priority of 999 paid first. • Payment priority of 000 will pay anything. Cash is recommended to be a priority

of 000 so it will pay anything. Examples:

• Deposit 999 pays only charge of 999 • Payment 900 pays any charge from 900 to 999 • Deposit 420 pays any charge from 420 to 429 • Payment 100 pays any charge from 100 to 199 • Payment 000 pays any charge from 000 to 999





Note: The Like Term indicator on the Detail Code Control Form – Student (TSADETC), when checked, will prevent payments from applying to charges outstanding from other terms. 2. Priority and the standard Application of Payment Process may be overridden when an

item is entered by directly applying that item to an existing item on the account by transaction number. When the item is entered on the Student Payment Form (TSASPAY), Account Detail Form (TSADETL), or Account Detail Review Form (TSAAREV) the Trans Pay field is populated with the transaction number of the line item to which the entry is being directly applied.

3. Run the Application of Payment Process (TGRAPPL) process in batch. This

process should be run before every accounting feed, either on a nightly or weekly basis, to send the appropriate financial transactions to the accounting system on how charges were paid. The sequence of application of payment is as follows:

a) Direct application using the Transaction Paid field. b) Direct application using invoice numbers. c) Like detail codes within the same term. d) Priorities. e) Refund to any priority. f) Negative charge to any priority. g) The sequence of application of payment

If a payment is the result of an exemption or a third party contract payment, an additional requirement must be met during the application process in order for the payment to apply to a charge transaction. The source code of the charge transaction must match the source code associated with the valid detail codes defined on TSACONT or TSAEXPT. The result of the Application of Payment Process may be viewed for each account on the Application of Payment Review Form (TSIAPPL or TFIAPPL). This form will show the charge detail code and the payment detail code and the amount applied.

Cashiering Procedure: Any Banner user who enters a charge and/or payment anywhere in the system will create a cashiering session for his/her user ID. Review and Close Cashiering Session:

a) At the end of the day (or period of activity), access the Cashier Session Review Form (TGACREV).

b) Enter the session user and the session number of 0 in the Key information and select Save.





c) In the Session Detail Selection information, enter the Category code of CSH (or the category code you have defined for cash, check, and credit card payments) and select Next Block to access the Cashier Session Summary information.

d) Totals are available by selecting Display Totals from the options menu. e) Select Next Block to access the Cashier Session Details window and view the

detail. Detail items will have the account ID number to reference. f) Select Close Session from the options menu or select Insert Record to close the

cashiering session. The session will now move to the User Sessions window where it will have a status of C.

Perform Supervisory Review: In Banner, a supervisor is defined on the User Profile Definition Form (TGAUPRF). If the supervisor/cashier relationship is being enforced on the Accounts Receivable Billing Control Form (TGACTRL), cashiers may be assigned to supervisors on the User Profile Definition Form (TGAUPRF). The supervisor user ID should have no cashiering activity tied to it. A supervisor is not allowed to finalize his/her own sessions; therefore, a supervisor user ID should only perform supervisory functions. The supervisor should have another user ID defined for daily cashiering and account activity.

a) The supervisor queries the Cashier Supervisory Form (TGACSPV). b) Review all active sessions to determine why they are active and if they should be

closed. c) Review all closed sessions. d) If there is a discrepancy in a closed session, the supervisor can access the Account

Detail Form (TFADETL) in supervisory mode by selecting Process Supervisor Adjustment from the options menu or by executing the Supervisor Adjustment function (Exit with Value) from the Key information. This will allow the supervisor to specify the user ID and session that needs to be adjusted. The Foreign Currency Detail Form (TSADETF) and the Account Detail Review Form (TSAAREV) may also be accessed in supervisory mode.

Finalize Cashiering Session:

a) On the Cashier Supervisory Form (TGACSPV), the supervisor now finalizes all closed cashiering sessions by changing the Status from C to F.

b) Cashier Detail Report (TGRCSHR) is then run with the parameter option to only report finalized sessions and then to update the finalized sessions to a status of R for reported. This will prevent the finalized sessions from the previous day from being reported again, because they now have a status of R.

c) Sessions could be closed / Finalized by the Cashier Session Close Process (TGRCLOS).





This process can close, finalize, close and finalize, or bypass cashiering sessions automatically. The ability to close and/or finalize, or bypass a session will be controlled based on the source of the records existing in the session. The user establishes which type of sessions can be automatically closed and/or finalized, or by-passed by building rules on the Charge/Payment Source Code Validation form (TTVSRCE). The process produces a report of closed and/or finalized sessions. If a session is set to close, or both close and finalize according to the values established on the Charge/Payment Source code Validation Form (TTVSRCE), and the process is executed with this parameter set to C or B, then the session will close when the process is executed.

Billing:

a) Bill Student Accounts: You can produce an invoice of items not previously billed for student accounts on an individual account basis by requesting that a bill be printed immediately online from the following forms: • Student Payment Form (TSASPAY) • Student Account Detail Form (TSADETL) • Foreign Currency Detail Form - Student (TSADETF) • Account Detail Review Form - Student (TSAAREV) • Student Course Registration Form (SFAREGS) Alternatively, you may request a batch process to invoice all accounts (TSRCBIL).

The online request of an invoice will not update the account as being billed. The batch process, when run in Statement mode, will update the bill date and begin aging the charges billed. All charges and payments are billed in detail one time. Any outstanding charges at the next billing cycle, which have not previously been paid and have a due date prior to the billing date, will be reflected as past due.

If a bill is requested online or through the batch process in Invoicing mode, any charges billed do not begin aging. Also, any charges and payments recorded in detail will still be eligible to be billed in detail when bills are requested in Statement mode.

b) Third Party Billing: The Third Party Billing Rules Form (TSATPRL) is used to define the rules that determine how Banner prints third party bills, and to establish the relationship between a third party rule code and how Banner will print bills which use that rule code. A rule code must be defined on the Third Party Billing Rules Code Validation Form (TTVTPRC) prior to using it on this form.





An invoice of items not previously billed may be produced, either for an individual third party account or for all third parties, via the batch process Third Party Billing Statement (TSRTBIL). An invoice may not be requested online for a third party.

The request of an invoice will not update a third party account as being billed; therefore charges and payments will be billed in detail when a bill is requested in Statement mode. No aging of invoiced charges occurs.

c) Schedule/Bill Procedure and Processing: The Student Billing Statement Process (TSRCBIL) produces a multiple page invoice/statement. It can also produce a schedule/bill document. A schedule/bill is a combination of a student's schedule of classes and an invoice of charges and credits.

There are two steps required to produce a schedule/bill: 1. Set up the schedule/bill parameters on the Schedule/Bill Rules Form

(TSASBRL). 2. Run the Student Billing Process (TSRCBIL) to produce a schedule/bill.

The key to the Schedule/Bill Rules Form is the schedule/bill rule code. This rule code is defined on the Schedule/Bill Rules Code Validation Form (TTVSBRC). A rules code should be defined for each set of schedule/bill parameters required by the institution. The schedule/bill rules consist of the following data: • Who gets a schedule/bill

The system determines who gets a schedule/bill using the parameters entered when submitting the Student Billing Statement Process (TSRCBIL) in conjunction with the data input on the Schedule/Bill Rules Form (TSASBRL).

• What items and item headings appear in the schedule portion: On the Schedule/Bill Rules Form (TSASBRL), you can indicate which data items will appear in the schedule portion. The available items are as follows:

o Part of Term Course Level o Course Reference Number (CRN) Course Status o Subject Meeting Days o Course Meeting Times o Section Building o Campus Room o Course Title Instructor(s) o Credit Hours Grading Mode

• What appears in the bill portion and how is it displayed:





This is defined by setting the parameters on the Schedule/Bill Rules Form (TSASBRL) to determine what the bill portion of the schedule/bill should look like.

• Messages: You may enter messages to be displayed on the schedule/bill document on the Schedule/Bill Rules Form (TSASBRL). The messages will display immediately following the billing information. An unlimited number of messages may be displayed; however, remember space considerations when supplying messages.

Produce Aging Reports The Aging Analysis Report (TGRAGES) is used to analyze past due accounts. It produces a list of accounts by billed date, due date, or effective date with up to three age-date range options. The Invoice/Statement Report (TSRCBIL or TSRTBIL) must have been run in STATEMENT mode in order to use billed or due dates. The report lists unpaid account balances within each age-date range in addition to future balances. The report control information gives totals by date range, future balance, and account balance.

Processing Holds/Releases Automatically By using automated hold/release processing, Banner can automatically assign holds to and release holds from a person or entity when specified conditions are met. To use this feature:

1. Create hold rule codes using the Auto Hold Validation Form (TTVRHLD). The Auto Hold Validation Form (TTVRHLD) is used to create and maintain the rule codes used in automated hold and release processing.

2. Define the hold rules using the Auto Holds Rules Form (TGAHOLD):

The Auto Hold Rules Form (TGAHOLD) is used to define the rules that determine whether an account will be placed on hold, and to establish the relationship between a hold rule code and the type of hold placed on an account.

Hold Type should be defined first in STVHLDD, in this form you can specify the scope of the hold (AR, Registration, Application, etc).

3. Run the Automated Hold Release Process (TGPHOLD):

The Automated Hold Release Process (TGPHOLD) automatically assigns or releases holds to students or entities based on criteria established on the Auto Holds Rules Form (TGAHOLD).





4. To review the student hold(s), Add or Release holds manually, use the Hold Information form (SOAHOLD).

Note: you can release the hold by changing the ‘To Date’ field to today or previous date.

Assess Penalty/Interest Charges The Assess Penalty/Interest Charges Report (TSRLATE) assesses penalty and interest charges for accounts with a past due balance. Interest charges are always based on percentage. Penalties and interest may be assessed on the outstanding balance, or on the outstanding balance for a specific detail category code. When a detail category code is selected, only past due detail items of that category will be summed together, to determine the amount outstanding to be used in the assessment calculations. Past due detail items are defined as transactions whose due date is less than or equal to the run date, and whose balance is not equal to zero. The Billing Processes (TSRCBIL) set the due date when run in STATEMENT mode. Since assessments are based on the balance or the past due detail items, it is highly recommended that the Application of Payments Process (TGRAPPL) be run before running the Penalty/Interest Process, especially when a particular category code is specified.

Contract/ Exemption Roll Process (TSRROLL) This process rolls contracts and exemptions to a new term, based on parameter values established when executing the process in conjunction with the criteria established on the Contract Authorization Form (TSACONT) and the Exemption Authorization Form (TSAEXPT). Execute this process when you are ready to roll contracts or exemptions to the next term. When creating a new contract or exemption, the default values will be obtained form the Student Billing Control Form (TSACTRL). Change the values on each contract or exemption record as necessary. Additionally, you have the option to roll information from one contract ID to another contract ID. This process incorporate the printing rule options established on the Third Party Rules Code Validation Form (TTVTPRC) and the Third Party Billing Rules Form (TSATPRL). This process allows for multiple exemptions per term.





Appendix (A) Banner Accounts Receivable Validation Tables

Form Code Form Description

STVHLDD Hold Type Code Validation Form TTVRHLD Auto Hold Validation Form TTVBILL Bill Code Validation Form TTVDCAT Detail Category Code Validation Form TTVDELI Delinquency Code Validation Form TTVDTYP Deposit Type Code Validation Form TTVECAT Entity Category Code Validation Form TTVPAYT Payment Type Code Validation Form TTVSBRC Schedule/Bill Rules Code Validation Form TTVSRCE Charge/Payment Source Code Validation Form TTVTBDS Term-Based Designator Validation Form TTVTPRC Third Party Billing Rules Code Validation

Form TVVAUTH Authorization Validation Form

Date post:	04-Apr-2018
Category:	Documents
Upload:	vuongcong
View:	227 times
Download:	2 times

Business Process Modeling Banner Accounts Receivable · Business Process Modeling Banner Accounts...

Documents