Completing Student Financials General Setup

This chapter provides an overview of Student Financials general setup and discusses how to:

• Set up installation parameters and keywords.

• Review valid records and fields.

• Set up business units.

• Set up tax authorities and tax codes.

• Set up aging sets.

• Set up payment application rules.

• Set up account types.

• Set up item types and item type groups.

• Set up service indicators.

• Set up a default academic term.

Understanding Student Financials General Setup

A substantial amount of setup is required before you can use Student Financials. The setup described in this chapter establishes the framework for everything that follows. Take enough time and resources now to build a strong foundation, which you can add to later. You do much of this setup once, and modify it rarely, if ever. You use other parts repeatedly as the system expands and changes.

Be aware that PeopleSoft Campus Solutions is an integrated system and coordination between departments and applications is essential to the success of your implementation.

Setting Up Installation Parameters and Keywords

To set up installation parameters and keywords, use the Student Fin Installation component (INSTALLATION_SF) and the Keywords component (KEYWORDS).

This section provides an overview of installation parameters and keywords, and discusses how to:

• Define number sequence start points, and maximum row settings.

• Define keyword edit tables and a null due date.

• Define commit levels.

• Define keywords.

Understanding Installation Parameters

Installation parameters define how Student Financials looks and performs. You specify how the system:

• Numbers certain elements.

• Displays results for various functions.

• Determines the frequency for committing work to the database.

You can change most of these settings at anytime without any negative impact. In fact, you should experiment with your settings in order to strike the proper performance balance. PeopleSoft provides default settings for many of these parameters, but review them to make sure that they work well for your institution.

Keywords

Key words enable you to quickly locate item types within a long list of possibilities. For example, you might have dozens of payment item types, but only a handful that are related to scholarships. By defining Scholarship as one of your key words and associating it with the select few item types, it will be much easier to locate just the item type you need. You can define up to three keywords per item type. Keywords are associated with edit tables and you must select the appropriate edit table to use for each key word.

Note. Because PeopleSoft Student Financials, Financial Aid, and Contributor Relations all use keywords, we recommend Student Financials, Financial Aid, and Contributor Relations staff work together to define a keyword standard for your institution.

Pages Used to Set Up Installation Parameters and Keywords

Defining Number Sequence Start Points and Maximum Row Settings

Access the SF Installation page.

Process Group	Enter a value for the process group. The system uses the process group in conjunction with G/L Combination processes.
Last Batch ID	Each batch transaction is assigned an ID number. This field displays the last ID number assigned to a batch. To start your numbering sequence at a particular point, enter a number here. Otherwise, the system continues to increment subsequent batch transactions from the number shown.
Last Origin ID	Use origin IDs to track the source of batch transactions (for example, receipts from the housing or parking offices). This field displays the last ID number assigned to an origin definition. To start your numbering sequence at a particular point, enter a number here. Otherwise, the system continues to increment subsequent origin definitions from the number shown.
Edit Combinations	Select this option if you use combination edits in your general ledger processing. Consult your financials staff to determine how to set this option.

Maximum Row Settings Group Box

For each field in this group box, enter the maximum rows of results that you want to display on a page at one time.

See Also

Defining Origins and Group Types

Understanding GL Interface Processing

Understanding Refunds

Defining Keyword Edit Tables and a Null Due Date

Access the SF Installation 2 page.

Key Word	Select an edit table to use for your first level Key Word values.
Key Word 2	Select an edit table to use for your Key Word 2 values.
Key Word 3	Select an edit table to use for your Key Word 3 values.
Null Due Date	Enter a date that you want the system to use when no other form of due date is specified. Charges with a null due date display as future charges. PeopleSoft recommends that you select a date well into the future. This date appears on the Total Due Charges page of the self-service portion of Student Financials.

Defining Commit Levels

Access the SF Installation 3 page.

Application Fee, Deposit Fee, Late Fee, and 1098–T Data Commit Level Group Boxes

The selections that you make in the following fields control how often the system commits batched application, deposit, 1098–T, and late fee transactions to the database.

Defining Keywords

Access the Keywords page.

Keyword Nbr (keyword number)

Select the keyword number for this keyword. Each keyword is associated with an edit table that is set up in SF Installation.

Reviewing Valid Records and Fields

To set up records and fields, use the Valid Records component (VALID_RECORD_SF) and the Valid Fields component (VALID_FIELDS).

Student Financials makes certain valid records (tables) and fields available for users to review. It is possible to modify these records and fields, but it is not advised. This section discusses how to:

• Review valid records.

• Review valid fields.

Pages Used to Review Valid Records and Fields

Reviewing Valid Records

Access the Valid Records page.

Record (Table) Name

The record (table) name used in the tuition calculation setup appears when you open the page. Because this information is delivered with the system, be careful whenever you plan to make changes to it.

Reviewing Valid Fields

Access the Valid Fields page.

Record	This field displays the record name. The system provides the default selection for this field.
Description	This field displays the record description. The system provides the default selection for this field.
Field	This field displays the field name. The system provides the default selection for this field.
Edit Table	This field displays the edit table associated with the record. The system provides the default selection for this field.

Setting Up Business Units

To set up business units, use the SF Business Unit component (BUSINESS_UNIT_SF).

This section provides an overview of business units and discusses how to:

• Define basic business unit parameters.

• Define additional business unit parameters.

• Define posting parameters.

• Define committal and approval options.

• Define collection rules.

• Define basic refunding rules.

• Define refund approval parameters.

• Define default payroll interface parameters.

• Define auto-numbering sequences.

• Define tax parameters for students from Canada, Australia, and New Zealand (includes Tax Calculation Options).

Understanding Business Units

The SF business unit is the framework that controls all processing within the Student Financials application. Each business unit can have its own set of business rules. For example you might have different campuses that operate independently from each other financially. By setting up different business units, you have the flexibility of defining just what you need. You must set up at least one business unit.

Pages Used to Set Up Business Units

Defining Basic Business Unit Parameters

Access the General 1 page.

Base Currency	Confirm or select the base currency that you want this business unit to use. The default value is the base currency selected for the institution under Set Up HRMS, Install, Installation Table, HRMS Options. You can override the base currency for each business unit.
Exchange Rate Type	Select the exchange rate type that you use to convert other currency types to the base currency. The exchange rate type is necessary for the posting of charges. Note. You define exchange rate types on the Currency Rate Type page (same navigation as above).
Academic Institution	Identify the academic institution that contains the SF Business Unit.
Campus	Select the appropriate campus for the SF Business Unit.
Location	Select the appropriate location for the SF Business Unit.
General Ledger Unit	If your institution uses PeopleSoft Financials, select the General Ledger Unit that receives information from the SF Business Unit. Otherwise, leave this field blank.
Accounting Method	Select your institution's accounting method: Accrual, Cash, or Modified Cash accounting.
AP Business Unit	Select the business unit to which your system interfaces when processing refunds through the accounts payable department.

Defining Additional Business Unit Parameters

Access the General 2 page.

Display Ethnicity Online	Select this option if you want the student’s ethnicity to appear on the Academic Information page.
Display Campus ID Online	Select this option if you want the campus ID to appear on the Academic Information page. The campus ID identifies the campus, not the student.
Display National ID Online	Select this option if you want the student’s national ID (for example, social security number) to appear on the Academic Information page.
Address Usage Billing	Select a default address usage type to use when you generate customer bills.
Name Usage	Select a default name usage type.
Term/Class Cancel Reason	Select a term/class cancellation code that you want to use as the default reason when you run the term/class cancellation process.
Aging Set	Select the aging set that the system uses by default for the Assign Collector process.
Service Indicator Set	Select the service indicator set that you want to use. This service indicator set must include all service indicators you want to use for credit history processing.
Tuition Calc Required Default (tuition calculation required default)	Select Yes, if you want the Tuition Calc Required flag set automatically when a student is activated in a term. Use this option if you want tuition to be calculated on Anticipated Units. Select No, if you do not want the Tuition Calc Required flag set automatically when a student is activated in a term. Use this option if you want tuition fees calculated only after enrollment activity (Bill Units).
Maintain GL Interface History	Select this option if you want the system to maintain general ledger interface history. This selection is required to use the Back Out GL Interface functionality.
Calc Tuition after Grade Post (calculate tuition after grade post)	Select this option if you want the Tuition Calc Required flag to be set to yes whenever student grades are posted or changed through the Grade Roster page. Note. This check box does not affect the Tuition Calc Required flag being set to yes when grades are posted or changed through the Enrollment pages.
Load Criteria Table	Select this option if you want the criteria tables (for example, Career, Program, Fee Triggers, and so on) to be loaded into working storage at the beginning of the Tuition Calculation process. Selecting this option can improve Tuition Calculation process performance. Note. If there are more than 100 total criteria values, this option must not be selected. Working storage is currently limited to 100 maximum values.
Accept Self-Service Payments	Select this option if you want to allow students to make payments over the web using ePayments. This selection is limited to this SF business unit. This SF business unit must also be attached to an institution set that enables self-service payments. Unless self-service payments are enabled for both the SF business unit and the institution set, students will only have access to one of the self-service pages (Account Inquiry). See Setting Up Self-Service Student Financials.

Defining Posting Parameters

Access the Posting Setup page.

QUICK_POST_TBL Purge Control

Student Post (Quick Post) and Corp Post transactions are recorded in the Quick Post Table. These entries can be consolidated into posting groups using the Purge QUICK_POST_TBL process. The options in this group box create entries in the Group Control Record that enable you to easily track Student Post transactions.

Credit Processing

Set the conditions that you want the system to use when credits (payments) are posted on an account.

Reference Number Posting Usage

This group box provides additional options for the posting of debits and payments.

See Also

Setting Up Receivables Maintenance

Consolidating and Reviewing Transactions for Individual Students and Organizations

Setting Up Payment Application Rules

Defining Committal and Approval Options

Access the Commit Options page.

Important! The selections that you make in this page have a specific effect on processing. Consult with your IT staff and system administrators to determine the optimum selections for your processing needs.

Group Posting

Set the levels at which group post transactions are committed to the database.

GL Posting

Set the levels at which general ledger transactions are committed to the database.

Billing Commit Option

Set the levels at which billing transactions are committed to the database.

See Also

Enterprise PeopleTools PeopleBook: Workflow Technology

Defining Collection Rules

Define the rules governing how your business unit handles receivables collection.

See Also

Setting Up Receivables Collection

Defining Basic Refunding Rules

Specify the business unit rules governing how the system handles refunds.

See Also

Setting Up Your Business Unit to Refund Customers

Defining Refund Approval Parameters

Set refund approval levels for student and organization refunds.

See Also

Setting Up Your Business Unit to Refund Customers

Defining Default Payroll Parameters

Establish default parameters for refunds created using PeopleSoft Payroll for North America.

See Also

PeopleSoft Enterprise Payroll for North America 8.9 PeopleBook, “Setting Up the Payroll Process”

Defining Auto-numbering Sequences

Access the Counters page.

With the exception of Payment Plans, the counter number fields on this page automatically display the last number used. You have the option of specifying a number with which you would like the sequence numbering to begin. For example, if you want cashiering receipt numbers to begin at 1,000, enter the number 999 in the Last Cashiering Receipt Number field. The system automatically assigns the number 1,000 to the first receipt produced and increments all receipts by 1 thereafter.

Group Posting

Payment Plans

(CAN)(AUS)(NZL) Defining Tax Parameters for Students from Canada, Australia, and New Zealand

Access the Canadian/ANZ Taxes page.

T4A Generation Setup

Canadian students are required to report all scholarship income. The T4A report is generated for the student’s use.

The following fields define the setup needed to transfer information from the Student Financials application to the PeopleSoft Payroll for North America application for the processing and generation of T4A reports. Consult with your payroll staff to determine the proper selections for the following options.

Date Type Selection

In this group box, select the type of date that you want to use to govern selection of items to be included in the T4A report. The system uses the date type selection in conjunction with the balance ID to control which transactions it includes in the report.

Cdn GST Registration Number

Enter the GST Reg No (Goods and Services Tax registration number) assigned to this business unit. The system uses this value for any receipts and invoices that are specifically designed to include the GST registration number when GST is assessed.

Australia/New Zealand Taxes

Note. Student Financials rounds based on the third decimal place of a number.

Setting Up Tax Authorities and Tax Codes

To set up tax authorities and tax codes, use the Tax Authorities component (TAX_AUTHORITY) and the Tax Codes component (TAX_CODE_VAT).

This section provides and overview of tax authorities and tax codes, and discusses how to:

• Define a tax authority.

• Specify VAT rebates for tax authorities.

• Define tax codes.

Understanding Tax Authorities and Tax Codes

Your institution may be under the jurisdiction of one or more tax authorities that require you to charge taxes for certain transactions. To process tax charges, you must define one or more tax authority codes.

Tax codes are used to link taxes to charge item types. Each tax code must include at least one tax authority, but can include more than one if your institution is subject to more than one taxing authority. For example, you may need to charge students both state and local sales taxes for books. By setting up a tax code that combines the two authorities, you can charge both taxes.

Pages Used to Set Up Tax Authorities and Tax Codes

Defining Tax Authorities

Access the Tax Authority page.

Tax Code Type	Select a tax code type of S (sales tax) or V (value added tax).
Percent	Set the default percentage of tax the authority assesses.
Same Account and Acct Type (account type)	Select the Same Account check box if you want the tax assessed to appear in the same account as its associated charge. If you clear the check box, you can select a different account type in the Acct Type field.
Item Type	Select the item type that you have defined for transactions from this tax authority.
Service Impact	Select the service impact that exempts customers from this taxation.

Specifying VAT Rebates for Tax Authorities

Access the Tax Authorities - Rebate page.

VAT PSB Type (value added tax public service body type) and Rebate Rate

If applicable, select the value added tax public service body type and enter a rebate rate.

Defining Tax Codes

Access the Tax Codes page.

Consolidate Same Item Type	If you are creating a code that combines two or more different tax authorities, you can select this check box to consolidate the tax transactions that make up the code into the same item type during posting. Otherwise, the system creates each transaction on an account as individual entries.
Authority	Select the tax authority that you want to attach to the tax code.
Percentage	The default percentage displays to the right of each authority that you add.

Setting Up Aging Sets

To set up aging sets, use the Aging Set component (AGING_TABLE).

An aging set is a complete set of aging categories that defines how your system ages your accounts. You can define multiple aging sets to be used for different types of customers. For example, you might want to age student accounts differently than you do organization accounts.

Pages Used to Set Up Aging Sets

Defining Aging Sets

Access the Aging Set page.

Basis Date	Select the basis date that you want to use when a charge is assigned to an aging category. Options are: Actual Billing Date, Billing Date, Current Due Date, and Original Due Date.
Dispute Aging	In the Dispute Aging and Category fields, define how you want to categorize any charges in dispute. Age Normal: Select if you want to age disputed charges like any other charge. When you select this option, disputed charges can still show up as being past due and can trigger collection actions. Categorize: Select if you want disputed charges to be distinguished as a unique category. When you select this option, the Category field becomes active. Ignore: Select if you want the system to overlook disputed charges. When you select this option, the system does not distinguish disputed charges as a unique category and does not age them like other charges. In addition, disputed charges do not trigger collection actions.
Category	Enter the category value that you want to use for disputed charges.
Aging Category	Enter an aging category value that you want to use to distinguish each time range. In the field to the right, enter a description of the particular category.
Start Days and End Days	Enter the beginning and ending points of the aging category. For example, if charges up to thirty days old are considered current, enter 0 in the Start Days field and 30 in the End Days field. The beginning and ending point of the range are controlled by the Basis Date.
Summ (summary)	Select a code to identify the late charge category: C (current due), D (dispute due), F (future due), O (other), or P (past due).
Cr Ch (credit check)	This check box is reserved for future use.

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 how to:

• Create a charge priority list and link it to an item type tree.

• Define charge priority list rules.

• Define payment overall priorities.

Understanding Payment Application Rules

Your institution probably has rules about how payments are to be applied to charges on student accounts. You may always want tuition to be paid first, or you may want the oldest charges paid first. In addition, there are many rules that apply to financial aid. Regardless of your institution's specific rules, you want Student Financials to automatically apply them, eliminating the need to make on-the-spot decisions about each payment.

Obviously, 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, 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 impacted by the default term, business unit posting rules, and priority values defined for payment item types.

PeopleSoft 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 over 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 related to tuition should be grouped together under a tree node named Tuition. Likewise with 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.

Charge Priority List Rules

Charge priority rules are 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 if payments can be applied to charges from various time periods and you can establish a priority order for allowed charges.

Charge priority lists are dependent 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 would like.

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.

See Also

Enterprise PeopleTools PeopleBook: Tree Manager

Pages Used to Set Up Payment Application Rules

Creating a Charge Priority List and Linking it to an Item Type Tree

Access the Charge Priority List page.

Tree Name

Select the name of the item type tree that includes all item types to be paid under this charge priority list.

Defining Charge Priority List Rules

Access the Details page.

Waiver Form	Select a waiver form if you want one to apply. A waiver form is a type of advance permission that the system uses with item types that have payment application restrictions. When you select a waiver form, the system applies the charge priority definition only if the waiver form has been attached to the student. Waiver 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, a waiver form can grant that permission. The waiver form must be attached to the charge priority list definition that is set to Permission for the prior term.
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! If you want to use the pay proportionate % tax functionality 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 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 if payments may be applied to charges for the current term. There are four valid values 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. Waiver forms 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. Waiver forms 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. There are three options 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 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.

Example of a Charge Priority List Selection

Charge priority setup can be confusing and small differences can sometimes yield surprising results. It is impossible to give examples of all scenarios, but the following examples present two common outcomes.

Keep in mind that any charge 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, let’s examine 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 of Last Enrollment Term. For purposes of this example, let us assume that the student’s last completed term of enrollment is Fall, 2000 and there is no term 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

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:

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 falls 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:

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 would once again include all charges because the current term would 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 related to tree nodes and time periods.

See Also

Managing Waiver Forms

Defining Posting Parameters

Defining Payment Overall Priorities

Access the Payment Overall Priority page.

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 selected as allowable charges.

Charge Sort

You can define up to four charge sort criteria. Keep in mind 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 only 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 defined as current is going to be the oldest term available.

Example of How Payment Overall Priority Sorts Eligible Charges

Using our sample set of charges, let us look at how charge priority and payment overall priority rules work together to control payment application, let’s suppose a student makes a payment of 8,000.00 USD against her account. Let us consider two setup scenarios to show how differently payments are applied.

Sample Charges

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 as follows:

In this example, all charges with due dates through 10/5/00 will be paid in full and 1,725 USD will be applied to the Spring, 2001 Tuition charge due 1/15/01. Because there is not enough money to pay all charges in full, the system applies the payment to the charges in order of the due date.

Also, note that there are two charges due 10/5/00 and also two 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 as follows:

The system pays in full all Tuition charges and those Housing charges through the 10/5/00 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.

Setting Up Account Types

To set up account types, use the SF Account Types component (ACCT_TYPE_SF).

Account types classify item types into usable account groupings. Differentiating charges into multiple accounts enables flexibility in billing and assessing late fees. For example, creating a separate account type for housing enables you to bill and assess late fees for housing charges differently than you do for tuition charges.

Pages Used to Set Up Account Types

Defining Account Types

Access the Account Types page.

Account Nbr Prefix (account number prefix)	Enter an account number prefix that appears as part of the charge description on account display pages. For example, charges with the account number prefix, TUITION would appear as TUITION001.
Account Per Term	Select to maintain a distinction between charges by term. If you do not select this option, all charges are placed in a single account.
Late Fee Code	Enter a late fee code to control the application of late fees to student charges in this account type. This selection does not apply late fees to external organization charges.
Ext Org Late Fee Code (external organization late fee code)	Enter an external organization late fee code to control the application of late fees to external organization charges in this account type. This selection does not apply late fees to student charges.
Primary Account	Select to establish this account as primary.
View Unappld Pymt Credit Hist (view unapplied payment credit history)	Select if you want unapplied payments to offset eligible charges. For example, a student has a Tuition charge of 5,000 USD that is 90 days past due and an unapplied payment of 1,000 USD sitting in the student's account. If you clear the check box, Credit History shows 5,000 USD as 90 days past and -1,000 USD as current. If you select the check box, Credit History shows 4,000 USD as 90 days past due.
Include Pre-Pay	Reserved for future use.
Move Excess FA	Select to have excess Financial Aid moved into the FA Excess Account defined on the SF Business Unit. For example, a student owes 1,000 USD in Tuition and receives 1,000 USD in Financial Aid but later drops a class and overall charges are reduced to 750 USD. If the check box is selected, the excess 250 USD is moved from the Tuition account to the FA Excess Account specified on the SF Business Unit. If the check box is cleared, the excess remains in the Tuition account as a credit. Note. When you select this option, you must also select the Move Initial Financial Aid option on the SF Business Unit, Posting setup page.
Exclude from Aging Total	Select to prevent this account from aging and being included in the collection process.
Balance Forward	Reserved for future use.
Move Exc Pmt (move excess payment)	Select to move an excess payment into the Payment Excess Account defined on the Posting setup page in the SF Business Unit component. For example, a student receives a parking ticket for 200 USD that is subsequently paid with a 200 USD check. The student then launches an appeal and the ticket is reduced to 150 USD. If the check box is selected, the excess 50 USD is moved from the Parking account to the Payment Excess Account defined on the SF Business Unit. If the check box is cleared, the excess 50 USD remains in the Parking account as a credit. Note. When you select this option, you must also select the Move Initial Payment option on the SF Business Unit, Posting setup page.
Late Fee Account	Select to designate the account as the recipient of all late fees. When you select this option, you must also enter a late fee code.
Include In Class Cancellation	Select to include this account when determining if a student’s enrollment will be cancelled due to non-payment of fees. If the check box is cleared, this account will not be included in calculations. For example, you might want to include charges in the tuition account but exclude charges in a miscellaneous account.
Move Exc Waiver (move excess waiver)	Select to move an excess waiver payment into the Excess Waiver Account Type defined on the SF Business Unit. For example, a student owes 1,000 USD in Tuition and receives a 1,000 USD Tuition Waiver but later drops a class that reduces the overall charge to 750 USD. If the check box is selected, the excess 250 USD moves from the Tuition account to the Excess Waiver Account Type specified on the SF Business Unit. If the check box is cleared, the excess 250 USD remains in the Tuition Account as a credit. Note. When you select this option, you must also select the Move Initial Waiver option on the SF Business Unit, Posting setup page.
Include in Balance	Select to include the account in the student's account balance. If this check box is cleared, the account is excluded from the student's balance.
Payment Plan Account	Select if the account is to be used as a payment plan account. Note. If you select this check box, do not select a Late Fee Code.
Include Billing	Reserved for future use.
Include Transfers	Reserved for future use.
Ext Org Late Fee Account (external organization late fee account)	Select to attach a late fee to the account. When you select this option you must also enter an Ext Org Late Fee Code.

See Also

Administering Payment Plans

Setting Up Item Types and Item Type Groups

To set up item types and item type groups, use the Item Types component (ITEM_TYPE_PANEL) and the Item Type Groups component (ITEM_GROUPINGS).

This section provides an overview of item types and item type groups, and discusses how to:

• Define basic item type attributes.

• Define transaction amount and tax form parameters for item types.

• Define miscellaneous parameters for item types.

• Define item type posting restrictions.

• Link account types to an item type.

• Map item types to general ledger accounts.

• Define item type GL interface parameters for a deferred revenue account.

• Define item type groups.

Understanding Item Types and Item Type Groups

Item types are the basic work unit of the Student Financials application. Each item type defines and describes a unique action. During the setup of your item types you differentiate between charges and credits and define how and where each can be applied. You also group them by classification and determine how your system uses them to transfer student account information to your general ledger.

Many functions in the Student Financials application also use item type trees. It is important that you understand how item types trees are organized and used.

Note. Virtually everything you do within Student Financials involves item types (the exception being certain transactions in cashiering). Because of this, planning your item type setup is very important. Make sure that you create enough item types to represent every unique transaction. Also, establish a numbering scheme that enables you to group similar charges and credits. This helps you later when you define item type security and makes it easier to create groups of item types for other setup procedures such as defining waivers, charge priority lists, and payment plans. Use the sample data provided with the system as an example.

Item Type Groups

Use item type groups to combine ranges of item types using multiple item type tree nodes. Item type groups limit the application of credits to desired charge items only. For example, if you have a waiver attached to a tuition group, you can use an item grouping to limit the application of the waiver to only tuition and housing, rather than to all fees.

See Also

Enterprise PeopleTools PeopleBook: Tree Manager

Pages Used to Set Up Item Types

Defining Basic Item Type Attributes

Access the Initial Setup page.

Keywords	Select up to three keywords you want to link to the item type.
Tuition Deposit	Select if the item type is for a tuition deposit. This check box is only active when the Deposit item type classification is selected.
GL Interface Required	If you select this check box , you must complete the GL Interface page of this component to save the item type. You must define both a debit and credit side for the item type, the GL Pct (general ledger percent) must add up to 100% for all accounts on each side, and all of the required fields on the GL Interface page must be populated. If you select this check box, the Course Class Specific and Accounting Date Control check boxes also become available. See Mapping Item Types to General Ledger Accounts.
Course Class Specific	Select if you want to override the GL Interface defined for this item type and use one that is defined specifically for certain courses or classes. When you select this check box, the GL Interface defined for the item type is overridden if you define an interface at the course or class level only and select the Track Class Pricing check box on the related term fee setup. For example, if you want tuition revenue from certain math classes credited to a special account rather than the normal tuition account, set up a unique item type using the Course Class Specific option. Note. GL Interfaces specific to a course or class are defined on the Student Records GL Interface page in either the Course Catalog or the Class Schedule components.
Accounting Date Control	Specify the accounting date of the item type. Select from the following values: Run Date: Select to use the GL interface process date as the accounting date. This is the default value for this field. Item Effective Date: Select to use the effective date of the transaction (item) as the accounting date. Term Start Date: Select to use the beginning of the term as the accounting date. For example, suppose students at your institution register for fall term courses in the spring, but you want the system to put the tuition income from those registrations into a fall accounting period. By selecting term start date as your accounting date control and specifying the fall term on your tuition transaction, the system posts the charges to the fall period. Warning! Selecting Term Start Date in the Accounting Date Control field could cause transactions to be backdated into an already closed accounting period. Select this option with caution. Maximum (Term Start Dt, Run Dt): Select to make the system use the more recent of Term Start Date or Run Date as the accounting date. This option is useful to prevent complications resulting from accounting periods that have already been closed.

Classification

Select the appropriate classification for this item type. Your choice dictates the fields available to you on the Miscellaneous Edits page, and indicates to the system if the item type is a charge or credit entry.

See Also

Completing Item Type Initial Setup

Defining Financial Aid Item Types

Defining Transaction Amount and Tax Form Parameters for Item Types

Access the Amount Edits page.

Min Transaction Amount (minimum transaction amount) and Max Transaction Amount (maximum transaction amount)	Select the optional minimum and maximum amounts for each transaction using this item type. The system uses these amounts as edits for Group Posting.
Base Currency	The base currency selected by your institution defaults into the Base Currency field. You can override this field.
Default Amount	You have the option of entering a default amount for your item types to streamline data entry. This is particularly useful when you are entering a charge or payment for something with a fixed cost (for example, a parking permit). You can override this default amount whenever necessary. The default amount must be greater than or equal to the Min Transaction Amount.

T4 Setup

This group box pertains to the form required by the Canadian government to report certain scholarships and other financial aid that must be counted as income.

T4 processing in Student Financials is a payroll interface. You can use Student Financials or PeopleSoft Financial Aid to process income scholarships and have the scholarship income reported to the federal government through the standard payroll T4 process.

Note. If your institution does not use PeopleSoft Payroll for North America, you can run the SF Generate T4 Data process (SFGENT4) and use the output from the file generated by this process to create an interface with your payroll system.

T2202A Setup

This group box pertains to the form required by the Canadian government to report eligible educational expenses for Canadian students.

1098-T Setup

This group box pertains to the form required by the U.S. government to report eligible educational expenses for U.S. students.

Defining Miscellaneous Parameters for Item Types

Access the Miscellaneous page.

Note. Not all fields shown in the page shot are available for all item type classifications. And, other fields may be available that are not shown. The following list defines all fields used with all item type classifications.

Defining Item Type Posting Restrictions

Access the Posting Restrictions page.

Item Effdt Edits (item effective date edits)

Due Date Edits

Linking Account Types to an Item Type

Access the Item Types - Account Types page.

SetID	Enter the SetID that includes both the account type and the item type. Warning! It is possible (but not recommended) to have item types and account types duplicated in more than one SetID. Exercise caution that you do not specify a SetID that is incorrect for the item type that you are defining.
Account Type	Enter an account type that you want to associate with the item type. Account types provide information for prompting when performing data entry.

Mapping Item Types to General Ledger Accounts

Access the Item Types - GL Interface page.

Note. If you select the GL Interface Required check box on the Initial Setup page, you must complete this page to save the item type.

Term/Session

Effective Date and Status

Journal Definition

This region of the page is divided into two identical sections, top and bottom. Each GL Interface definition requires at least one debit and one credit entry. Each debit entry and each credit entry may be split into multiple entries for distribution to your general ledger, but you must make sure each side (debit and credit) total 100%.

Splitting a Transaction Between Multiple GL Accounts

The General Ledger Percent (GL Pct), Priority, Priority Amount, and Account Limit fields are use to split a debit or credit across multiple GL accounts.

Chart of Account Information

Enter chart of account information for the item type.

Defining Item Type GL Interface Parameters for a Deferred Revenue Account

Access the Deferred GL Interface page.

Deferred Date

If you indicate that a particular item type needs to defer revenue, the system prompts you for liability account information and a deferred date. The system uses the liability account until the date that you have indicated for that item type. The system does not automatically generate the entry for moving the deferred revenue from the liability account to the realized revenue. When this date passes, you must move the revenue into the general ledger.

Deferred Dynamic Org

Select to have the system defer the appropriate revenue based on the subject area of the classes in which a student is enrolled. This capability enables you to defer revenue based on a student's course load using the organizational chart field.

Defining Item Type Groups

Access the Item Type Groups page.

TableSet	Select the setID that includes the item type tree that you want to use.
Tree Name	Select the tree name of an item type tree that includes all of the tree nodes that you want to include in your item type group.
Tree Node	Select a tree node that you want to include in your item type group

Setting Up Service Indicator Sets

To set up service indicator sets, use the Service Indicator Sets component (SERVICE_IND_SETUP).

This section provides an overview of service indicator sets and discusses how to:

• Define service indicator set details.

• Define eligible academic careers for service indicator sets.

Understanding Service Indicator Sets

Service indicator sets enable you to automatically attach service indicators to student accounts by running the Credit History process. When you define service indicator sets, you link a service indicator to an aging category/minimum amount combination. When you run the Credit History process, the system applies the linked service indicator to any student with an overdue balance that falls within the specified aging category and is over the minimum amount. In addition, if the linked service indicator is already applied to a student account and the student pays off the overdue balance, the next time you run the Credit History process, the system removes the service indicator.

See Also

Processing and Reviewing Customer Credit History

Setting Up Service Indicator Codes and Reasons

Pages Used to Set Up Service Indicator Sets

Defining Service Indicator Set Details

Access the Service Indicator - Details page.

Severity	Enter the alphanumeric code established by your institution to indicate the severity of the service indicator.
Aging Set	Select the aging set containing the aging category to which you are linking a service indicator.
Aging Category	Select the aging category that triggers the application of the service indicator to student accounts.
Min Amt (minimum amount)	Define the minimum amount that triggers the application of the service indicator to student accounts.
Service Indicator Cd (service indicator code)	Select a service indicator code from your established list. This code is linked to a service impact that controls what actions the system takes related to the service indicator.
Service Ind Reason Cd (service indicator reason code)	Select a service indicator reason code from your established list. This code explains why this service indicator is being applied.
Contact ID	Select the ID number of a specific person with the department responsible for this service indicator set.
Department	Select the department that is responsible for this service indicator set. This is the department the student must contact to clear the associated service indicator.

Academic Career Controls

The check boxes in this group box control where the system searches to confirm that the student is active in an academic career before applying a service indicator. At least one check box must be selected, but you may select all three.

Defining Eligible Academic Careers for Service Indicator Sets

Access the Service Indicator - Career Setup page.

Academic Career

Select the academic career to which the associated service indicator can be applied. Note. If you did not select the No Career check box on the Service Indicator - Details page, you must be sure to specify the career for all appropriate rows and severity levels.

Setting Up a Default Academic Term

To set up a default academic term, use the SF Term Default component (DFLT_TERM_TBL).

A default term value simplifies data entry. Typically, it is most beneficial to change the default term value at the beginning of each term. Using effective dating functionality, you can predefine default term values in advance and have them automatically change on the first day of the term.

Page Used to Set Up a Default Academic Term

Defining Default Academic Terms

Access the Term Default page.

Effective Date	Enter the effective date for the SF Term you are identifying.
Status	Select the status for this term default.
Term	Enter the default academic term.
Term Beginning Date and Term Ending Date	Enter the term beginning date and the term ending date.
Academic Year	Enter the academic year to which the term belongs.
Antic Aid Term From (anticipated aid term from)	Enter the value of the first (beginning) term that you want considered for anticipated financial aid (aid awarded but not disbursed).
Antic Aid Term To (anticipated aid term to)	Enter the value of the last (ending) term that you want considered for anticipated financial aid.