Subscription — Overview

Subscription handles long-term enrollment + recurring billing: enroll in a "package", the system creates period-based billing schedules, issues invoices, and manages class booking, Enrichment, add-ons, and discounts per period.

Quick picture

Think of a learning center selling a "term package":

1. Admin creates a Subscription (package): name, price, schedule, booking conditions.
2. Customer / admin enrolls a student → creates an Enrollment.
3. System builds a BillingSchedule (billing periods, each with an amount).
4. On schedule, each period creates an Invoice; admin schedule / approve / skip.
5. During the process: add add-ons, apply discounts per period; optionally skip a period.
6. Each booking lifecycle step (submitted/confirmed/cancelled) sends notifications to the customer & staff; admin tracks invoice generation progress in Subscription Billing Manager.
7. If the package has Enrichment, select dates in Step 2; the Enrichment fee belongs to Booking and is not added to recurring Subscription Billing.

Two Subscription types

Type	Subscription.TypeId	Meaning
BookingAndBilling (default)	null/0	Books class places and collects money; requires SubscriptionProduct (Program) setup.
BillingOnly	1	Recurring billing only; skips booking-product validation, hides Program section.

Main "objects"

Name	One sentence
Subscription	Package/template: price, schedule, booking conditions.
Enrollment	Runtime enrollment, with Submitted→Approved→Confirmed lifecycle.
BillingSchedule	Period-based billing schedule; canonical source for booking period selection.
Invoice	Invoice per period, with financial status lifecycle.
Add-on / Discount	Extra service / discount applied per booked period.
Enrichment	Weekday-based service selection; its fee becomes a Booking line per occurrence.
Term	Academic period; subscription links to term.

Suggested reading order

1. End-user view — what admin and customer do.
2. Core concepts — Subscription vs Enrollment, billing, booking.
3. Architecture & data — tables and relationships.
4. Codebase flow — API, service, validation.
5. Data & read/write tables — what Term is, tables by flow.
6. Common cases — skip, add-on, double-booking, etc.

Current implementation

• A Subscription may have a Flyer, invoice split rule and Manual/Auto billing generation. Published setup locks price, billing settings, linked Term, schedule and add-on product/bus-stop configuration at API/UI level.
• Subscription Manager operations live under api/SubscriptionManager/* and are strictly BU-scoped. SBK search is exact numeric search; Term badges count distinct pending enrollments in the current BU/site scope.
• Enrichment can be linked only when the Product is active/approved, has a valid TermProduct, rate, and accounting item; its fee is created in TermBookingLine, not through EnrollmentExtra or Subscription Billing.
• Duplicate copies setup only and remains Unpublished/Unbookable; Rollover moves existing runtime to an active linked future Term without creating a new Subscription or finance record. Extend adds an adjacent future period in the same Term.
• Billing automation schedules one existing job for the earliest unbilled invoice date; unpublish or Manual cancels pending work, and failures stop at the affected period without backfill.

Real-world example: An admin publishes a package and later tries to change its price. → The entire mixed request is rejected until the package is unpublished; editable metadata such as description remains separate.