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:
- Every point transaction line carries
date_valid_fromanddate_valid_to. They are set where the points were awarded: the document line’s point start and end dates (MembershipPointsTxnServiceL709–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. - Each line becomes a control-account lot (
bl_crm_membership_points_ctrl_acc, withdate_start,date_endandnext_expiry_date_check). Redemptions draw down lots; the Points Expiry tab of Membership Edit lists them. MEMBERSHIP_EXPIRY_POINTS_ELIMINATION_PROCESSORselects every active lot withbalance_amount > 0 AND date_end <= NOW(), writes anEXPIRYtransaction 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
EXPIRYrows 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
| Symptom | Cause | Fix |
|---|---|---|
| Points expired unexpectedly | The lot’s date_end passed and the processor ran | Extend the valid-to on a new adjustment; the old lot cannot be revived |
| Points never expire | The elimination processor is not scheduled, or the lots have no end date | Schedule it; give every source a validity |
| Reminder e-mails not sent | Reminder processor not scheduled, or members have no e-mail | Scheduler; member records |