Scheduling promotions in LS Central: periodic and discount offers with dates

Pricing · 7 min read

A promotion in LS Central is not "live" because someone typed the dates in. It is live when the right offer type carries a validation period, is scoped to the right stores, and has been switched to Enabled — in that order. This guide walks the whole schedule, because every "the offer didn't fire" story is one of those steps skipped.

The offer types you can put on a schedule

LS uses Periodic Discounts as a synonym for three offer types: Discount Offer, Multibuy Discount, and Mix & Match. LS gives these periodic offers higher priority in discount calculations than later offer types, which is worth knowing when promotions overlap. Pick the vehicle by the shape of the deal:

One behavioural note that changes how signage should read: an Offer in LS Central works as a price change, resulting in a changed price at the POS rather than showing a discount from the former price. A discount percentage is assigned to the discount offer as a whole, together with when to enable and disable it. If your reporting or shelf talkers promise a visible "discount" line, check what the customer actually sees before the promotion launches.

There is also a date mechanic most teams never use. Discount Offer lines carry Valid From Before Expiration Date and Valid To Before Expiration Date fields. They are DateFormula fields: if filled in, the line's discount is only active during the period before the expiration date of the item being sold. LS's own example enters -5D to 0D to give 15% off a fresh chicken in the last five days before its expiration date, read from the GS1 DataBar barcode. For perishables, this schedules the markdown against the product's life instead of the calendar.

The schedule is two things: validation period plus status

New administrators usually find the dates and stop there. LS separates the calendar from the switch, and both halves matter:

• The validation period is the calendar. A validation period can be set on all offer types, and the starting and ending dates are displayed in the Validation Period FactBox. If no validation period is selected, the offer is not restricted by a time period — it runs whenever it is enabled, indefinitely.
• The status is the switch. An offer's status is either Disabled or Enabled. Offer information and settings can only be changed when the offer is Disabled, and only Enabled offers are triggered on the POS. After setup, the status must be changed from Disabled to Enabled for the offer to be sent to the POS terminals.

So "scheduled" means: built while Disabled, carrying the validation period that bounds it, scoped to its stores, then Enabled before the window opens. An offer with perfect dates that is still Disabled does nothing. An Enabled offer with no validation period does everything, forever, until someone remembers it.

Schedule a promotion: the procedure

1. Pick the type and create the offer from the matching page — Discount Offers, Multibuy Discounts, or Mix & Match — selecting a line and choosing Edit. Leave the status Disabled while you build; you cannot change settings on an Enabled offer anyway.
2. Add the lines. In the Lines FastTab, each line's Type can be Item (a single item), Product Group, Item Category, All, or a Special Group, with the value chosen in the No. column. Use the Exclude check box to carve exceptions out of a broad line — LS's example discounts an item except the black skirts — rather than rebuilding the offer item by item.
3. Set the benefit. On the Benefits FastTab (Discount Offers), enter the discount percentage or amount that applies to all lines; it becomes the default for new items, and each line can still be edited separately. Remember the guardrail: a discount amount can never be higher than the total amount of the items sold, and the POS checks that the price never goes negative.
4. Set the triggers. In the Triggers FastTab, leave every field empty if the offer is for all customers — LS is explicit that empty triggers mean exactly that. Fill them in only to limit the offer, for example to members of a club or scheme, or to a customer presenting a coupon. A Periodic Discount Offer can also be triggered by amount via the Amount to Trigger field: if the total sale is over the specified amount and the other requirements are fulfilled, the offer triggers.
5. Check interactions. On the Settings FastTab you can block other offer types from being triggered alongside this one — LS's example blocks Total Discount and Tender Type Discount in addition. Only offers examined later in the price calculations can be blocked, so decide deliberately which promotions are allowed to stack.
6. Attach the schedule. Set the validation period with the promotion's start and end dates, and confirm both dates show in the Validation Period FactBox. No dates here means no expiry — that is a decision, not a default to drift into.
7. Scope the stores. In the Store Groups FastTab, enter the distribution store groups where the offer is valid. Offer information is only replicated to these stores — a store missing here will never see the promotion, whatever the dates say.
8. Enable it. Change the status from Disabled to Enabled. This is the step that sends the offer to the POS terminals.
9. Test before the window opens. Run a test transaction at a terminal in an in-scope store with a qualifying item and confirm the offer fires at the offered price; then test an excluded item or an out-of-scope condition and confirm it does not. (If the terminal was recently offline, confirm its data is current first — see our POS offline mode checklist.)

Validation period or manual enable? Decision notes

• Fixed calendar window (a weekend sale, a seasonal markdown): set the validation period and enable in advance. The dates bound the offer even if nobody is watching on the closing night.
• Open-ended until further notice: leave the validation period empty on purpose, enable it, and put a diary date on reviewing it — an unrestricted offer is a standing discount, and should be owned like one.
• Perishables: prefer the expiration-date line fields over calendar dates, so each unit's markdown window follows its own expiry.
• One store group only: the schedule is the same, but the Store Groups FastTab is where the promotion is really defined — verify replication to a terminal in that group before advertising it.

Pre-launch checklist: the three silent failures

1. Still Disabled. The offer was built, dated, and reviewed — and never enabled. Only Enabled offers trigger on the POS, and only enabled offers are sent to the terminals. Check the status field, not the meeting notes.
2. No validation period. The promotion fires correctly on day one and is still firing in month three, because nothing told it to stop. Confirm the start and end dates in the Validation Period FactBox.
3. Store groups missing or wrong. The offer exists at head office and nowhere else, because offer information is replicated only to the stores in the Store Groups FastTab. Confirm every participating store's group is listed.

Two honourable mentions: a trigger filled in "just to document it" quietly limits the offer to that audience — empty means everyone — and a blocked offer type on the Settings FastTab can suppress a second promotion you expected to stack.

Changing or ending a promotion early

To modify or delete a discount offer, change its status back to Disabled first — settings cannot be changed while it is Enabled. But heed LS's warning before you edit in place: statistics on a discount offer cannot be updated if the discount offer is modified, so LS advises disabling the offer you want to modify and creating a new one instead. That preserves a clean record of what each promotion actually did. The Statistics FactBox on the offer shows the total sales and profit the offer triggered — the numbers you lose by overwriting history. Only Disabled offers can be archived, which is the tidy end-state for a finished promotion. Any change updates the offer's Last Date Modified field, including changes to lines, triggers, settings, additional benefits, and store groups, so that field is your audit trail for "who touched this offer last."

What success looks like

• The offer status is Enabled before the window opens, with start and end dates visible in the Validation Period FactBox.
• A test transaction in an in-scope store fires the offer at the expected price; an excluded item and an out-of-scope store do not.
• After the end date, the same test transaction no longer fires the offer — the schedule, not someone's memory, ended it.
• The Statistics FactBox shows sales and profit attributed to the offer, and the offer is disabled and archived rather than edited into next month's promotion.

FAQ

The offer is set up but nothing happens at the till. What do I check? In order: status (Enabled?), validation period (does today fall inside it?), store groups (is this store in one?), triggers (did a field limit the audience?), and lines (is the item actually covered, or excluded?). That sequence catches the documented failure modes.

Can two promotions run on the same item? Periodic offers carry higher priority in discount calculations, and the Settings FastTab can block other offer types from triggering alongside an offer. Whether stacking happens is therefore a configuration choice — make it explicitly.

Do I need dates for a permanent offer? No — with no validation period the offer is not restricted by time. Treat that as a standing discount with an owner and a review date, not as a promotion.

General information only, based on LS Retail documentation checked 2026-10-17. Offer screens vary slightly between offer types and versions — confirm against your own environment before launching a live promotion. Standing discount and price work sits alongside Business Central price lists; keep the two mechanisms separate.