Recurring Billing Without Drift

Recurring Billing Without Drift

A subscription signed on January 31 bills at the end of every month — forever. The naive schedule engine computes each billing date from the previous one, so after the first February every date is stuck on the 28th: the contract silently loses three days a month, and nobody notices until an auditor reconciles a year of invoices. This is a real production-incident generator in subscription billing, and you are going to build the engine the way it must be built: every occurrence measured from the contract's anchor date.

Requirements

The starter contains a table "Billing Occurrence" — keep it exactly as shipped, the grading tests read it by name:

• "Occurrence No." — Integer, the primary key, numbered from 1
• "Period Date" — Date, the raw schedule date, measured from the anchor
• "Billing Date" — Date, the period date with the billing adjustment applied

Create a codeunit named "Recurring Schedule Engine" with one public procedure:

procedure Generate(AnchorDate: Date; RecurrenceText: Text; AdjustmentText: Text; Occurrences: Integer; var BillingOccurrence: Record "Billing Occurrence")

Rules:

1. RecurrenceText describes one schedule step as a date-formula text in language-independent form: <, a whole number N ≥ 1, one unit letter D, W, M, Q or Y, then > — e.g. <1M>, <2M>, <1Q>, <14D>.
2. Generate empties the buffer it receives, then inserts exactly one row per occurrence, "Occurrence No." running from 1 to Occurrences.
3. The "Period Date" of occurrence 1 is the anchor date itself. Occurrence k lies k − 1 steps after the anchor, and every occurrence is measured from the anchor — never from the previous occurrence.
4. Day and week steps are exact arithmetic: occurrence k is the anchor plus (k − 1) × N days for unit D, or (k − 1) × N × 7 days for unit W.