Setting Up Payment Application Rules
To set up payment application rules, use the Charge Priority List component (CHARGE_PRIORITY) and the Payment Overall Priority component (OVERALL_PRIORITY).
This section provides an overview of payment application rules and discusses:
Your institution probably has rules about how payments are to be applied to charges on student accounts. You may want tuition to always be paid first, or you may want the oldest charges paid first. In addition, many rules apply to financial aid. Regardless of your institution's specific rules, you want Student Financials to automatically apply them, eliminating the need to make immediate decisions about each payment.
Defining one set of rules that works for every situation is difficult. To meet all of your needs, you should carefully plan and define several sets of rules. You must understand how these rule sets work separately and with each other, and how they work with other parts of the system.
To make setup as flexible, yet precise, as possible, the system uses a combination of charge priority list and payment overall priority rules that are attached to payment item types. These very specific payment processing definitions are also affected by the default term, business unit posting rules, and priority values defined for payment item types.
Student Financials provides flexible payment processing capabilities, but setup requires considerable thought. While complex, the process is logical and accommodates most payment application schemes. Plan well and take the time to test your setup extensively.
Before you start setting up your charge priority list and payment overall priority rules, be sure to check your item type tree setup. Because your charge priority definition depends on your item type tree, the tree must be set up correctly. For example, all item types that are related to tuition should be grouped together under a tree node named Tuition. The same applies to housing and parking item types. Your actual item type tree setup may use different terminology, but the structure must include nodes similar to these examples. Also, make sure that the same item type number has not been included in more than one tree node.
See the product documentation for PeopleTools: Tree Manager.
Charge Priority List Rules
Defining charge priority rules is the first step in determining how the system applies a payment. You define exactly what charges are eligible for payment under a particular rule set. You also define whether payments can be applied to charges from various time periods and you can establish a priority order for allowed charges.
Charge priority lists depend on item type trees to identify which charge items are qualified for the particular type of payment. Because charge priority list details are defined at the tree node level, you can make payment restrictions as broad or narrow as you want.
Warning! You must not specify a parent and child node on a charge priority list. Doing this may cause unusual payment application issues because a charge will be selected twice: one from the parent and another from the child.
If you try to specify a parent and child node on a charge priority list, a message appears and warns against overlapping nodes. You will not be able to save the charge priority list. This message affects only current and future effective-dated rows.
Payment Overall Priority Rules
Payment overall priority rules define the order of payment allocation when payments do not fully cover all eligible charges. You have two options when defining payment overall priority rules. Either your payment overall priority can act as a tiebreaker, or it can pay all eligible charges equally.
|
Page Name |
Definition Name |
Navigation |
Usage |
|---|---|---|---|
|
Charge Priority List |
ITEM_CHRG_TYP_PRTY |
|
Create a charge priority list and link it to an item type tree. |
|
Charge Priority List - Details |
ITEM_CHRG_TYP_PRT2 |
|
Define charge priority list rules. |
|
Payment Overall Priority |
PAY_PRIOR_ALL |
|
Define payment overall priorities. |
Access the Charge Priority List page ().
Image: Charge Priority List page
This example illustrates the fields and controls on the Charge Priority List page. You can find definitions for the fields and controls later on this page.
|
Field or Control |
Definition |
|---|---|
| Tree Name |
Select the name of the item type tree that includes all item types to be paid under this charge priority list. |
Access the Charge Priority List - Details page ().
Image: Charge Priority List - Details page
This example illustrates the fields and controls on the Charge Priority List - Details page. You can find definitions for the fields and controls later on this page.
Self service student permissions can be used for a student to grant permission.
|
Field or Control |
Definition |
|---|---|
| Permission Form |
Select a permission form if you want one to apply. A permission form is a type of advance permission that the system uses with item types that have payment application restrictions. When you select a permission form, the system applies the charge priority definition only if the permission form has been attached to the student. Permission forms are commonly used with financial aid payment. For example, if a particular type of financial aid award restricts payments to the current term charges unless permission is given by the student to pay prior term charges, then a permission form can grant that permission. The permission form must be attached to the charge priority list definition that is set to Permission for the prior term. |
| Use Aid Year |
Select to use the financial aid year for the charge priority list. When the flag is off (cleared), current functionality applies and the academic year is used. |
| Tree Node |
Select allowable charges by entering the appropriate tree nodes. The system applies payments only to charge item types that fall in the range of the tree node. Warning! You must not specify a parent and child node on a charge priority list. Doing this may cause unusual payment application issues because a charge will be selected twice: one from the parent and another from the child. When you try to specify a parent and child node on a charge priority list, a message appears and tells you the charge priority list cannot be saved because of overlapping nodes. The message only appears for current and future-dated rows. Warning! If you want to use the pay proportionate % tax functionality that is available in Payment Overall Priority setup (see the following field description), the tax item type must not be included within the range of allowable charges. If it is included within the range, the system treats it as any other eligible charge and it does not distinguish it as unique. |
| Priority |
Assign a priority level for each tree node that is used to define allowable charges. The system uses this priority value only when you select Charge Tree Node as one of the Sort Payment Field values in your Payment Overall Priority setup. A priority of 1 is higher than a priority of 2. |
| Current Term |
Select a value to control whether payments can be applied to charges for the current term. Four values are available for this field: Yes: Select this value if you want the system to apply payments with no restrictions to charges in this time period. No: Select this value if you do not want the system to apply payments to any charges in this time period. Neg. Perm: (negative permission) Select this value if you want the system to apply payments as necessary to charges in this time period, unless the student expressly prevents it. Student permissions can be used in conjunction with negative permission. Permission: Select this value if you want the system to require specific permission before applying payments to charges in this time period. Student permissions can be used in conjunction with permission needed. Note: The definition of the Current Term value is determined by the value of the payment term. If no term is specified, the value of the payment term is determined by the Default Term Control value in the SF Business Unit component. Three options are available for default term control: Use SF Default Term, Use Last Enrollment Term, and Use Current Enrollment Term. When you use SF Default Term, the value of the payment term is the same as that of the SF default term. If you use either Last Enrollment Term or Current Enrollment Term as the default term control, the value of the payment term varies by the enrollment history of the student against whose account the payment is being applied. |
| Prior Term |
Select a value to control whether and how payments can be applied to charges for the prior term. The four values for this field are the same as those defined for the Current Term field. The prior term is the academic term that immediately precedes the current term. The actual determination of the prior term is based on the value that is used for the current term. Values are: Use Aid Year OFF:All terms prior to the current term within the academic year only. Use Aid Year ON:All terms prior to the current term within the current aid year only. |
| Prior Year |
Select a value to control whether and how payments are applied to charges for the prior year. The four values for this field are the same as those defined for the Current Term field. Use Aid Year OFF:All terms prior to the current academic year. Use Aid Year ON:All terms prior to the current term that are in the aid year immediately prior to the current aid year. |
| Future Term |
Select a value to control whether and how payments can be applied to charges for any future terms. The four values for this field are the same as those defined for the Current Term field. A future term is an academic term that comes after the current term. The actual determination of a future term is based on the value that is used for the current term. Use Aid Year flag OFF: A future term is an academic term that comes after the current term. The actual determination of a future term is based on the value that is used for current term. Use Aid Year flag ON: All terms after the current term within the current aid year. |
| Amount |
Enter the maximum amount that can be applied to the corresponding period. If no limitation exists for this payment, leave the amount field blank on all platforms except for DB2. If the amount is left blank on a DB2 platform, it functions as if it is zero and does not allow any amounts to be paid by the payment. On DB2 platforms only, you must complete the amount field with all 9s (a value of 999,999,999.00) to allow for no limitation. The field is formatted for 12.2 number entries. |
Example of a Charge Priority List Selection
Charge priority setup can be confusing, and small differences can sometimes yield surprising results. It is not possible to provide examples of all scenarios, but the following examples present two common outcomes.
Remember that any charge that is qualified for payment by the charge priority selection is considered equal and can be paid according to the rules of the definition. This is why tax item types must be excluded from the range of allowable charges if you want to pay them proportionate to the payment against the charge. If they were included within the range of allowable charges, the tax could be paid in full, or not at all, regardless of the amount paid on the associated charge.
Using our sample charges, and a charge priority list allowing charges from the Tuition, Housing, Miscellaneous, and Parking tree nodes, examine the following two scenarios and see how minor changes can affect payment application. In each case, the SF Business Unit Default Term Control is set to use the value Last Enrollment Term. For purposes of this example, assume that the student's last completed term of enrollment is Fall, 2000 and no term is specified with the payment (causing the system to use the SF Business Unit Default Term Control value—this point is important to understanding these examples).
Sample Charges
|
Transaction Type |
Tree Node |
Term |
Charge Amount |
Due Date |
|---|---|---|---|---|
|
Tuition Charge |
Tuition |
Fall, 1999 |
500.00 USD |
October 15, 1999 |
|
Housing Charge |
Housing |
Fall, 1999 |
1,000.00 USD |
October 30, 1999 |
|
Phone Charge |
Other |
Fall, 1999 |
100.00 USD |
October 30, 1999 |
|
Tuition Charge |
Tuition |
Spring, 2000 |
2,000.00 USD |
February 15, 2000 |
|
Tuition Charge |
Tuition |
Fall, 2000 |
2,000.00 USD |
October 5, 2000 |
|
Housing Charge |
Housing |
Fall, 2000 |
700.00 USD |
October 5, 2000 |
|
Misc. Charge |
Miscellaneous |
Fall, 2000 |
75.00 USD |
October 1, 2000 |
|
Housing Charge |
Housing |
Fall, 2000 |
200.00 USD |
February 1, 2001 2 |
|
Tuition Charge |
Tuition |
Spring, 2001 |
1,800.00 USD |
January 15, 2001 |
|
Housing Charge |
Housing |
Spring, 2001 |
1,050.00 USD |
February 5, 2001 |
|
Misc. Charge |
Miscellaneous |
Spring, 2001 |
50.00 USD |
February 5, 2001 |
Selected Charges—Scenario One
When the student makes a payment to the account, the charge priority list rules allow the following charges to be selected as eligible for payment:
|
Transaction Type |
Tree Node |
Term |
Charge Amount |
Due Date |
|---|---|---|---|---|
|
Tuition Charge |
Tuition |
Fall, 1999 |
500.00 USD |
10/15/99 |
|
Housing Charge |
Housing |
Fall, 1999 |
1,000.00 USD |
10/30/99 |
|
Tuition Charge |
Tuition |
Spring, 2000 |
2,000.00 USD |
2/15/00 |
|
Tuition Charge |
Tuition |
Fall, 2000 |
2,000.00 USD |
10/5/00 |
|
Housing Charge |
Housing |
Fall, 2000 |
700.00 USD |
10/5/00 |
|
Misc. Charge |
Miscellaneous |
Fall, 2000 |
75.00 USD |
10/1/00 |
|
Housing Charge |
Housing |
Fall, 2000 |
200.00 USD |
2/1/01 |
|
Tuition Charge |
Tuition |
Spring, 2001 |
1,800.00 USD |
1/15/01 |
|
Housing Charge |
Housing |
Spring, 2001 |
1,050.00 USD |
2/5/01 |
|
Misc. Charge |
Miscellaneous |
Spring, 2001 |
50.00 USD |
2/5/01 |
Comparing the two tables, you can see that the only item not included in the set of eligible charges is the phone charge. The reason for this is that the charge priority list example given previously allows payments for charges from four tree nodes: Tuition, Housing, Miscellaneous, and Parking. The Phone charge is under the tree node of Other and, therefore, is not considered an eligible charge. Also, because payments can be applied to all time periods (current term, prior term, prior year, and future term), the system can include all active charges.
Selected Charges—Scenario Two
If you use a different charge priority setup that excludes payments for a future term on each of the allowable charge nodes, the results are considerably different:
|
Transaction Type |
Tree Node |
Term |
Charge Amount |
Due Date |
|---|---|---|---|---|
|
Tuition Charge |
Tuition |
Fall, 1999 |
500.00 USD |
10/15/99 |
|
Housing Charge |
Housing |
Fall, 1999 |
1,000.00 USD |
10/30/99 |
|
Tuition Charge |
Tuition |
Spring, 2000 |
2,000.00 USD |
2/15/00 |
|
Tuition Charge |
Tuition |
Fall, 2000 |
2,000.00 USD |
10/5/00 |
|
Housing Charge |
Housing |
Fall, 2000 |
700.00 USD |
10/5/00 |
|
Misc. Charge |
Miscellaneous |
Fall, 2000 |
75.00 USD |
10/1/00 |
|
Housing Charge |
Housing |
Fall, 2000 |
200.00 USD |
2/1/01 |
In this case, the system does not include charges for Spring, 2001 because they are associated with a future term. This is because you established the current term as the last enrollment term when you defined your default term control. In this case, the last enrollment term is Fall, 2000. If you change the Default Term Control value to Use SF Default Term, the system will again include all charges because the current term will be Spring, 2001.
In summary, your charge priority definitions determine what charges are eligible for payment. This determination is made by limiting payments to charge item types that meet specific criteria that are related to tree nodes and time periods.
Access the Payment Overall Priority page ().
Image: Payment Overall Priority page
This example illustrates the fields and controls on the Payment Overall Priority page. You can find definitions for the fields and controls later on this page.
|
Field or Control |
Definition |
|---|---|
| Allocation Method |
Select an allocation method: By Oldest First: Select if you want to use sort payment fields to sort the eligible charges. If you select this option, the last sort is to order the eligible charges by the oldest item number first. Equal Percentages: Select if you want to pay an equal portion of each eligible charge. If you elect to pay by equal percentages, the sort payment fields are not used. |
| Pay Proportionate % Tax |
Select if you want all taxes associated with a particular charge to be paid proportionate to the payment against the charge. Payment of taxes follows the same payment priority as the associated charge. Note: For pay proportionate % tax functionality to work, the tax item type cannot be included as an allowable charge in the charge priority setup. Make sure that the tax item type is not included within the range of any of the tree nodes that are selected as allowable charges. |
Charge Sort
You can define up to four charge sort criteria. Remember that all sort rules defined for Payment Overall Priority apply only to charges already selected by the Charge Priority rules. For example, if your Charge Priority rules are set up to select charges for current and future terms only, and your Payment Overall Priority rules are set up to sort by Term, Oldest First, the term that is defined as current will be the oldest term available.
|
Field or Control |
Definition |
|---|---|
| Sort 1 Sort 2 Sort 3 and Sort 4 |
A number of possible values exist for each sort field: Academic Year: Select to sort active charges by academic year, beginning with active charges from the earliest year. Academic Year, Current First: Select to sort active charges by the academic year, using the current academic year first. After the system selects eligible charges for the current academic year, it sorts the remaining charges by academic year from the oldest to the most recent. Charge Tree Node: Select to sort active charges by the priority value of the charge tree nodes that are established in the charge priority list definition being used. Item Charge Due Date: Select to sort active charges by charge due date, beginning with the active charge with the earliest due date. If restricting corporate payments for third-party contract functionality, do not use the Payment Overall Priority of sorting by Item Charge Due Date. For non-contract corporate payments, you can use the Payment Overall Priority of sorting by Item Charge Due Date. Term, Current First: Select to sort active charges by term, using the current term first. You determine the definition of the current term using the Default Term Control field on the Posting Setup page of the SF Business Unit component. Therefore, it is not necessarily the chronological current term. After the system selects eligible charges for the current term, it sorts the remaining charges by term from the oldest to the most recent. Term, Oldest First: Select to sort active charges by terms, using the oldest term first. Term, Payment Term First: Select to sort active charges by terms, using the term for which the payment applies first. If no term is specified with the payment, the system uses the SF default term. After the system selects eligible charges for the payment term, it sorts the remaining charges by term from the oldest to the most recent. Oldest Invoice Date: Select if you want the posting to gather the charges by invoice. This value is available only if the Apply Payments by Invoice flag is selected on the SF Installation setup. |
Example of How Payment Overall Priority Sorts Eligible Charges
Using our sample set of charges, look at how charge priority and payment overall priority rules work together to control payment application. Suppose that a student makes a payment of 8,000.00 USD against his or her account. Consider the following two setup scenarios to understand how differently payments are applied.
Sample Charges
|
Transaction Type |
Tree Node |
Term |
Charge Amount |
Due Date |
|---|---|---|---|---|
|
Tuition Charge |
Tuition |
Fall, 1999 |
500.00 USD |
10/15/99 |
|
Housing Charge |
Housing |
Fall, 1999 |
1,000.00 USD |
10/30/99 |
|
Phone Charge |
Other |
Fall, 1999 |
100.00 USD |
10/30/99 |
|
Tuition Charge |
Tuition |
Spring, 2000 |
2,000.00 USD |
2/15/00 |
|
Tuition Charge |
Tuition |
Fall, 2000 |
2,000.00 USD |
10/5/00 |
|
Housing Charge |
Housing |
Fall, 2000 |
700.00 USD |
10/5/00 |
|
Misc. Charge |
Miscellaneous |
Fall, 2000 |
75.00 USD |
10/1/00 |
|
Housing Charge |
Housing |
Fall, 2000 |
200.00 USD |
2/1/01 |
|
Tuition Charge |
Tuition |
Spring, 2001 |
1,800.00 USD |
1/15/01 |
|
Housing Charge |
Housing |
Spring, 2001 |
1,050.00 USD |
2/5/01 |
|
Misc. Charge |
Miscellaneous |
Spring, 2001 |
50.00 USD |
2/5/01 |
In the previous section on setting up a charge priority list, the setup example shown selects charges using four Item Type Tree nodes (Tuition, Housing, Miscellaneous, and Parking) and allows payments to be applied in all time periods. Using this rule set, the system selects all of the charges on the student's account as eligible, with the exception of the phone charge.
Selected and Sorted Charges—Scenario One
Using the Payment Overall Priority setup shown previously (eligible charges sorted first by due date, then by charge tree node), the system sorts the eligible charges in this way:
|
Transaction Type |
Tree Node |
Term |
Charge Amount |
Due Date |
|---|---|---|---|---|
|
Tuition Charge |
Tuition |
Fall, 1999 |
500.00 USD |
10/15/99 |
|
Housing Charge |
Housing |
Fall, 1999 |
1,000.00 USD |
10/30/99 |
|
Tuition Charge |
Tuition |
Spring, 2000 |
2,000.00 USD |
2/15/00 |
|
Misc. Charge |
Miscellaneous |
Fall, 2000 |
75.00 USD |
10/1/00 |
|
Tuition Charge |
Tuition |
Fall, 2000 |
2,000.00 USD |
10/5/00 |
|
Housing Charge |
Housing |
Fall, 2000 |
700.00 USD |
10/5/00 |
|
Tuition Charge |
Tuition |
Spring, 2001 |
1,800.00 USD |
1/15/01 |
|
Housing Charge |
Housing |
Fall, 2000 |
200.00 USD |
2/1/01 |
|
Housing Charge |
Housing |
Spring, 2001 |
1,050.00 USD |
2/5/01 |
|
Misc. Charge |
Miscellaneous |
Spring, 2001 |
50.00 USD |
2/5/01 |
In this example, all charges with due dates through 10/5/00 will be paid in full and 1,725.00 USD will be applied to the Spring, 2001 Tuition charge due 1/15/01. Because not enough money exists to pay all charges in full, the system applies the payment to the charges in order of the due date.
Also, note that two charges are due 10/5/00 and also two are due on 2/5/01. The system sorted these charges in order of their charge tree node priority. Recall that in the charge priority setup, the Tuition node is given a priority of 1, Housing a priority of 2, and Miscellaneous and Parking a priority of 3.
Selected and Sorted Charges—Scenario Two
If you use a payment overall priority that reverses the order of the sort payment fields (charge tree node first and charge due date second), the results are very different. In this case, the system sorts the eligible charges in the following way:
|
Transaction Type |
Tree Node |
Term |
Charge Amount |
Due Date |
|---|---|---|---|---|
|
Tuition Charge |
Tuition |
Fall, 1999 |
500.00 USD |
10/15/99 |
|
Tuition Charge |
Tuition |
Spring, 2000 |
2,000.00 USD |
2/15/00 |
|
Tuition Charge |
Tuition |
Fall, 2000 |
2,000.00 USD |
10/5/00 |
|
Tuition Charge |
Tuition |
Spring, 2001 |
1,800.00 USD |
1/15/01 |
|
Housing Charge |
Housing |
Fall, 1999 |
1,000.00 USD |
10/30/99 |
|
Housing Charge |
Housing |
Fall, 2000 |
700.00 USD |
10/5/00 |
|
Housing Charge |
Housing |
Fall, 2000 |
200.00 USD |
2/1/01 |
|
Housing Charge |
Housing |
Spring, 2001 |
1,050.00 USD |
2/5/01 |
|
Misc. Charge |
Miscellaneous |
Fall, 2000 |
75.00 USD |
10/1/00 |
|
Misc. Charge |
Miscellaneous |
Spring, 2001 |
50.00 USD |
2/5/01 |
The system pays in full all Tuition charges and those Housing charges through the October 5, 2000 due date. This is because the system sorts charges first by charge tree node and second by the charge due date.
In summary, your Payment Overall Priority definition determines how the system sorts eligible charges (selected by your corresponding charge priority definition) to allocate payment.