Skip to content

Expiry Rules

The previous version of this page described fixed-term, rolling, calendar-based and tiered expiry rules. None of those is a screen in BigLedger. Expiry works like this:

  1. Every point transaction line carries date_valid_from and date_valid_to. They are set where the points were awarded: the document line’s point start and end dates (MembershipPointsTxnService L709–L710 — which a price-book Point treatment supplies), the commission scheme treatment’s Validity Period (Days) counted from the document date, the Valid Date From / To on a manual Add Point Adjustment, or the validity columns of the Upload Member Point Transaction CSV.
  2. Each line becomes a control-account lot (bl_crm_membership_points_ctrl_acc, with date_start, date_end and next_expiry_date_check). Redemptions draw down lots; the Points Expiry tab of Membership Edit lists them.
  3. MEMBERSHIP_EXPIRY_POINTS_ELIMINATION_PROCESSOR selects every active lot with balance_amount > 0 AND date_end <= NOW(), writes an EXPIRY transaction line for the balance and zeroes the lot (MembershipCtrlAccAndCurrentBalanceService.expireMembershipPoints, L273–L276). It runs when the Scheduler runs it; if nobody schedules it, nothing ever expires.

Two companions: MEMBERSHIP_POINTS_EXPIRY_REMINDER_PROCESSOR e-mails members whose points are about to expire, and MEMBERSHIP_STATUS_UPDATE_ZERO_BALANCE_PROCESSOR sets a member inactive once the balance in a currency reaches zero. Both are also scheduled jobs.

Where to do this

  • The validity on each source: the Point treatment in Pricebook, Validity Period (Days) in Commission Scheme, Valid Date From / To on Add Point Adjustment.
  • The schedule: Scheduler — the three processors above.
  • The evidence: the Points Expiry tab on the member, and the EXPIRY rows on the Point Transaction tab.

Decide before go-live

  • One validity convention for every source. If the price book gives twelve months and a manual adjustment gives none, the member’s balance is a mix of lots that expire and lots that never do.
  • Whether to run the reminder — it is the only member-facing expiry notice the product sends.
  • Whether zero-balance members should go inactive. For a retailer that is usually wrong (a member who spent everything is a good member); leave that processor unscheduled unless membership is points-funded.

What this is not

Expiry does not post anything. The EXPIRY line reduces a balance; no journal is written and no breakage income is recognised — see Points Setup.

When it goes wrong

SymptomCauseFix
Points expired unexpectedlyThe lot’s date_end passed and the processor ranExtend the valid-to on a new adjustment; the old lot cannot be revived
Points never expireThe elimination processor is not scheduled, or the lots have no end dateSchedule it; give every source a validity
Reminder e-mails not sentReminder processor not scheduled, or members have no e-mailScheduler; member records