Skip to end of metadata
Go to start of metadata

Fee Management – Working Assumptions

  • Fees/Tuition and other chargeable items will be stored in a RateService, that, like transaction type, will roll over time. This will need a "rollover" service to establish the next year of fees if dates, etc. are to be attached to them.
  • ATP will be the source of information for things like when late fees etc. will be applied.
  • External registration system will be responsible for the recordation of adds, drops, add without penalty, drop without penalty, transfer from, transfer to and withdrawal records, including the dates on which those activities occur. The linking of student to AO is the responsibility of the registration system.
  • From discussion, it appears that the appropriate level of information that KSA will expect attached to add/drop/etc. will be KS' Activity Offering (usually referred to as AO) or Program Offering (PO)
  • KSA-FM is only interested in courses for which a student is registered (not waitlisted, or any other statuses). There is an expectation that if a student signs up for a course and is subsequently allowed into that course, KS will inform KSA-FM of this, and will provide the appropriate sign-up date to allow KSA-FM to know if late registration fees will or will not apply.
  • KSA will not be the system of record for many of the attributes of FM. Some, but not all, are present in KIM. Example – home campus, level of study (UG, PG), full or part-time, residency, major code, cohort code.
  • KSA is not the system of record for courses, and ought to be, in most all cases (other than outlier use cases) completely agnostic if not ignorant as to the actual courses a student is taking. The rate codes information plus other student attributes should be sufficient to calculate the appropriate charges for a student for a semester. Embedding "knowledge of specific classes" into the rules engine blurs the lines of contract between KS-ENR and KSA.

 

High Level Overview of Functionality



KS enrollment passes the signup list for the semester. This includes ALL adds, drops, etc. For the session. This is explained more fully in the "Data Requirements from the Enrollment System" portion of this document. This data is used to create a FeeManagementSession which is unique for this charging session. As a student can be reassessed multiple times for the same term, this is versioned with a subcode in much the same way as transaction types, etc.
The shared vocabularly about pricing (Rate) and dates (ATP) are used to allow the two systems to communicate vital information. This allows KSA to charge for courses etc., WITHOUT having to know about the specifics of those courses.
Rates are discussed later in the document.

After Receipt of Enrollment Data


Once KSA has received the enrollment data, the rules portion kicks off. The fundamental job of the rules is to take the signup lines, and the rates attached to them, and convert them into charge manifest lines, which KSA can then process. There is an overview of these rules in this document, and then there is a much bigger discussion in the Unified Rule document.
Once this process is complete, and we have a charge manifest, this is passed back to KSA for processing. The charge manifest is compared to the prior manifest, in order to calculate differentials, and correctly bill the student's account.

Rates

Written convention

For the sake of easy identification in the documentation, when a whole rate is written, it is written as rate type .. rate (for example, tuition.flat..biology.undergraduate). The rate type here is tuition.flat, the rate is biology.undergraduate.

Basic Concepts

Rates are the generalized repository for things that can be charged during fee assessment. They cover a broad gambit of course fees, program fees, penalties, tuition rates, as well as generic rates (flag rates) that are processed by the rules engine to be applicable to a student. (For example, when there is an undergraduate or a graduate version of the same fee).
For an explanation of why there is a RateService, please see the document "Rate Service and Communication with KSA".
RateType is discussed later – this is basically the category of "rate" that will be used by the rules engine to kick off whatever charging algorithm we need to do. This is extensible by the institution as its interpretation is written in rules (however we will provide the basic types once finalized, as listed in this document)
From there we have rate catalog objects, which define the basics (the "template" as I think it was referred to in an earlier call) of the rates, including limits that are put on rates. Following the OO standard, we consider something "final" if its dependents cannot change the value. So for example, if RateCatalog sets isAmountTypeFinal to true, then amountType cannot be changed in Rate. This also tells us what ATPs this rate can be applied to. We have discussed using dates, etc., but I think a list of ATP is where we have ended up? We might have to look more closely at this when we look at applying to majors, instead of AOs, but that's a future discussion.
Note that the amount types are Flat (The rate is the same no matter what, i.e. charge $100 no matter how many credits on the courses) Fixed (a fixed amount per credit, i.e. $100 per credit hour) or Flexible (per credit hour charge, but the rates are not mathematically consistent, so for example, $100 for 1 credit, $150 for 2 credits, $175 for 3 credits, $200 for 4 or more credits.)
Then we get to Rate – this is the actual "instance" of the rate, the thing you would attach to an AO, or as Cathy and I discussed this week, maybe to the major, etc. This should be reference by "code" which will be unique for each Rate (as it is for each AuditableEntity in KSA). This code could be the same as the transaction type code if a school wanted it to be.
From Rate, we know RateCatalog and RateType and RateAmount. RateAmount is used to allow a rate to be varied by credit hour, and in this case, we can also change the TransactionType for each different level of rate. This is a small USC use case, but it can also be applied to UMD's tuition rates for in-state students, allowing us to use a single tuition code for FT/PT.

Overview of the KS-KSA interaction



KS to KSA interaction will be via a message (the exact routing and formatting of the message is still under discussion. A proposed format is included in this document.) This will communicate the signup record for the academic period that is being calculated.
Whatever happens in the communication, KSA will create a session object to store the data, and it will be based on that object that we will be performing fee assessment to create the manifest that will finally be translated into the actual charges that are applied to the account.
The shared vocabulary to communicate the signup records is based on Rate and ATP to ensure that both systems are consuming the same data, while not having to interfere with how the other system is functioning.

Rate Types

This is still very much work in progress, but this is what I am finding to be the major commonalities.
Different types of fees and tuition found in the UMD CCP Documentation. I am awaiting USC's documentation to validate against theirs.
Please see Appendix A for a graphical representation of the different models that have been discerned from work done with both USC and UMD.
See appendix A for graphical models of these rate types.

Tuition – AO connected Tuition Rates

KSA Name

Name at SI if know.

Rate Type

Description

Fixed Credit Tuition

 

tuition.credits.fixed

Tuition that is billed per credit hour. This may be subject to a limit rate (cap, or cap between unit ranges) which is discussed later.

Flexible Credit Tuition

 

tutition.credits.flexible

Tuition that is billed per credit hour. This may be subject to a maximum cap. The rate is not done as a multiplier, rather as a discrete but different amount per credit.

Fixed Course Tuition

 

tuition.course

Tuition that is billed once per course (activity offering).

Flat Tuition

 

tuition.flat

Tuition that is billed once per semester for a certain group of courses – for example, no matter how many courses from an MBA program are taken, a certain amount will be billed. This might also vary by cohort. This tends to be limited to a certain group of courses.

Flag Tuition

 

tuition.flag

A flag rate is one that has no inherent value, other than to instruct the rules engine that the rate must be chosen by the engine. For example, standard tuition flags might all be converted to resident, graduate rates for students in that situation.

Note that some of these might be accompanied by a differential rate which would deduct from the regular rate for certain students.
One or more of these rate types (or more likely, a flag rate) would be attached to each incoming activity offering. Another pattern might be to attach tuition rates ONLY to those AOs that have special tuition, and KSA will infer regular tuition patterns for all AOs that do not have a tuition code attached to them.

Flag Rates – General Note

Note that if KS-ENR needs to have actual rates attached to each AO/PO in order to surface these to the student in the course catalog, it will be necessary for them to attach all possible course rates, not just the flag rate. The selection of the correct flag rate would be done then by the rules, using some agreed way to identify the groups of rates.

Tuition Transaction Types (based on UMD implementation)

Part-Time vs. Full Time
Undergraduate vs. Graduate.
Resident vs. Non-resident.
{Note that there are a number of other "smaller" rates, for example, highschool connect, etc. There are also Shady Grove tuition codes, which have fewer restrictions.}
This leads to eight classifications of tuition. It is possible that some of the full-time codes could be removed by the use of the override transactionType coupled with the cap amount, thought this might not be desirable for future maintainability.

Part Time or Full Time

Undergrad or Grad

Resident or Nonresident

UMD's T-Code

PT

UG

R

1040

PT

UG

NR

1050

PT

G

R

1120

PT

G

NR

1160

FT

U

R

1000

FT

U

NR

1020

FT

G

R

1100

FT

G

NR

1140

Plus other changes, that are applicable at the AO level, e.g. Certain courses, with attached remissions, etc., as well as other campus tuitions (Shady Grove tuition, following the same scheme or a different scheme for tuition but with different fees.) most of which can be handled by appropriate attachment at the AO level.
There is also public-policy tuition codes which are only applicable to certain majors, but override the regular tuition.
It is possible that "regular tuition" codes can be inferred from any course that doesn't carry an override tuition code. For institutions that do not vary their tuition by course [bearing in mind, this would require them to have no certificate courses, etc., so probably an unrealistic use case] then there would be no reason to attach tuition codes in this way. It is generally considered a bad idea to infer data from lack of data, but this option could be implemented should an institution choose that route.

AO Fees

KSA Name

Name at SI if know.

Rate Type

Description

Period Fee

 

fee.ao.term

A fee that is charged once per time period, regardless of the number of AOs it is attached to. This can be used to charge a fee if a student registers for one, or several of a group of courses. It is implicitly a "fixed" fee – i.e. one charge, regardless of the number of credit hours.

Hourly Fee (Fixed rates)

USC – "Per Unit Fee" – Only "flexible" really exists at USC. (SB-2)
– "Fee per hour/credit"
UMD only uses "fixed" fees

fee.ao.credits.fixed

A fee that is charged by the number of credit hours for each AO it is attached to. It is implicitly either a flat or flexible fee, due to the relation to credit hours.
Note, per SB-2, the TransactionType can change per rate.

Hourly Fee (Flexible rates)

 

fee.ao.credits.flexible

 

Course Fee

USC – "Section Fee" (SB-1)
UMD - Fee per course

fee.ao.course

A fee that is charged once for each AO it is attached to. This is implicitly a "fixed" fee.

Annual Fee

 

fee.ao.annual

A fee that is only ever charged once to a student, per year. This is implicitly a fixed fee.

One-time Fee

 

fee.ao.once

A fee that is only ever charged once to a student, during their academic lifetime. This is implicitly a fixed fee.

Flag Fee

 

fee.ao.flag

A fee that doesn't implicitly have a value, but can be replaced with a non-flag fee by the rules engine.

Hourly Fee (Fixed rates)
(Grouped)

 

fee.ao.credits.grouped.fixed

Identical to the same type without the grouping, however, the fee is charged as a single unit, with the number of credits being derived from the collective of courses with this fee. This is essentially a fee that works in the same way as tuition.

   

Hourly Fee (Flexible rates)
(Grouped)


It is also possible that there is a "Dependency Fee" which might be a regular course fee or period fee. These are fees that are charged on a course if they are the only course that is taken, or some certain combination of courses is taken.
These rate types would also be attached to the AO.
UMD drops the resident/nonresident tuition distinction for mandatory fees, but retains undergrad/grad, part-time, full-time. This could be handled as an undergraduate fee and a graduate fee with a flexible amount structure, or as four different fees.
USC's three fee types are in the table.

Fee application distinctions (based on UMD implementation)

1202 – Fee if only one of the special courses are taken – probably can be done as an exception rule in the rules, but would be attached to the special courses.
1501 – A "once time per semester" fee for certain architecture courses.
3336 SG Aux Fee – Fee for students in a certain course, in a certain major, only.

PO Fees – Attached to the program offering / major/ etc.?

KSA Name

Name at SI if know.

Rate Type

Description

Program Fee

 

fee.po.term

A fee that is charged once per time period, regardless of the number of AOs it is attached to. This can be used to charge a fee if a student registers for one, or several of a group of courses. It is implicitly a "fixed" fee – i.e. one charge, regardless of the number of credit hours.

Program Enrollment Fee

 

fee.po.once

A fee that is only ever charged once to a student, during their academic lifetime. This is implicitly a fixed fee.

Flag Fee

 

fee.po.flag

A fee that doesn't implicitly have a value, but can be replaced with a non-flag fee by the rules engine.


1499 – Studio Lab fee only for students with a certain major – does not appear to attach to an AO
1556 Journalism Professional Fee – PT and FT distinction for UG, G but not doctoral students.
1569 MSBA Club Fee – for a single major.

Non-AO Fees – Generated within the rules system.

KSA Name

Name at SI if know.

Rate Type

Description

Late Fee

 

fee.late

A fee that is charged for late registration, etc.

General Fee

 

fee.general

A fee that is charged to a student if a certain number of circumstances are met – not specifically attached to an AO.

These are fees that might be incurred by a student that are not specifically attached to the AO. These fees would be referenced via the rules that are established in KSA-FM. There is an expectation that these are not attached to the AOs.

Examples (based on UMD implementation)

GoldlenID fee for member code 17.
1544 – MBA Association – member code of 28, except for certain majors.

Rate Patterns

Basic Patterns

These are attached to an AO/PO and are generally charged or not charged depending on their existence. Note that these are composed of the RateTypes that come in the next part of the document.

  • Program Fee: A charge attached to a program of study. For example, charge all people with an Architecture major the following fee.
  • Course Fee: Standard fee attached to a course (AO) with no restrictions other than those already layed out. These will follow the flat, fixed or flexible models.
  • Special tuition fee: Certain courses, without respect for program, have a special tuition rate. For all intents and purposes, this can be treated as an AO (Course) fee. This can only work when there are no distinctions (graduate/ undergraduate, resident/nonresident) unless it is being used as a special flag rate (for example, differing tuition by campuses).
  • Flag Rate: A standard rate, but with special meaning (most likely with its own "type"). Used for rates that are very variable by student. For example, we attach "tuition" to most courses- the rules engine will assess what type and amount and transaction type for the tuition. This might be dependent on multiple factors, and the rules engine might have to replace the Flag Rate with another Flag Rate. (For example, move from undergraduate tuition to graduate tuition.) In most cases, this is the type of rate that would be used for tuition. If there are a vast majority of courses that use a single tuition flag, and a smaller number that are exceptions, it might be reasonable to add only exception tuition flags to the AOs, and leave the rules engine to infer that anything without a tuition exception flag are subject to regular tuition.
  • Program Flag Rate: As a flag rate, but attached to a program. Often, a program flag rate will be used in conjunction with a flag rate to form the actual charge. For example, charge regular tuition, unless the student is registered in this program.

Interplay Patterns

Interplay fees are interpreted by the rules engine.

  • Incompatible fees: Certain fees are implicitly incompatible. For example, part-time fees and full-time fees, or a fee which is part of the full-time fees. In other cases, the incompatible fees will resolve situations where a fee is usually charged, but if a certain other fee is charged, it invalidates it. For example, in the case of special tuition rates for a certain course, for certain majors, the second rate would be incompatible with the original tuition rate and would be removed.
  • Combination Fee: A combination fee is one that is charged when the same fee is attached to both the AO and the PO. That is to say that a certain fee is charged to students in a certain program, taking certain courses.
  • Combination Exemption: A fee that's applied at the AO level, unless it also exists at the PO level. If a student is in a certain major, they are exempted from the fee.

Rate Types

Different types of fees and tuition found in the UMD CCP Documentation and the USC documentation. Both systems are

Base Terms

The model is designed to cover both tuition and fees, but is open to cover other types of rates too. These could be defined in this system and be used for other purposes.
There are three models of calculation for the final amount.

  • There is FLAT. A flat charge means that the amount of the transaction does not change. For example, a course that has a $100 fee is a FLAT charge. This is irrespective of the number of credits that a course involved, or indeed, if the course has credits.
  • There is FIXED. Fixed charges have a fixed amount per unit or credit. So a five credit course with a FIXED charge will be calculated by charging the amount of the fee * 5.
  • There is FLEXIBLE. Flexible charges have a non-linear scheme. For example, a course may have a fee attached that is charged at a rate of $100 for 1 unit, $200 for 2 units, and $250 for three units.

If a fee is FIXED or FLEXIBLE, it is part of the rate type name. All others are FLAT.

Rates may be capped (limited to a certain price during a certain range of units). Due to the nature of FLAT, FIXED and FLEXIBLE, it only make sense to cap those rates which are FIXED, as FLAT rate has no multiplier, and FLEXIBLE rates contain their own logic to mimic this behavior.

Tuition

KSA Name

Name at SI if know.

Rate Type

Description

Hourly Tuition (Fixed Rate)

 

tuition.credits.fixed

Tuition that is billed per credit hour. This may be subject to a maximum cap.

Hourly Tuition
(Flexible Rates)

 

tuition.credits.flexible

Tuition that is billed per credit hour. This may be subject to a maximum cap.

Course Tuition

 

tuition.ao

Tuition that is billed once per course (activity offering).

Flat Tuition

 

tuition.course

Tuition that is billed once per semester for a certain group of courses – for example, no matter how many courses from an MBA program are taken, a certain amount will be billed. This might also vary by cohort. This tends to be limited to a certain group of courses.

Flag Tuition

 

tuition.flag

A tuition rate that will be decided by the rules engine. For example, a school might have differing tuition rates based on student attributes (graduate or non graduate, or enrollment in a special program). This flag would be replaced by the rules engine to be the appropriate tuition rate given other circumstances.

One or more of these rate types would be attached to each incoming activity offering.

Understandings (based on UMD implementation)

At UMD, the following distinctions are made for tuition: (Each to its own TT)
Part-Time vs. Full-Time
Undergraduate vs. Graduate.
Resident vs. Nonresident.
This leads to eight classifications of tuition. It is possible that some of the full-time codes could be removed by the use of the override transactionType coupled with the cap amount (since replaced with the limit by credits concept), thought this might not be desirable for future maintainability.

Part Time or Full Time

Undergrad or Grad

Resident or Nonresident

UMD's T-Code

PT

UG

R

1040

PT

UG

NR

1050

PT

G

R

1120

PT

G

NR

1160

FT

U

R

1000

FT

U

NR

1020

FT

G

R

1100

FT

G

NR

1140

(Plus other changes, that are applicable at the AO level, e.g. Certain courses with attached remissions, etc., as well as other campus tuitions (Shady Grove tuition, following the same scheme or a different scheme for tuition but with different fees.) most of which can be handled by appropriate attachment at the AO level.
There are also public-policy tuition codes along with a host of other courses that charge tuition according to either a different model, or using the same model but using different transaction types. In other cases, there are tuition models which are only applicable to certain majors or programs, but override the regular tuition. {Example, the high school connection program}.

USC Understandings

USC has a number of different tuition rates, and they are attached at the program level. There is no (known) use of student-level attributes to decide the tuition rates. A student's rate is dependent on the courses that they are taking. Where a student takes a combination of tuition rates, the USC system goes through an algotrithm to "choose the rate" and then applies it to all the courses the student is taking. Fundamentally, a student taking a group of courses will pay the rate associated with the majority of them. If there is a tie, the USC system will apply the rate of the lowest limit rate.

AO Fees

KSA Name

Name at SI if know.

Rate Type

Description

Term Fee

 

fee.ao.term

A fee that is charged once per time period, regardless of the number of AOs it is attached to. This can be used to charge a fee if a student registers for one, or several of a group of courses. It is implicitly a "fixed" fee – i.e. one charge, regardless of the number of credit hours.

Fixed Per Credit Fee

USC – "Per Unit Fee" – Only "flexible" really exists at USC. (SB-2) (That is to say that the fixed fees are handled as flexible fees).

fee.ao.credits.fixed

A fee that is charged by the number of credit hours for each AO it is attached to. It is implicitly either a flat or flexible fee, due to the relation to credit hours.
Note, per SB-2, the TransactionType can change per rate. This means that the former working assumption that the fee code is the transaction code/type is not 100% true.

Flexible Per Credit Fee

USC – "Per Unit Fee" – Only "flexible" really exists at USC. (SB-2)

fee.ao.credits.flexible

A fee that is charged by the number of credit hours for each AO it is attached to. It is implicitly either a flat or flexible fee, due to the relation to credit hours.
Note, per SB-2, the TransactionType can change per rate.

Course Fee

USC – "Section Fee" (SB-1)

fee.ao.course

A fee that is charged once for each AO it is attached to. This is implicitly a "fixed" fee.

Annual Fee

 

fee.ao.annual

A fee that is only ever charged once to a student, per year. This is implicitly a fixed fee.

One-time Fee

 

fee.ao.once

A fee that is only ever charged once to a student, during their academic lifetime. This is implicitly a fixed fee.

Flag Fee

 

fee.ao.flag

This type of fee cannot actually be charged. Its existence tells the rule engine that it needs to do something specific.

Note that there is a possibility to make these fees dependent on the existence or non-existence of another.
These rate types would also be attached to the AO.
UMD drops the resident/nonresident tuition distinction for mandatory fees, but retains undergrad/grad, part-time, full-time. This could be handled as an undergraduate fee and a graduate fee with a flexible amount structure, or as four different fees.
USC's three fee types are in the table. USC's "in major/out of major" fees would be modeled as two different fees.

Fee Application Distinctions  (based on UMD implementation)

1202 – Fee if only one of the special courses are taken – probably can be done as an exception rule in the rules, but would be attached to the special courses.
1501 – A "once time per semester" fee for certain architecture courses.
3336 SG Aux Fee – Fee for students in a certain course, in a certain major, only.
3337 – Seems to be the same as 3336?

PO Fees – Attached to the program offering / major/ etc.?

KSA Name

Name at SI if know.

Rate Type

Description

Program Fee

 

fee.po.term

A fee that is charged once per time period, regardless of the number of AOs it is attached to. This can be used to charge a fee is a student registers for one, or several of a group of courses. It is implicitly a "fixed" fee – i.e. one charge, regardless of the number of credit hours.

Program Enrollment Fee

 

fee.po.once

A fee that is only ever charged once to a student, during their academic lifetime. This is implicitly a fixed fee.

Program Flag

 

fee.po.flag

This type of fee cannot actually be charged. Its existence tells the rule engine that it needs to do something specific. For instance, the existence of a certain flag on a PO might tell us to turn all the tuition flags into a certain type of tutition code.


1499 – Studio Lab fee only for students with a certain major – does not appear to attach to an AO
1556 - Journalism Professional Fee – PT and FT distinction for UG, G but not doctoral students.
1569 - MSBA Club Fee – for a single major.

Non-AO Fees

KSA Name

Name at SI if know.

Rate Type

Description

Late Fee

 

fee.late

A fee that is charged for late registration, etc.

General Fee

 

fee.general

A fee that is charged to a student if a certain number of circumstances are met – not specifically attached to an AO.

These are fees that might be incurred by a student that are not specifically attached to the AO. These fees would be referenced via the rules that are established in KSA-FM. There is an expectation that these are not attached to the AOs or POs, rather they are generated due to calculable situations that occur in rules processing.

Data Requirements from the Enrollment System of Record

Basic Overview:

Receipt of KS-ENR/ other system data will be used to create a "FeeManagementSession" object.

We'd need to know (The "term record")

Note: The names are just to give the idea- I'm sure the KS team already has vocabulary for many of these items that we can adopt. This is for validation only and is not a proposed model. Earlier records had understood the program offering to be the indicator of the major, etc. Cathy indicated that this is not true, and will be passed along with the term record. There will also be some modeling of a "cohort" code, which at last discussion, had not been fully considered by the KS-ENR people. For this model, we are recognizing those items purely as lists of String objects, expecting those to be more fully considered in future revisions.


  • Student (accountId)
  • AtpId for the "top level" (i.e. fall semester – minimesters, etc. can be attached to the individual signup lines, but the agreed use case was charging for a "term". Cathy informs me that there is a concept of "term" as a class 2 service, but ATP (which is class 1) appears to have taken off as the go to service. This is certainly true in KSA, where we rely exclusively on ATP.
  • status which can be WHAT_IF or ACTUAL – What if will trigger a calculation only, whereas ACTUAL will also produce transactions.
  • Any keypairs that you we are sent for the session (this might be used in a simulation to give us data that cannot be inferred from the signup – this would have to be done at implementation, though we can probably standardize some of them out of the box). This might, for example, contain data such as "what if the student is non-resident next semester" etc.
  • Signup objects. Probably a modified version of what is in the Class below. (Pretty much everything except id and isComplete, which are internal).

Class Signup (Intial proposed data structure for the signup items for KS)

The working version of this will be stored in the class document. It is here for reference only.

Attributes and Initial States

id

Internal identifier for the signup line.

registrationId

Identifier for the signup line from KS (Likely a UUID.) This would not change over time no matter how many times this line were sent to us.

creationDate

Date on which the action was taken by the student/ admin etc. for audit purposes.

effectiveDate

Date on which the action was placed. This would be the data against which a late fee would be applied, if applicable. From a student's end, this would be the same as creationDate. An administrative person might have the ability to alter this date (for example, if they were processing paper applications, etc.)

operation

See below for the operations.

offering

Pointer to the offering that was signed up for – We are looking for some type of AO id or PO id – is this something that can be one in the same or do we need a piece of data to distinguish?

atp

Specific ATP of the offering (will be the same as, or a subsection of the atp in the session.)

units

Number of units that the student signed up for. In our modeling, we allow a decimal up to two decimal places. Note that KS models this as a String. This may cause internationalization problems with the differing use of commas and periods in different locales.
Our internal storage of this is as units*100

rateData

List of attached Rates (String rateCode + String subCode)

isComplete

Internal field marking that the offering has been completely processed by the rules. This won't be passed in interface. It's set to true on completion in rules.

Signup Operations

Able to be performed by Student

Able to be performed by administrative user

ADD
DROP

ADD_WITHOUT_PENALTY
DROP_WITHOUT_PENALTY
TRANSFER_IN (SWAP)
TRANSFER_OUT (SWAP)

WITHDRAW(question)

WITHDRAW(question)


Note that withdraw is still under discussion. In the KS-ENR, you withdraw from a program, whereas in UMD's model (for which we have the fuller specification), withdrawal happens on all REMAINING courses, once the withdrawal happens. But it should be noted that any classes that were dropped prior to that are still billed as dropped, not withdrawn. I think (unconfirmed) that KS-ENR is expecting just to send us a "WITHDRAW" notification. If needed, we could take this notification and, using the prior session, create a withdraw record as needed. If KSA were responsible for this, the coordination if a withdrawal were reversed might become very complicated. (It's also inappropriate that KSA be responsible for this, if the institution themselves recognize same-term drop and withdraws.)

Prelimenary Overview of the DSL Requirements

These are based on UMD rules, taking into account known rules from USC. Please note that there is a much deeper process of these ideas in the Unifed Rule and Example documents.

List of FeeManagementPeriod Keypairs:

{These are the parameters that apply to all sessions in this ATP, essentially global setup for the period.}
Some of these (star) might be derived from the ATP itself.
(star) firstDayOfClass (First day of tuition, end of add/drop period)
(star) lastDayOfAddDrop (date after which drops are not eligible for a refund)
dropPenalty (percentage charged if a student drops in the add/drop window.)
This might be more or less complicated depending on the school's rules.
(*)withdrawDate1..5 – (Dates of the withdrawal permitted.)
(*)withdrawPercentage1..5 (Percentage of the withdrawal associated with withdrawDate1..5)
(*)lateRegistrationDate – (Date after which registration is late – probably same as firstDayOfClass)
Note that the percentage etc. with the KS-ATP is done by implication of the name of the ATP. (Eg. Withdrawal60, etc.)
These keypairs should be read-only.
The rules should also permit read-only access to information contained within the ATP for the session, and the ATPs attached to the signup lines.

Expected Rule Visibility

The rules are expected to be able to see/affect:

The session:

The signup, the keypairs on each signup item, the rates on each signup line, and the keypairs on each rate line.
The session keypairs for this session only.
The persistent keypairs, for information that has to persist over a student's lifetime.
The student keypairs, for information about the student that exist in this session only (graduate status, etc.)
The charge manifest for this session, including the charge manifest's keypairs.
The FeeManagementPeriodSettings (set for all sessions with this ATP) – cannot be changed inside rules.
Communication between semesters is done via persistent keypairs. In the event that a Fee is charged only once, we can set the marker as the ATP of the session that charged it.
For the sake of communication, we need to be able to add lines to the session log. The session log contains a type marker, and a text description. The log should be as descriptive as possible as each part of the rule set is processed. Why was something added/ removed/ changed/ charged.
When creating a charge (the rules need to be able to add charges etc. to the manifest), we can optionally define the rollup and tags.

Type of Keypair

Meaning – use

Lifetime

Set By

signup

Each line of the signup can have a keypair associated with it. This is included for expandability, where a signup item needs to signal something to the FM rules. They can also be set by the rule to allow us to track the status of each line of the signup as we go through the rule process.

Valid only for a session. These are temporary keypairs to allow tracking through the fee management session. When a new session is started, it will have new signup lines, and therefore the old keypairs will not be visible.

-FM-Rules
-From KS during the passing of signup data.

persistent

Associated with the student on a permanent basis. They keypair name or value should be used to reflect the time period if this is of limited applicability. For example, if we need to know that a fee was paid in spring 2012, the atp id might be attached to the name of the keypair. Note that the Boolean use of this should be used with an atp id so that you know if this was set in this session.

Fundamentally a "global" keypair for a student. Should be used sparingly.

Valid throughout all of the student's lifetime. Note that a secondary call to FM during the same session will show data run on the same session.

-FM-Rules
-Admin UI in KSA

session

Data about the student that affects fee management, for which KSA is not the responsible system. There is an agreed list of these keypairs, that can be extended by the institution. These will be pulled from the system of record at the start of a session.
These might be seen as "student" keypairs, as their data will most likely refer to student metadata.

In addition, the session itself might create keypairs to track its own data in the charging process.

Only within a session. These keypairs are prepopulated when the session begins, and can be added to during the session.

-FM-Rules
-From KS
-From session startup.

manifest

If data needs to be stored on a line of the manifest, they can be stored here.

Only with this specific manifest line.

-FM-Rules

rate

Keypairs can be associated with a rate directly. This might be used to flag incompatibilities of rates, etc.
Note that the rate keypairs can be inherited from the rate catalog. Access to both will be via rate keypairs.

Associated only with a specific rate.

-Admin UI
[Read-only from rules.]

FM Period Settings

For a given ATP there will be settings that drive that session. These are read-only within the session.

Valid for all FM sessions in this time period.

-Admin UI
[Read only from FM-Rules.]


The most commonly accessed keypairs (expected) will be the session, the signup and the FM period settings. The persistent keypairs will be used less commonly, but will be needed for cross-session communication. The remaining keypairs will be used far less commonly.

Session Keypairs

The session keypairs have a dual use. They can be used both by and during the session to store session related data, and they can be sent to the rules from an external system to give external information about the session. The most common use for this feature will be to send data to KSA regarding student statuses that are outside of the scope of KSA. For example, the residency status of a student, or their study level.
The following keypairs are expected to be standard, but an institution may add more as they are needed.

Keypair Name

Values

studyLevel

Undergraduate (UG), Postgraduate (PG), Doctoral (D)

residency

Instate (IS), Out of state (OS), OR, state/country of residency.

 

Examples of DSL that might be needed.

These are by way of example only

  • Set persistent keypair <keypair name> to <keypair value>
  • Set session keypair <keypair name> to <keypair value>
  • On signup <signup line> set keypair <keypair name> to <keypair value>
  • On manifest <manifest line> set keypair <keypair name> to <keypair value>
  • On rate <rate> get keypair <keypair name>
  • Get settings keypair <keypair>
  • Add session memo <type> <memo>

The Charge Manifest

The charge manifest is the end product of the fee management session, which will then be consumed by KSA and the appropriate charges will be applied to the account.

Each line of the charge manifest can be one of the following:

Type

Details

Extra information

CHARGE

Standard charge line for the manifest. This will become a transaction. The amount can be negative if needed.

Produced by rules.

CANCEL

A cancellation is a reduction of a prior charge. In general, a CANCEL will balance out a charge, or will at least partially balance out a charge. It is expected that a CANCEL will relate directly to a charge.

{Note that we do need a CHARGE/CANCEL even if they completely outweigh each other, because a CHARGE might have already been produced, and we need to make sure we cancel it if we need to, or we need to make sure that we do a partial cancel if we need to}

Produced by rules.

DISCOUNT

A discount is a cancellation, but unlike a CANCEL, might not have the same transaction type as its charge. For example, you might charge full tuition, but then discount to a different code in order to raise the revenue on one account and then bill the discount elsewhere. This is similar to producing a negative CHARGE on a different transaction type.

Produced by rules.

CORRECTION

A correction is a CHARGE from a prior session that was not raised in the current session (and therefore must be removed from the account.) Corrections are produced automatically during the reconciliation process that runs after the rules session.

Produced by the reconciliation system.

CORRECTED

A corrected transaction is one that reverses a CORRECTION transaction that has been added to the session.

Produced by the reconciliation system.


The lines of the manifest have an internal key. They can be related using the following combination keys:
signupId – all lines of the manifest with the same signupId will be from the same line of the signup. That is, they all apply to the same offering.
internalId & rate, OR offeringId & rate – these lines all refer to the same course or assessment. I.E. if the same course is added and dropped, they will match on offeringId & rate. If it is a compound calculation (one that is based on more than one course) then internalId & rate will be used.
We'll need the ability to find the previous (in this manifest) matching line of the manifest of a rate, signup line, etc.
When setting the lines of a charge manifest, the status should be set (see above).
The rate needs to be set, which can be used to automatically populate some of the fields.
The effectiveDate should be calculated from the rate. (But can be set by the rules)
The transaction type can be derived from the rate, but this derivation is done in rules.
The amount is derived from the rate.
Rollup and Tags can be added. With tags, the defaults from the transaction type are also applied. With the rollup, this will override the transaction type rollup.

Examples of DSL that might be needed.

These are by way of example only

(Most entries into the charge manifest will not really reference the manifest, and would be more direct. "Charge this")
Charge <rate> for <courseId>
Charge <rate> for <courseId> with amount of <amount/default> and effective date of <date/default> and transaction type of <transaction type id/default> and recognition date of <date/default>
Charge <rate> for internalId with amount of <amount/default> and effective date of <date/default> and transaction type of <transaction type id/default> and recognition date of <date/default>
Set rollup on charge to <rollup id>
Set tag on charge to <tag id>
Cancel <rate> for <courseId>
Discount <rate> for <courseId> by <percent> percent.
Discount <rate> for <courseId> by <amount> amount.
Discount <rate> for <internalId> by <percent> percent.
Discount <rate> for <internalId> by <amount> amount.

ATP

For each line of the signup, or for the whole signup, we need to be able to get the milestone values for the ATP. This might be used to get information such as the add/drop period ending for a specific course, etc.
Note the following predefined milestones in KS:
https://wiki.kuali.org/display/STUDENTDOC/%28CM+2.0%29+Tuition+Calculation+Milestones

Milestone Type Key

Type Name

Description

Responsible Organization

How used?

Rules

kuali.atp.milestone.Refund100

Refund 100

Cancel w/ 100% refund Date

Finance

Deadline

First day of classes

kuali.atp.milestone.Refund80

Refund 80

Cancel w/ 80% refund Date

Finance

Deadline

3rd week

kuali.atp.milestone.Refund60

Refund 60

Cancel w/ 60% refund Date

Finance

Deadline

4nd week

kuali.atp.milestone.Refund50

Refund 50

Cancel w/ 50% refund Date

Finance

Deadline

Winter term only, 2nd week of classes

kuali.atp.milestone.Refund40

Refund 40

Cancel w/ 40% refund Date

Finance

Deadline

5th week

kuali.atp.milestone.Refund20

Refund 20

Cancel w/ 20% refund Date

Finance

Deadline

6th week

 

(info) Note: These milestones do not match UMD's rules. They are similar only to the withdrawal rules.

Expected ATP Milestones for UMD

In the examples given, these have been used as expected milestone names.
kuali.atp.milestone.firstDayOfClass
kuali.atp.milestone.lateRegistration (Likely matches firstDayOfClass)
kuali.atp.milestone.lastDayForPenaltyDrop
kuali.atp.milestone.withdrawal80
kuali.atp.milestone.withdrawal60
kuali.atp.milestone.withdrawal40
kuali.atp.milestone.withdrawal20

Examples of DSL that might be needed.

These are by way of example only


Get milestonedate <milestone name>
Plus any appropriate comparisons (before, after, etc.)
Note most comparisons will be done against the effective date of the lines.

The Steps Through the Rules

Note that the examples given are from UMD's CCP 2013.
This part of the document is supplemented by the Unified Rule Layout document. The information presented here is more of an overview to that document.

The initial rule set- processing

The add/drops and seeing if we need to charge late fees, and the like.

Aim

Go through the add/drop records. Mark off if we need to charge fees, etc. on those records (removal of the Rate lines) and doing the initial charge of late fees, if needed.
Once this has been done, we should be in a position to decide if the student is full or part time.

Logic

In the initial scan, we can do the initial add/drop rules:

Command: WITHDRAW [Needs more review]

Intended Consequences

-        Remove the withdraw fee objects (fees are generally left on the account, even after withdraw.)

-        Other aspects of the withdraw will have to be handled in rules, later.

Remove the Rate objects for “*fee*” on this line.

Command: ADD

Intended Consequences

-        Add commands are something we will charge for.

-        There might be a late add penalty.

Check to see if it’s on or after firstDayOfClass, if true, charge late registration fee.

(Add a rate to manifest, of “late.registration.fee” with internal id of “lateRegCharge”)

 

All Rates can be left intact. (We expect to charge them at this point.)

Command: ADDWITHOUTPENALTY or TRANSFERIN

Intended Consequences

-        Essentially an ADD that cannot be charged as “late”. Other logic is identical to ADD.

All Rates can be left intact. (We expect to charge them at this point.)

 

Command: DROP

Intended Consequences

-        If the drop occurs after the allowable period, there might be a late fee.

-        If the drop is after a certain period, it might have no effect whatsoever. (in terms of charges).

-        There might be two different dates in the ATP for when fees and tuition might not be affected. These will be tracked by the different part of the calculation.

-        If the drop is legal, we will remove rates for both this line, AND the “add” (ADD, ADDWITHOUTPENALTY, TRANSFERIN) line that is for the same course that precedes this one.

Command: DROPWITHOUTPENALTY, TRANSFEROUT

Intended Consequences

-        The drop line is inherently legal. We will remove rates for both this line, AND the “add” (ADD, ADDWITHOUTPENALTY, TRANSFERIN) line that is for the same course that precedes this one.

-        Essentially neuter both the add and the drop records.

Full or Part Time

Count the credits associated with all add records that are marked as isComplete = false.
Compare this number to a fixed number in the keypairs for this ATP (which might be different depending on level of study) and set the session keypair "fullTime" to Y or N depending on this.
Not that there is a possibility that this information will just be provided to us by the registration system. This is wholly dependent on how the status is calculated, and if it is constant (might you be full time for courses, but only part time for mandatory fees, because some of your courses are exempted from those fees?)

Default Tuition Rates

It may be necessary to add the default tuition rate to all courses that do not have a special tuition rate already added to them. This might be a flag rate or a regular rate depending on the complexity of the charging system at the school. For specific classes or courses that have their own tuition rate that is specified at the AO or grouping level, this might be used as an exception.
A number of inferences may be brought about using standard known items about the student, or about the course, but not the course itself. So for example, if a course is taught at a specific campus, this may be used in the decision making process, or if the student is a graduate student, etc. In order to keep the lines between the systems clean, however, the rules should not have to check the specifics of the course (i.e. is this French 102) as that would necessitate new rules to be written when adding a new class which ought not to be necessary if the information is appropriately passed from KS, who are the system of record for course information.
It might also be necessary to replace all tuition rates with another tutition rate, based on a "majority rule" as with the system at USC. That is, if the majority of classes have law tuition attached, attach law tuition to all classes.

Default Fee Rates

For rates such as the "Mandatory campus fees" etc., it might be necessary to work in a similar way to default tuition. We can infer that a course has mandatory fees (and we add them in this step) UNLESS another mandatory fee flag is passed along with the course (that is, an exemption).

Always attaching to an AO

While some of the discussion around this topic has referenced the idea of inferring a tutition code of "regular" when there is no tutition code attached at the AO level (this has been a position taken by the KS team), one of the sponsoring instutitions made it clear that they do NOT want a system where lack of information has a meaning. As such they would NOT be using the inference system. As this is created in the rules, KSA needs to be able to support both models.
In this way, it would be necessary to attach the base tution model to each AO. KSA-FM would then be able to change that specific model if needed. This would be done by rate replacement based on known factors about a student or other factors that affect fee management. For example, replacement of the resident tuition rate with the non-resident tutition rate if appropriate.

Course "Knowledge"

For complete outlier cases, and to be able to support the way that UMD CURRENTLY does fee management, it might be necessary that KSA-FM recognize the course and section number, but this should be used as a last resort only because it would necessitate rewriting rules instead of correctly attaching rates at the AO level.
KSA-FM is designed primarily from the standpoint that it should be almost entirely ignorant of the actual courses being taken by a student. It is the interplay of the Rates that will cause the fee computation to happen. This allows the maximum possible control to be handed to the enrollment system, while retainting the control over the actual computation process within KSA using an agreed vocabulary of Rate and ATP to inform each system of the processing needs of the other.

Examples of DSL that might be needed.

These are by way of example only

  • Mark signup <signup> as complete.
  • Remove rate <rate> from signup <signup>
  • Replace rate <rate> on signup <signup> with rate <rate>
  • Remove rate of type <wildcard> from signup <signup>
  • Remove all rates on <signup>
  • For each signup without <rate> add <rate> etc.

 

Secondary Rule Processing

Processing of fee types, exemptions, etc.

Aim

At this point, all of the fees that are to be ignored by virtue of being legally dropped, etc. have been removed. It should be possible to replace many of the fees that are dependent on combinations, etc. (flag rates) with the appropriate actual rate.

Logic

Using keypairs and other derived information (number of credits, courses, etc.) Remove or replace certain rate codes.

Flag Fees

Example: If STUDY_LEVEL keypair is GRADUATE then replace fee.flat..bio.undergraduate or fee.flag..bio with fee.flat..bio.graduate
If STUDY_LEVEL keypair is DOCTORAL then remove fee.flag..bio (doctoral students are exempt.)
If PO line of {certain major} exists, then switch the "out of major" version of a fee to the "in major" version of a fee.

Incompatible Fees

Example: If a student has both mandatory fees and campus fees (mandatory fees include campus fees) then remove.
If fee1 and fee2 exist, remove fee2.
If fee3 and fee4 exist on the same signup line, remove fee4.

Combination Fees

Example: If a student is in a certain major, and takes a certain class, there is a fee.
If fee is on both a PO line and an AO line, remove from PO line. If only on AO line, remove altogether.

Combination Exemption

Example: If a student is in a certain major, and takes a certain class, the fee for that class is waived.
If a fee is on an AO line and is on a PO Line, remove from both.

Special Fees

Remove a certain fee if there is a keypair set for it… for example, a "charge once in a student lifetime" Fee.

UMD Rules

If

And

Other

Do this

mandatory.fee.flag..maincampus

studyLevel = UG

fullTime = y

Change all to fee.ao.term..undergrad.ft

mandatory.fee.flag..maincampus

studyLevel = UG

fullTime = n

Change all to fee.ao.term..undergrad.pt

mandatory.fee.flag..maincampus

studyLevel = GR/DR

fullTime = y

Change all to fee.ao.term..grad.ft

mandatory.fee.flag..maincampus

studyLevel = GR/DR

fullTime = n

Change all to fee.ao.term..grad.pt

mandatory.fee.flag.sg

fullTime = y

 

Change all to fee.ao.term..sg.ft

mandatory.fee.flag.sg

fullTime = n

 

Change all to fee.ao.term..sg.pt

fee.flag..mba

fullTime=y

 

Change to fee.term.mba.ft

fee.flag..mba

fullTime=n

 

Change to fee.term.mba.pt

fee.flag..jouralism

fullTime=y

 

Change to fee.term.journalism.ft

fee.flag..jouralism

fullTime=n

 

Change to fee.term.journalism.py

fee.flag.po..globalhealth does not exist

 

 

Remove fee.ao.term..global.health, global.health.aux, global.health.facilities from ALL courses.

fee.flag.technology*

Fulltime=y

 

Change to fee.ao.course..technology.ft

fee.flag.technology*

Fulltime=n

 

Change to fee.ao.course..technology.pt

fee.flag.po..architecture

Fulltime=y

 

Change to fee.term..architecture.ft

fee.flag.po..architecture

Fulltime=n

 

Change to fee.term..architecture.pt

(*)Note that these might be removed in further processing due to their incompatibility with the mandatory fees.

Tertiary Rule Processing

Aim

With the preprocessing from the secondary, we should now be able to charge (place on the manifest) the fee portion of the signup. By the end of the tertiary rules, all fees should have been charged.

Logic

Where rate type is:

fee.ao.term [no matter how many times this rate is listed on the account, charge it once this term]

Count the number of ADD/ADDWITHOUTPENALTY/TRANSFERIN this is attached to
Count the number of DROP/DROPWITHOUTPENALTY/TRANSFEROUT this is attached to.
If the number of "adds et al" exceeds the number of "drops et al" (i.e. it is attached to a course being taken!) then charge the rate once, using the rateId as the identifier (not the AO). The amount and transaction type will come from the only entry in RateAmount.
Mark all instances of the rate (in the rateData) as isComplete.
If the number of "adds et al" is the same as than the number of "drops et al" (i.e. i.e. it has been dropped (legally) an equal number of times as it has been added) then cancel the rate once, using the rateId as the identifier (not the AO) and mark all instances of the rate (in the rateData) as isComplete. The amount and transaction type will come from the only entry in RateAmount.
(Removed – we shouldn't need to cancel the rate off, because it will be handled during reconciliation.)

fee.ao.annual [Identical to term, as non-chargeable fees will have been removed in secondary][no matter how many times the rate is listed, charge it once per year. This will have to be tracked as a permanent keypair]

As the fee will have been removed in secondary processing, if this is present, we can charge.
Count the number of ADD/ADDWITHOUTPENALTY/TRANSFERIN with rateEligible = true this is attached to.
Count the number of DROP/DROPWITHOUTPENALTY/TRANSFEROUT with rateEligible =true this is attached to.
If the number of "adds et al" exceeds the number of "drops et al" (i.e. it is attached to a course being taken) then charge the rate once, using the rateId as the identifier (not the AO). The amount and transaction type will come from the only entry in RateAmount.
Mark all instances of the rate (in the rateData) as isComplete
If the number of "adds et al" is the same as than the number of "drops et al" (i.e. i.e. it has been dropped (legally) an equal number of times as it has been added) then cancel the rate once, using the rateId as the identifier (not the AO) and mark all instances of the rate (in the rateData) as isComplete. The amount and transaction type will come from the only entry in RateAmount.

fee.ao.once [Identical to fee.ao.term, as non-chargeable fees will have been removed in secondary] [UMD does not use fee.ao.once, so it is not referenced here.][No matter how many times a rate is listed, charge it once in the student's lifetime. This would have to be tracked as a permanent keypair]

As the non-chargeable fees will have been removed in secondary processing, if this is present, we can charge once, and mark as isComplete.

fee.ao.course [Charge the rate once per course, following the single amount that is listed in the rate]

For every AO with this rate, move to the manifest as a charge, using the line identifier. Mark the rate on the ao as isComplete. The amount and transaction type will come from the only entry in RateAmount.
For every AO with this rate, that is a "drop et al." with rateEligible = true, move to the manifest as a cancel, using the line identifier. Mark the rate on the ao as isComplete. The amount and transaction type will come from the only entry in RateAmount.

fee.ao.credits.fixed There is a possibility that we need a new fee type of "combined" where for as many courses there are that use the code, we add all the units together and then charge the amount based on that. (Fundamentally, working more along the same lines as tuition). This would be a fixed of flexible type arrangement, and would make more sense with the isCapped idea. UMD has no use case for this, but it might be worth working out the logic at this point. [Charge the rate for each line that has it in accordance with the number of credits attached]

For every AO with this rate, move to the manifest as a charge, using the AO identifier. Mark the rate on the AO as isComplete. The transaction type will come from the only entry in RateAmount. For the amount, take the amount from RateAmount, and multiply by units from the signup line. If this amount exceeds the cappedAmount, charge the capped amount.
For every AO with this rate, that is a "drop et al." with rateEligible = true, move to the manifest as a cancel, using the line identifier. Mark the rate on the ao as isComplete. The transaction type will come from the only entry in RateAmount. For the amount, take the amount from RateAmount, and multiply by units from the signup line. If this amount exceeds the cappedAmount, cancel the capped amount.

fee.ao.credits.flexible

For every AO with this rate, move to the manifest as a charge, using the line identifier. Mark the rate on the AO as isComplete. Look up the amount and transactionType in RateAmount using the number of units as the lookup keys. If this does not exist, use the default amount.

Quaternary Rule Processing

Aim

At this point, general fees should have been applied to the account. In this section, we look for special cases. This might include applying discounts, etc. to fees already placed. This should only be used for outlier cases. If they can be altered in the preprocessing at the secondary stage, they should be done there.

Logic

Unspecified at this time.

Quinary Rule Processing

Aim

Look for special tuition rates, and apply them to courses, convert the generic tuition flags to the appropriate tuition rates for the level/etc. of the student.

Logic

If this exists (!not)

And this

Replace this

With this

tuition.flag.po.eco.restoration

 

tuition.flag..regular

tuiton.course..eco.restoration

tuition.flag..gis

Residency=MD

tuition.flag..gis

tuition.credits.fixed..gis.resident

tuition.flag..gis

Residency !=MD

tuition.flag..gis

tuition.credits.fixed..gis.nonresident

tuition.flag.po..radar

 

tuition.flag..regular

tutions.credits.fixed..radar

tuition.flat.po..real.estate

 

tuition.course..real.estate

tuition.flag..regular

tuition.flat.po..persian

 

tuition.credits.fixed..persian

tuition.flag..regular

tuition.flat.po..arabic

 

tuition.credits.fixed..arabic

tuition.flag..regular

tuition.flag..dets.closed

Residency=MD

tuition.flag..dets.closed

tuition.credits.fixed..dets.closed.resident

tuition.flag..dets.closed

Residency=!MD

tuition.flag..dets.closed

tuition.credits.fixed..dets.closed.nonresident

tuition.flag..dets.open

Residency=MD

tuition.flag..dets.open

tuition.credits.fixed..dets.open.resident

tuition.flag..dets.open

Residency=!MD

tuition.flag..dets.open

tuition.credits.fixed..dets.open.nonresident

!tuition.flag.po.bmsb

 

tuition.flag..accounting

tuition.flag..regular

tuition.flag.po.bmsb

Residency=MD

tuition.flag..accounting

tuition.credits.fixed..accounting.resident

tuition.flag.po.bmsb

Residency=!MD

tuition.flag..accounting

tuition.credits.fixed..accounting.resident

!tuition.flag.po.bmsb

 

tuition.flag..accounting.dc

tuition.flag..regular

!tuition.flag.po.bmsb

 

tuition.flag..accounting.sg

tuition.flag..regular

!flag.tution.po..vtt

 

tuition.credits.fixed..vtt

tuition.flag..regular

!flag.tution.po..mps

 

tution.course..mps

tuition.flag..regular

!flag.tution.po..jouranlism

 

tution.credits.fixed..journalism

tuition.flag..regular

!flag.tution.po..mps

 

tution.ao.credits.fixed..mps

tuition.flag..regular

!flag.tution.po..mpao

 

tution.ao.credits.fixed..mpao

tuition.flag..regular

tuition.flag.po..freshman.connection

Residency=MD

tuition.flag..regular

tuition.flat..freshmen.connection.resident

tuition.flag.po..freshman.connection

Residency=!MD

tuition.flag..regular

tuition.flat..freshmen.connection.nonresident

!tuition.flag.po..mred

 

tuition.flat.mred

tuition.flat..regular

!tuition.flag.po..mait

 

tuition.credits.fixed..mait

tuition.flat..regular

tuition.flag.po..mred

Residency=MD

tuition.flag..regular

tuition.credits.fixed..mred.resident

tuition.flag.po..mred

Residency=!MD

tuition.flag..regular

tuition.credits.fixed..mred.nonresident

tuition.flag.po..sph

Residency=MD

tuition.flag..regular

tuition.credits.fixed..public.health.resident
tuition.credits.fixed..public.health.resident.differential

tuition.flag.po..sph

Residency=!MD

tuition.flag..regular

tuition.credits.fixed..public.health.nonresident

tuition.credits.fixed..public.health.resident.differential

tuition.flag.po..sphl

 

tuition.credits.fixed..sphl

tuition.flag..regular

tuition.flag..mls.online

Residency=MD

tuition.flag..mls.online

tuition.flag..mls.online.resident

tuition.flag..mls.online

Residency=!MD

tuition.flag..mls.online

tuition.flag..mls.online.nonresident

tuition.flag..mls.graduate.tuition.sg

Residency=MD

tuition.flag..mls.graduate.tuition.sg

tuition.credits.fixed..mls.grauate.tuition.sg.resident

tuition.flag..mls.graduate.tuition.sg

Residency=!MD

tuition.flag..mls.graduate.tuition.sg

tuition.credits.fixed..mls.grauate.tuition.sg.nonresident

tuition.flag..public.policy.dc

Residency=MD

tuition.flag..public.policy.dc

tuition.credits.fixed..public.policy.dc.resident

tuition.flag..public.policy.dc

Residency=!MD

tuition.flag..public.policy.dc

tuition.credits.fixed..public.policy.dc.nonresident

tuition.flag..jpsm.graduate.tuition

Residency=MD

tuition.flag..jpsm.graduate.tuition

tuition.credits.fixed..graduate.jpsm.resident

tuition.flag..jpsm.graduate.tuition

Residency=!MD

tuition.flag..jpsm.graduate.tuition

tuition.credits.fixed..graduate.jpsm.nonresident

tuition.flag.po...frostburg

Residency=MD

tuition.flag..regular

tuition.credits.fixed..collaborative.engineering.resident
tuition.credits.fixed..

collaborative.engineering.resident.frostburg.differential

tuition.flag.po...umes

Residency=MD

tuition.flag..regular

tuition.credits.fixed..collaborative.engineering.resident
tuition.credits.fixed..

collaborative.engineering.resident.umes.differential

tuition.flag.po...ssu

Residency=MD

tuition.flag..regular

tuition.credits.fixed..collaborative.engineering.resident
tuition.credits.fixed..

collaborative.engineering.resident.ssu.differential

tuition.flag.po...frostburg

Residency=!MD

tuition.flag..regular

tuition.credits.fixed..collaborative.engineering.nonresident
tuition.credits.fixed..

collaborative.engineering.nonresident.frostburg.differential

tuition.flag.po...umes

Residency=!MD

tuition.flag..regular

tuition.credits.fixed..collaborative.engineering.nonresident
tuition.credits.fixed..

collaborative.engineering.nonresident.umes.differential

tuition.flag.po...ssu

Residency=!MD

tuition.flag..regular

tuition.credits.fixed..collaborative.engineering.nonresident
tuition.credits.fixed..

collaborative.engineering.nonresident.ssu.differential

tuition.flag..business

Residency=MD

tuition.flag.business

tuition.credits.fixed..graduate.business.resident
tuition.credits.fixed..graduate.business.resident.differential

tuition.flag..business

Residency=!MD

tuition.flag.business

tuition.credits.fixed..graduate.business.nonresident
tuition.credits.fixed..graduate.business.nonresident.differential

tuition.flag.po..cybersecurity

 

tuition.flag..regular

tuition.credits.fixed..cybersecurity

tuition.flag.po..public.policy

Residency=MD

tuition.flag..regular

tuition.credits.fixed..public.policy.resident
tuition.credits.fixed..public.policy.resident.differential

tuition.flag.po..public.policy

Residency=!MD

tuition.flag..regular

tuition.credits.fixed..public.policy.nonresident
tuition.credits.fixed..public.policy.nonresident.differential

 

Once this has executed, only standard tuition flags should remain for processing.

Resident

StudyLevel

FT/PT

Replace This

With This

MD

UG

FT

tuition.flag..regular

tuition.credits.fixed..cp.undergrad.resident.ft

MD

UG

PT

tuition.flag..regular

tuition.credits.fixed..cp.undergrad.resident.pt

MD

GR/DR

FT

tuition.flag..regular

tuitions.credits.fixed..cp.graudate.resident.ft

MD

GR/DR

PT

tuition.flag..regular

tuitions.credits.fixed..cp.graudate.resident.pt

!MD

UG

FT

tuition.flag..regular

tuition.credits.fixed..cp.undergrad.nonresident.ft

!MD

UG

PT

tuition.flag..regular

tuition.credits.fixed..cp.undergrad.nonresident.pt

!MD

GR/DR

FT

tuition.flag..regular

tuitions.credits.fixed..cp.graudate.nonresident.ft

!MD

GR/DR

PT

tuition.flag..regular

tuitions.credits.fixed..cp.graudate.resident.pt

MD

 

 

tuition.flag..sg

tuition.credits.fixed..sg.resident

!MD

 

 

tuition.flag..sg

tuition.credits.fixed..sg.nonresident

Then, IF there is an MTAP waiver:
(If there is tution.flag..mtap)

Where there is this:

Add this:

tuition.credits.fixed..cp.undergrad.resident.ft

tuition.credits.fixed..cp.undergrad.resident.ft.discount

tuition.credits.fixed..cp.undergrad.resident.pt

tuition.credits.fixed..cp.undergrad.resident.pt.discount

tuitions.credits.fixed..cp.graudate.resident.ft

tuitions.credits.fixed..cp.graudate.resident.ft.discount

tuitions.credits.fixed..cp.graudate.resident.pt

tuitions.credits.fixed..cp.graudate.resident.pt.discount

tuition.credits.fixed..cp.undergrad.nonresident.ft

tuition.credits.fixed..cp.undergrad.nonresident.ft.discount

tuition.credits.fixed..cp.undergrad.nonresident.pt

tuition.credits.fixed..cp.undergrad.nonresident.pt.discount

tuitions.credits.fixed..cp.graudate.nonresident.ft

tuitions.credits.fixed..cp.graudate.nonresident.ft.discount

tuitions.credits.fixed..cp.graudate.resident.pt

tuitions.credits.fixed..cp.graudate.resident.pt.discount

tuition.credits.fixed..sg.resident

tuition.credits.fixed..sg.resident.discount

tuition.credits.fixed..sg.nonresident

tuition.credits.fixed..sg.nonresident.discount

Senary Rule Processing

Aim

By this point, all fees and discounts should have been applied to the manifest. Only tuition should remain at this point. By now, all tuition flags should have been converted to actual rates that can now be charged.

Logic

tuition.flat (Charge the same rate for a group of classes)

Get each line that carries the tuition.flat rate. Mark all of them as isComplete.
Move the rate to the manifest as a charge using the amount and transaction type from Rate.

If there are lines with penaltyDrop attached {I need verification from Ted about this}

Add a charge using rate code "fee.tuition.penalty" equal to 20% of the amount charged under tuition.flat. {Ted validated that if it's a flat fee for a group and you drop part of the group, there is no penalty. This might not be the case at other institutions.}
{We probably need to build in some keypair here for "unless waiveTuitionPenalty2013-1" is true for this student}

tuition.flat (Charge the tuition rate on a per-class basis. Usually for non-credit-bearing classes)


Using the rate, default transaction type and amount. Mark as isComplete.

{I'm a little mixed here with the old way I was doing it and the new way. We'll have to do something like this to deal with the add/drop penalty, but for right now, I'm trying to solve the issue of charging a student, before I get to the penalties).

If there is a penaltyDrop {Checking this with Ted}

Charge a penalty rate of 20% of the amount of the original rate. Mark both as isComplete.

tuition.credits.flexible

Charge by the number of credits/units attached to a course. This is a non-linear progression, so 5 units != (necessarily) 5x the cost or 1 unit. 1 unit might be 50$, 2 units 100$, 3 units 125$, etc.
I don't believe UMD or USC actually has this rate. It's included for completeness. I will ignore here. (USC DOES however use it for fees, hence the RateService supporting this model.)

tuition.credits.fixed

Charge by the number of credits/units attached to a course. This is a linear progression, so 5 units = 5x the cost or 1 unit.
For each line that has the ratetype of tuition.credits.fixed, and the same rate:
Count the number of units.
Mark those lines/rates as isComplete
Calculate the correct amount by multiplying the amount in the rate by the number of units, and subjecting to cappedAmount if present.
Add this as a charge to the manifest under the rate code (not the AO, as it is for multiple AOs)
{Still need to work on drop logic, here}
Calculate the number of units associated with penaltyDrop
Calculate the old tuition amount by getting the credits by adding the current units (above) to the penalty units (just calculated).
Calculate the amount again, using the rate, units, and the cappedAmount if present.
If the old tuition (just calculated) is higher than the current tuition, calculate the difference, multiply by tuitionPenaltyPercentage (set for session) and add as a charge under the tuition penalty rate.
Mark all the rates as isComplete.

Septenary Rule Processing

Aim

This is to handle the special withdrawal rules.

Logic

For each withdraw command, find the latest line in the manifest that refers to this course that is a tuition code.

THIS LOGIC IS INCOMPLETE AND NEEDS MORE WORK.


Compare the effectiveDate to the withdrawDate[1..5] to find which band the effectiveDate falls in to (If after 1 but before 2, it's band 1, if after 2 but before 3,band 2… if after 5, there is no band.
Get the appropriate percentage from withdrawPercenage1..5
For each tuition code, issue a cancel of the percentage amount referenced in the latest tuition line of the manifest.

Octonary Rule Processing

Aim

This is the cleanup part of the rule – are there any incompatible charges on the account that we need to look at. Are there any two fees that can't be charged together? Are there any special statuses that have not been done elsewhere? This is the catch all. We should be able to look at keypairs, the signup list,

Logic

Unknown at this point.

After the Rules Execute

The rules portion of this serves to create a fee manifest. This is the sum total of all items that should be billed to the student. It is not a differential. That is to say, if a student has already been charged a fee, it will AGAIN be present in this version.
We now pass on this manifest back to the main KSA code, which will look at prior charging sessions, and work out all differential charges. This is done through the chargeSession() logic which can be found in the regular process diagrams.

Appendix A

Fee and tuition model patterns known from USC/UMD. Note that KSA doesn't specifically distinguish tuition from fees except at a conceptual level (They are both forms of "Rate") but these are the known patterns expressed by their most common usage at the institutions.
Caps and limits are conceptualized in the same way – a Rate can be set to a limit between credit ranges. If the upper credit range is non-attainable, this acts as a cap.

Credit-Based Tutition Models


Commonly used for standard rates for some types of students at UMD (those that are not subject to a per-credit cap.) Also used for some programs at USC that do not have a limit rate (called a flat rate at USC).
This is conceptualized as tuition.credits.fixed

Commonly used for standard rates for some types of students at UMD (in-state undergraduate rate, for example.) I do not believe this is used at USC. This model is in fact the same as the limit rate (coming up) but it it simply has no upper bound.
This is also conceptualized as tuition.credits.fixed

Commonly used at USC. The "limit area" is known as the flat rate at that institution. Note that by setting the upper limit on the credits to an impossibly high amount, we could mimick the flat rate with a cap pattern with this.
This is also conceptualized as tuition.credits.fixed

Note that the "limit rate" is actually defined as a dollar amount, because it might not be the linear value set by the flat rate * the smallest number of units in the limit. This model is used at USC.
This is also conceptualized as tuition.credits.fixed

Mathematically identical to the limit rate. I don't believe this model is in use at either institution, but can be created with the design as it stands.
This is also conceptualized as tuition.credits.fixed

Course-Based Tuition Models


Similar pattern to the credit-based model, however the credits are either irrelevant, or do not exist in the case of non-credit bearing courses. This would be a pattern for a group of courses that charge in this way. Equally, for one-off courses, a single charge could be raised in the appropriate amount for the one course. Both of these patterns are in use at UMD. USC uses this model, however this is out of scope for the system at this moment according to Steve (the charging for these type of courses is handled elsewhere).
This is conceptualized as tuition.course

For a certain subset of courses (MBA being a common subset) or for a certain combination of student attributes or program affiliation, the student is billed a flat rate of tuition no matter how many courses or credits they take. This model is in use at UMD.
This is tuition.flat

Note that there is no known use case for this model at either sponsoring instutiton, but as the model allows for it, it has been recorded as tuition.credits.flexible
As all amounts have to be done in advance, this model is unlikely, especially in a scenaraio where half credits can be taken.

Credit/ Course Based Fee Models


An amount is charged for each credit the student takes. For example, if you take 12 biology credits, your bio fee might be 12* a certain amount. In use at USC and UMD.
This model is conceptualized as fee.ao.credits.fixed

Similar to the per-credit model, but charged on a course, so if you take 3 French courses, you will be charged 3* the amount, regardless of how many credits a course might have. This is in use at UMD.
This is conceptuazlied as fee.ao.course

Charge once, regardless model is used for courses that attract a lab fee, but the amount is fixed, regardless of the number of courses you take. For example, if you take an architecture course, you pay an architecture lab fee, which is the same regardless of the number of courses or credits you take with the fee attached. This is in use at UMD.
This is conceptualized as fee.ao.term

Certain fees charge at a certain number of credits. For example, if total credits is under 12, charge a lower rate than if the total credits are 12 or over. This is in use at UMD with the part/full time mandatory fees.
This is conceptualized as a fee.ao.term, however, the rate will be switched based on student attributes (in this case, the full or part-time status of the student.)

The discrete (flexible) fee model, the fee contains a dollar amount for each step in credits (for example, $100 for 1 credit, $200 for 2 credits, $250 for 3 credits, and so on.) This model is very common at USC (and in fact, is how they also handle the flat-rate per credit model. They simply program linear amounts into the stepping system. Note that this model also allows for the transaction type to change over the steps, so 1-3 credits might be raised as transaction type A, whereas 4-9 credits might be raised as transaction type B.
This is conceptualized as fee.ao.flexible

Program Models

Note that fee.po.term works in exactly the same was as fee.ao.term, but it is attached to a program offering rather than an activity offering.

Unlisted Models

Note that fee.ao.once and fee.ao.annual are, in essence the same as fee.ao.term, however, the rule engine will have to check to see if that charge has been raised before, and if so, suppress the charge. Equally, fee.po.once equates directly to fee.po.term, but will be suppressed by rules if it has previously been charged.

  • No labels