Introduction
While there are many benefits for implementing multiple Student Financials (SF) Business Units, immediate value is recognized by concentrating efforts on designing the business structure for an operational unit, rather than making compromises across units consolidated under one SF Business Unit. SF Business Units allow an operational unit to utilize its own set of unique and independent business rules. In situations where new operational units are being implemented on top of units already in Production, utilizing multiple SF Business Units significantly reduces risks and eliminates the necessity to continuously evaluate how decisions made for the new units will impact those currently in Production.
Student Financials Business Units
The Student Financials Business Unit is the central component of the PeopleSoft Student Financials application. SF Business Units are associated with an Academic Institution, a Campus within the Academic Institution, and a valid Campus Location of the Academic Institution. They are further defined with a General Ledger Unit for interfacing student and corporate receivables to the Financials General Ledger, and an Accounts Payable Business Unit for processing refunds. SF Business Units provide the primary security components in Student Financials for inquiry and posting access to both student and corporate accounts.
Each SF Business Unit should be defined with five characters and have an equal and corresponding Set ID. At least one SF Business Unit and Set ID combination must be equal to the five character value of the Academic Institution Code. Tables in PeopleSoft Student Administration are divided and contained within Record Groups. Record Groups consist of single or multiple tables and table views. Record Groups are maintained within Table Set Controls and allow you to define the business and operational rules for each SF Business Unit uniquely, or incorporate Table Set Sharing across multiple SF Business Units within the Academic Institution.
When defining how many SF Business Units to create, consideration should be given to what operational units within the institution age receivables, bill customers and collect past due accounts for common groups of student populations. This definition should be used as an initial guidepost in determining the number of SF Business Units to implement and operate in PeopleSoft Student Financials, but you must also consider how the software defines, processes, posts, maintains and reports student financial transactions. For example, the following information is maintained and/or processed at the SF Business Unit level:
- Security
- Academic Programs linked to SF Business Units
- Customer Accounts (students and third party organizations)
- Tuition Groups
- Enrollment Deposits
- Tuition Calculation
- Student Billing
- Payment Processing
- Student and Corporate Post
- Student and Corporate Group Post
- Cashier Offices
- Student and Corporate Cashier Payments
- Self-Service Credit Card Processing
- G/L Interface
- Batch and Individual Refunds
- Credit History (Aging Receivables)
- Late Fees
- Enrollment Cancellation
- Collections
- Write-Offs
- Third Party Contracts
- Payment Plans
Student Financials Security
PeopleSoft Student Financials provides seven security options. Each option can be defined with No Security, User Id Security and Permission List Security. Although each option is unique unto itself, Business Unit security is the controlling factor for Origin and Item Type Security.
SF Business Units provide the mechanism for securing financial transactions within PeopleSoft Student Administration. All charges payments, financial aid, deposits, etc. are posted to a customer account under a SF Business Unit structure. Running multiple SF Business Units provides a more streamlined approach for separating and securing financial transactions that occur within different operational units across the Institution. A multiple SF Business Unit structure provides opportunities for
- Granting and restricting access to view and inquire on student accounts under a specific SF Business Units
- Granting and restricting access to post transactions to student accounts under specific SF Business Units (Student Post and Group Post)
- Granting and restricting access to Cashiering Offices under specific SF Business Units
Security access to SF Business Units can be granted to individual users or assigned to specific Permission Lists. Business Unit Security allows stringent control on what users have access to view and post to accounts within specific SF Business Units. Once security has been granted, additional access can be assigned to Cashier’s Offices underneath each SF Business Unit.
Security access to Item Types can be granted to individual users or assigned to specific Permission Lists. Item Type Security allows you to restrict access to individual Item Types or ranges of Item Types (Tree Nodes) for posting within the SF Business Unit.
Tuition Calculation Processing
PeopleSoft Student Financials provides numerous options for calculating tuition and fees. Not only can you establish a structure to meet the needs of a broad grouping of students, you can also create specific fees to meet special circumstances fro very select groups of students. The SF Business Unit is the central component for tuition calculation processing in PeopleSoft Student Financials. All Academic Programs are associated with SF Business Units on the HOME_CAMPUS_TBL. When students are Term Activated in an Academic Program, this association is the mechanism for triggering the SF Business Unit in which Tuition Calculation and Posting will occur.
Tuition Calculation is processed by SF Business Unit. Utilizing multiple SF Business Units provides more control for effective and efficient calculation and processing for unique groups of students.
In order for the system to calculate tuition, students must be placed in Tuition Groups. Tuition Groups describe a category of students who are charged similarly using a common set of general rules. Tuition Groups are defined by SF Business Units, and students are placed in these groups based on user defined criterion at the time tuition calculation is run for the SF Business Unit.
Utilizing multiple SF Business Units provides more control over how you construct your Tuition Group structure and increases performance and accuracy. A multiple SF Business Unit structure can significantly reduce the number and complexity of Tuition Group Criterion that is utilized for placing students for calculation purposes. Implementing a new SF Business Unit will also eliminate the need to redesign and reconfigure the current Tuition Groups and Criterion in Production.
Student Billing
The Billing Request process is the first step for generating student invoices. Billing Requests are processed based on SF Business Units. Because all financial transactions are contained at the SF Business Unit level, utilizing multiple SF Business Units allows greater control and flexibility in how and when students are billed.
If you do not wish to bill and generate an invoice for a specific group of students you simply do not run a Billing Request for the SF Business Unit associated with those students Academic Programs. This is a much more effective and efficient way to restrict students from the billing process, as compared to creating multiple Billing Standard Requests based on Academic Programs, SF Account Types, transaction posting dates and other criterion.
Self-Service Payments
Utilizing multiple SF Business Units allows flexibility for defining which entities within the institution allow real time authorization and settlement of credit card transactions in PeopleSoft Student Administration. Because the distinction is made at the SF Business Unit level only charges contained in the SF Business Units that allow credit card processing will be eligible for payment.
Institution Sets provide students access to view their Student Financials transactions through Self-Service. In order to process credit card payments for the SF Business Unit via Self-Service, the Institution Set associated with the student must be enabled for credit card payments. If Accept Self-Service Payments is not selected for the Institution Set, credit card transactions will not be allowed, regardless of the selection on the SF Business Unit, and students will only have access to account inquiry.
Each Institution Set can be associated with a merchant id for credit card payments and a merchant id for electronic check payments. Payments can be allocated at three different levels: (1) By Charge; (2) By Term; or (3) By Business Unit. For each Institution Set you can decide to allow excess payments via credit cards and accept admissions deposits via credit card as well.
One or multiple SF Business Units can be associated with an Institution Set. One SF Business Unit may accept credit card payments, while another SF Business Unit may not. In order to process credit card payments for the SF Business Unit via Self-Service, the Institution Set associated with the student must be enabled for credit card payments. This combination provides opportunities for students to have customer accounts under two unique SF Business Units that operate differently in terms of Self-Service credit card acceptance, but view each SF Business Unit in Self-Service through one Institution Set.
The Accept Self-Service Payments option on this page can not be selected or deselected. This option will be enabled or disabled based on decisions made on each SF Business Unit. A unique Credit Card Item Type, eCheck Item Type and Deposit Item Type can be associated with each SF Business Unit that allows Self-Service payments. This allows stringent control over payment application rules for each Item Type within each SF Business Unit.
Cashiering
Cashiering Offices are established underneath SF Business Units. Each SF Business Unit can run one or many Cashiering Offices. Utilizing multiple SF Business Units for separate operational units allows each unit complete control in terms of how many offices it operates, how many registers are used, and what cashiers have access to the offices within the SF Business Unit. Security for Cashiering Offices is controlled by the SF Business Unit. Each Cashiering Office is associated with a SF Business Unit, Campus and Location. Each Cashiering Office within the SF Business Unit can be associated with a unique SF Merchant ID for credit card processing.
Refunds
Individual and batch refunds are processed at the SF Business Unit level. Utilizing a multiple SF Business Unit structure allows each operational unit to control the parameters and frequency in which it processes refunds for students.
Each SF Business Unit can choose the refund method it will employ: (1) Payroll; (2) Accounts Payable; or (3) Other. If desired, the unit can also allow changes to the refund method at the time individual refunds are processed. Service Impacts can be incorporated with the refund process that will exclude students from receiving a refund even if a credit balance exists within the SF Business Unit. Frequency of batch refunds can be defined for financial aid only, non financial aid only and both financial aid and non financial aid item types. Minimum and maximum refund amounts can be established per SF Business Units.
Student Financials Transaction Postings
Virtually all student financials related transactions occur at the SF Business Unit level. In order to record a transaction on a customer account you must first identify what SF Business Unit the transaction should be posted. The following posting processes reference the SF Business Unit:
- Student Post
-
- Corporate Post
- Group Post
- Student Payments
- Corporate Payments
- Payment Reversal
- Charge Reversal
- Payment Applier
Aging of Receivables
The Credit History process ages receivables at the SF Business Unit level. Utilizing multiple SF Business Units allows flexibility in how and when different operational units age receivables, process late fees, cancel enrollments and place accounts in collection. When multiple SF Business Units are in place, the frequency in which receivables are aged, as well as the actions that are taken afterwards is entirely at the discretion of each operational unit.
The PeopleSoft Student Financials application has been designed to automatically age all transactions within the SF Business Unit. If there is a need to exclude transactions from the aging process, this can be accomplished by excluding SF Account Types from the process. The point in which transactions (Item Types) within a SF Account will begin to be aged depends on the Basis date you indicate when you establish your Aging Set. Aging Categories allow you to define how you want to track your receivables, and can be created with as much flexibility as you need to reflect your institution’s current business practices.
Late Fees
Late Fees are processed at the SF Business Unit level. Late Fee codes are defined by Set Id and attached to SF Account Types utilized within the SF Business Unit. Utilizing multiple SF Business Units allows different operational units to define and process late fees for students and organizations based on its own parameters for dealing with past due accounts. Because the process is run per SF Business Unit, past due charges within different SF Business Units will not be included in the calculation and posting of late fees.
Enrollment Cancellation
The Enrollment Cancellation process in Student Financials is processed by Business Unit. Utilizing multiple SF Business Units provides more control over what past due charges are considered when determining if a student’s enrollment should be cancelled for the term or session. Only past due charges contained in specific SF Business Units will be considered.
Preparing to cancel a student’s enrollment due to non-payment of fees involves a series of well planned and executed business decisions that primarily includes defining how receivables will be aged and what action to take when a specified amount becomes past due after a certain period of time. While the Enrollment Cancellation process is imbedded in Student Financials, it is directly integrated with Student Records, primarily in the areas of Enrollment Actions/Reasons, Time Periods, and Academic Calendars. The Enrollment Cancellation process should be developed and coordinated with Student Records.
Student Financials provides option for canceling enrollment on a term basis, session basis, class-by-class within term basis and class-by-class within session basis. Within the SF Business Unit all students can be selected for consideration, or the process can incorporate specific Tuition Groups or Academic Programs associated with the SF Business Unit. The process can include transactions that are past due based on a specific date or based on a specific number of days.
Collections
SF Business Units control the collections process for students and organizations. Each SF Business Units can define parameters for moving students and organizations in to collections based on a combination of past due amounts and past due categories. Students and organizations can be automatically moved out of collections based on a combination of exit due amounts and exit due categories. Procedures for working collections can be established per SF Business Units and can incorporate communications and checklists as a way to track and monitor collection activities. Automated workflow processes can be incorporated to assign students and organizations to specific collectors.
Third Party Contracts
Third Party Contracts for corporate customers are defined by SF Business Unit. This allows each operational unit within the institution to maintain its own group of corporate contracts and accounts. Each SB Business Unit can utilize its own contract numbering scheme and bill customers as required.
Summary
Utilizing multiple SF Business Units provides a tremendous amount of flexibility with how unique operational units within the Institution can conduct day-to-day business activities. The primary benefit of a multiple SF Business Unit structure is that it allows each unit to operate independently, utilizing it own set of business rules. Students recognize benefits in the ability to view their accounts across SF Business Units independently, as well as increased functionality with credit card payment options.
