Tuition: plans, discounts and the financial mirror
Build the tuition plan in versions with effective dates, declare exactly how each discount combines with the others (adds up, applies alone, ceiling and order), and follow each student balance mirrored from your financial system, always with the age of the data on screen. Part of the Education vertical, optional and off until an administrator activates it.
The Education screen gains a Tuition block: the price plan in versions, the discounts with their combination rule written down, and the student financial mirror.
What the CRM does not do here
The CRM does not bill tuition, does not issue payment slips or invoices, and there is no dunning cycle. Charges and payments appear because your financial system reported them. Billing stays where it is.
Plans in versions, with effective dates
Each plan has a stable code and one version per price. To raise the price, create a new version with the date it starts to apply. The system picks the version that was in effect on any given date, so changing the price today never changes a past charge and never touches a signed contract.
Amounts are stored in cents with the currency next to them, and the plan can declare a maximum discount: the ceiling for everything added together.
Discounts: say how they combine
Every discount declares its own combination. It either adds up with the others, or it applies alone. Discounts sharing an exclusive group compete with each other and only the best one enters. A percentage can apply to the full amount or to the remaining balance, in cascade. The order comes from the Order field and ties are broken by code, so the result is always the same.
When the total goes past the plan ceiling, the system trims from the last discount backwards: the highest priority one survives intact and the screen shows which one was trimmed.
Simulation
The simulation shows the full amount, the discounts applied in order, the net amount and the installment. Nothing is saved and nobody is charged. It also lists what was left out and why: outside its effective dates, lost the group, ceiling reached, condition not met.
Financial mirror with a freshness seal
The student financial block shows charged, paid, balance, overdue and next due date. Every row carries the source system and the date it was read, and the screen says honestly when the data is stale or when there is no data at all. Overdue is derived on read, from the due date and the balance.
Data comes in through a CSV file or your ERP integration, and it is idempotent: reimporting the same file updates the rows and never duplicates them.