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 a valid-from and a valid-to date. They are set where the points were awarded:

   • a price-book Point treatment: Validity Period (Days) counted from the moment the points are worked out — at the till when the line is added, or on the server when it fills them in;
   • a commission scheme treatment: Validity Period (Days) counted from the document date. The field defaults to 0, and 0 means the points end on the document’s own date — the first expiry run takes them;
   • the Valid Date From / To on a manual Add Point Adjustment, or the validity columns of the Upload Member Point Transaction CSV.

   A line saved with no dates at all is given an end date of 31 December 9000: it never expires, and that is the date you will see on the Points Expiry tab.

2. Each earning line becomes a lot with a start date, an end date and a next expiry check. Redemptions draw down lots, the soonest-ending first, and only lots whose end date has not passed. The Points Expiry tab of Membership Edit lists them.

3. MEMBERSHIP_EXPIRY_POINTS_ELIMINATION_PROCESSOR (its name in the Scheduler applet’s processor picker) selects every active lot with a balance whose end date has passed, writes an EXPIRY transaction line for the balance and zeroes the lot. It runs when the Scheduler runs it. It is not one of the clocks a new tenant is given, so if nobody schedules it, nothing ever expires.

Two other processors carry expiry-sounding names, and neither does what its name says:

• MEMBERSHIP_POINTS_EXPIRY_REMINDER_PROCESSOR sends no e-mail. It runs the same expiry as the elimination processor. The one-month reminder e-mail exists in the product, but only behind an API call; nothing on a schedule sends it.
• MEMBERSHIP_STATUS_UPDATE_ZERO_BALANCE_PROCESSOR sets a member inactive when their balance reaches zero — only in a point currency coded ACCESS. For any other currency it changes nothing.

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 elimination processor.
• 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. Check every commission scheme’s Validity Period (Days) too: a scheme left at 0 awards points that expire the day they are earned.
• How members will hear that points are about to expire. The product will not tell them: scheduling the “expiry reminder” processor expires points and sends nothing. The notice is yours — a campaign, a receipt line, a till prompt — and it belongs in your programme terms.
• Whether zero-balance members should go inactive. For a retailer that is usually wrong (a member who spent everything is a good member). The processor only acts on a currency coded ACCESS, so leave it unscheduled unless membership is points-funded and your currency carries that code.

Prove that something actually expired, a week after go-live

A registered processor is not a scheduled one, and a scheduled one is not one that has run. The distinction is invisible from every screen in Membership Admin: an expiry policy written into your price sets looks identical whether or not anything sweeps.

So whoever configures the tenant checks it once, deliberately, and it takes two minutes. Find a member with a lot whose end date has passed — the Points Expiry tab lists the dates — and look for an EXPIRY row on their Point Transaction tab dated after the processor’s first run. No EXPIRY row means nothing is expiring anywhere in the tenant, whatever the policy says, and the consequences run further than a member’s balance: finance is carrying a liability that will never be released (what you owe your members), and any breakage estimate built on zero EXPIRY lines has no evidence in it.

Do it again the first time somebody asks why nothing has expired. It is the same two minutes and it is a different answer from “it is scheduled”.

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. Recognising the release is a manual journal somebody posts in the period the sweep ran — what you owe your members.

When it goes wrong