Bill renewals in runs, on demand or on a schedule

Purpose

Each renewal season the association invoices members whose terms are ending, reminds them, warns those whose stored card will expire, and drops those who did not renew. An administrator needs to see exactly what a run will do before it does it, and to trust that nothing is done twice.

How It Works

An administrator keeps billing templates: a program, filters on types and packages, the actions wanted, and the reason to record on drops. A run is created from a template over a range of term end dates and planned on a business date. Planning takes the committed terms ending in the range, leaves out renewed, never-ending, suspended and organization-child memberships, and classes each term as renewing or lapsed by its grace. A renewing member is planned a renewal order (or an auto-renewal order when a payment method is stored), a notice and reminders. A lapsed member is planned a drop. The plan counts everything so it can be reviewed. Executing runs on the durable jobs engine and acts on each action once. An action whose term changed since planning does nothing. Orders are prepared through Membership's own checkout preparation and placed with a retry key. Notices go through Platform's communications to the member's first e-mail address. Drops terminate the term with the run's reason. A recurring run repeats a template on a schedule in the association's time zone. Today renewal orders cannot reach Commerce and notices are stored but not sent. Organizations receive no notices.

Relationships

• Depends on CAP-MBR-MEM-009 because renewal orders are prepared exactly as a checkout is.
• Depends on CAP-MBR-MEM-003 because a drop is a staff termination.
• Depends on Platform's communications (MOD-PFM-NOT) and durable jobs (MOD-PFM-OPS), and on Commerce orders (MOD-COM-ORD).