One unique Banner-related limitation at USU is the way tuition is handled differently between Logan Main Campus, RCDE Campuses, and USU Eastern Campuses. First, understand that the tuition tables are not linear. There is steep cost associated with the first credit, a plateau traditionally between the 13th and 18th credit, and student body fees are similarly heavily front loaded. The problem was tuition was originally campus specific so that each campus received tuition dollars for the classes it taught. This meant that the student was charged that steep first credit for each campus they registered for and weren't able to benefit from the plateau if their registrations weren't all at the same campus.
This was addressed by the Multi-Campus Wavier for several semesters, but this had the problem of a lag time. The student was still overcharged at registration, then had to wait for a waiver to be applied in batch to refund the difference and had a hold placed that prevented registration changes to a mostly manual process.
The Campus Revenue or One-Pot Tuition solution remedies this. Tuition is no longer charged by campus. It is charged based on a section attribute. Since there are two tuition tables in use at USU, one for Logan Main Campus and RCDE, the other for USU Eastern, there are two section attributes to identify which tuition table to use. The attributes are USUM and USUE (USUV was added later for the unique veterinarian program which is not considered part of the One-Pot solution). Now, students are charged the correct tuition from the point of registration making the student and parents happy. The tuition is collected into a single account (or pot). Then a number of processes are run to distribute those funds proportionally to the student's registered credit hours to accounts specific to the appropriate campus.
Attached is a script that will run the tuition attribute sync process in a development environment(ZDEVL, ZPPRD etc.).
One Section Modification - 06/01/2022
The new definition is based on a system wide change (One Section) to get all Online courses to use only one section (verses the old practice of having one course broken out by each individual campus), then splitting up the campus revenue and determining tuition tables based on the students’ currently location (zip code) instead of the campus code on the course. Student tuition attribute has been completely removed from the process.
The student zip code is declared at registration time via an Action Item. When the student enters a zip code the student will be assigned a Campus Code, Site Code and Rate Code based off the Zip Code in SGASTDN. Now, students are charged the correct tuition from the point of registration making the student and parents happy. The tuition is collected into a single account (or pot). Then a number of processes are run to distribute those funds proportionally to the student's registered credit hours to accounts specific to the appropriate campus.
There are MANY pieces to this solution:
Automated Section Attribute Sync - This is the Applications Manager process that applies the USUM, USUE, and USUV codes. It is the CAMPUS_REVENUE process flow found in the EDO application. It has one component per semester we are actively running the sync on. The Oracle package.procedure called by the process is BANINST1.Z_CAMPUS_REVENUE.P_SYNC_SECTION_ATTRIBUTES(p_term_code).
TABLES (all in BANINST1)
- Z_CAMPREV_SOURCE - This table must be populated each semester with the detail codes, descriptions, index, and account numbers for the tables where tuition and fees are collected.
- Z_CAMPREV_DISTRIBUTION - This table must be populated each semester with the campus code, detail code, description, percentage (represented by a decimal), index, and account for where the tuition and fees should be allocated buy the One-Pot process. The percentages on each campus for each detail code should sum to 1.
- Z_CAMPREV_BREAKDOWN - This table is populated by the One-Pot process wil totals for the amount collected on each detail code, what potion of that belongs to which campus, a run date, and the associated jobsub_code.
- Z_CAMPREV_USUE - This table gives breakdown by detail code of the amounts distributed to each campus for USUE.
- Z_CAMPREV_USUM - This table gives a breakdown by detail codes of the amounts distributed to each campus for USUM.
BANINST1.Z_CAMPUS_REVENUE - This is the package responsible for all the heavy lifting for the One-Pot process.
ZSP1POT - (only used for terms prior to Summer 2022) This is the jobsub process built to allow the registrar's office the ability to administer the process. It takes two parameters, a term code, and a previous run jobsub number. If run with only a term code, the process generates the values needed to distribute tuition and fees to their appropriate campuses for the first run of the semester. After the first run, the previous run code should be populated so that only the change in amounts will be distributed. The registrar's office has been educated on this process and only updates the previous run parameter when they push the generate file to the controllers office for distribution.
ZSP1POT2 - (Used for terms Summer 2022 and later.) Same process as above.
student@data.banner.usu.edu files
- USUgurfeed<timestamp>.csv - this is the file generated in the correct format to distribute tuition and fee amounts to their appropriate accounts.
- USUEreceivable<timestamp>.csv - this it the detail file generated for the USUE attribute.
- USUMreceivable<timestamp>.csv - this is the detail files generated for the USUM attribute.
- USUEsummary<timestamp>.csv - this is the aggregate file showing the totals by detail code for the USUE attribute by campus.
- USUMsummary<timestamp>.csv - this is the aggregate file showing the totals by detail code for the USUM attribute by campus.
- USUErevenue<timestamp>.csv - this file shows the tuition and fees by student, their credit hour breakdown, and their distribution to USUE campuses.
- USUMrevenue<timestamp>.csv - this file shows the tuition and fees by student, their credit hour breakdown, and their distribution to USUM campuses.
EDO Section
Z_CAMPREV_SOURCE and Z_CAMPREV_DISTRIBUTION need to be populated each semester. For now, the business process is to extract the values of these table from the previous year's corresponding term (so for 201440, extract 201340) and deliver these to LuAnne Bladen in the Registrar's Office. She will work with the Controllers office to update the values for what is needed for the new term. Once they have the values back to you, check them. Do this by ensuring that the percentages for each detail code sum up to 1. Then load these to the appropriate tables.