Price-change traps: rounding, distribution timing, and stale prices at the POS

Pricing · 7 min read

"The price is wrong at the till" has three completely different causes in LS Central, and each one sends you to a different fix. The price can be right but rounded differently than you expected. The change can be correct at head office but never have left the building. Or the terminal can be faithfully selling from yesterday's replicated data. Chasing the wrong layer wastes hours — this guide separates the three, in the order to check them.

Trap 1: rounding — the price is right, the math is not what you expected

LS Central inherits its rounding behaviour from Business Central's General Ledger Setup, where four different settings do four different jobs:

Foreign-currency equivalents of these settings live on the Currencies page, which is why a rounding complaint that only affects one currency is a currency-card problem, not a G/L Setup problem. Two compounding behaviours matter at the till. First, rounding happens line by line: as one Dynamics Community answer on journal differences puts it, Business Central converts and rounds each line individually based on the G/L and currency rounding precision, so documents with many lines can accumulate small cumulative differences — the thread cites 0.01–0.04 — without anything being "broken." Second, LS Central adds its own layer at payment time: transaction balance rounding is the combination of sales rounding and payment rounding, arising when tender rounding is used and there is a difference between the sale amount and the payment amount. A transaction can still post as long as that difference stays within the limit set by the Allowed Diff. in Trans field on the Store card, which represents the sum of all tender rounding allowed for one transaction. Small, bounded rounding differences at statement time are this machinery working as designed — differences above the allowed limit, or on individual unit prices, are not.

The trap is changing the wrong setting: adjusting Amount Rounding Precision will not fix a unit price that is off by a cent, because unit prices answer to Unit-Amount Rounding Precision. Match the symptom to the layer before touching setup — rounding settings are company-wide and every change affects every store.

Trap 2: distribution timing — the change never left head office

The classic case is the discount offer that "doesn't work." In LS Central, an offer is not a till-side discount calculation: the Offer works as a price change, resulting in a changed price at the POS rather than a discount shown from the former price. And an offer only leaves head office when someone activates it — once a discount offer is set up, its status must be changed from Disabled to Enabled in order for it to be sent to the POS terminals. An offer still sitting at Disabled is not broken; it was never sent. The reverse also applies: to modify or delete a discount offer, the status goes back to Disabled first. And because statistics on a discount offer cannot be updated if the offer is modified, LS Central's own advice is to disable an offer you want to change and create a new one instead — editing a live offer mid-flight is how you get a price at the till that matches neither the old nor the new intention.

Even an Enabled offer — or a plain price change — still has to travel. Prices reach the POS through scheduled jobs, not by magic: data-preparation jobs have to run on a regular basis in the LS Central Scheduler to keep replicated data up to date, and the pattern is visible in the Commerce jobs, where COMMERCE_UPDATE is meant to run on a regular schedule during the day to pick up data changed since the previous update, while COMMERCE_INIT prepares startup data (first run, and when a new store is added). The same cadence logic governs POS data: a price changed at 10:00 is only at the till after the next successful job cycle. "We changed it an hour ago" and "the job runs every two hours" is a complete explanation, not a mystery.

Trap 3: stale prices — the terminal is working from old data

The POS is deliberately built to sell from replicated data rather than live head-office lookups: since LS Central 17.0, the POS-ALL-INIT and POS-ALL-UPDATE scheduler jobs replicate data to the POS so the POS can run offline. That resilience is the trap. When a replication job fails, is paused, or hasn't run since the change, every terminal keeps selling at the last prices it received — correctly, from its own point of view. A price that is right at head office, right in one store, and wrong in another almost always means one destination missed a cycle, not that the price setup differs. Our offline mode guide covers the extreme version: a terminal that loses its connection entirely keeps working from its last-known master data, prices included.

While you triage, give staff a safe way to check and a controlled way to cope. The POS command PRICECHK checks an item's price without creating sales entries — the right tool for "is this shelf label right?" — and PRICECH changes the price on a sales line, which is a per-transaction patch, not a fix for the underlying distribution problem. If cashiers are PRICECH-ing the same item all day, the item's price never arrived; go fix the job, not the tenth transaction. The data paths behind all of this are covered in how customer and member data moves — prices travel the same corridor.

Triage: which trap are you in?

1. Is the head-office price itself a cent (or a rounding interval) away from intent? Rounding trap. Check Unit-Amount Rounding Precision for unit prices, Amount Rounding Precision for amounts, and the Currencies page if only one currency is affected.
2. Is it an offer price that's missing? Open the offer. If the status is Disabled, it was never sent to the POS — enable it, and stop editing live offers; disable and recreate instead.
3. Head office right, one store wrong, another store right? Stale data. Check the replication/distribution jobs for the wrong store's destination: last successful run versus when the price changed.
4. Every store wrong by the same amount? Back to step 1 — a shared cause (rounding setup or a centrally edited price) beats a fleet-wide coincidence.
5. Differences only appear at payment/statement time, and they're small? Probably transaction balance rounding working within the Store card's Allowed Diff. in Trans limit. Verify the size against the limit before treating it as an error.

What success looks like

• A test price change made at head office appears at every store's POS after one job cycle — verified with PRICECHK, not by making a sale.
• Offers in the list are either Enabled (live, untouched) or Disabled (draft or retired) — none are being edited while live.
• Rounding differences at the statement are within the Allowed Diff. in Trans limit and explainable layer by layer; anything bigger has a named cause.

FAQ

We changed the price this morning. When should the till show it? After the next successful distribution/replication cycle for that store — the change is not live at the POS until the scheduled jobs carry it there.

Can a price be right at head office but wrong at one terminal? Yes — the POS sells from replicated data, so a terminal that missed a cycle keeps the old price while everything else moves on.

Should cashiers just override wrong prices? A line price change (PRICECH) is a reasonable patch for one customer; repeated overrides on the same item are a symptom. Treat them as a distribution alarm, not a workflow.

Note: rounding and tax-adjacent setup affects financial postings. This article is operational guidance, not accounting advice — confirm G/L rounding changes with whoever owns your chart of accounts before applying them company-wide.