Two defects that share a shape: a figure landing on the wrong record.
Bill-level discounts were apportioned across every line by a single
factor, so "20% off Beverages" pulled tax out of the atta line as well.
The bill total was right either way, which is what made it easy to ship
— only the slab split on a filed return was wrong. Targeted campaigns
now reduce the lines they name, and bill-wide reductions still spread
pro rata, so the arithmetic is unchanged wherever it was already right.
Shoppers registered at a till only ever reached the back office as three
fields riding along on a bill. Somebody who signed up and bought nothing
existed on one terminal and nowhere else, and two tills registering the
same mobile each minted their own row. Customers are now an outbox of
their own on pos/{store}/{terminal}/customer, and the id is a UUIDv5
over the normalised mobile number — so a hundred terminals agree on who
a shopper is without talking to each other.
Registrations go up before bills, and a failure there cannot strand a
day's takings. No loyalty figures are sent: they belong to the bill
stream, which is idempotent and knows about every counter.
Two things found while building it. Numbers were keyed on raw digits, so
a cashier typing +91 forked a shopper as effectively as a random id
would. And the sale path wrote the customer with ConflictAlgorithm
.replace, which is a DELETE and an INSERT — every column absent from the
row reverts to its schema default, so the new sync flag would have been
cleared by the shopper's next purchase.
Schema v8. Existing customers are queued rather than assumed sent: the
terminal cannot tell an imported row from a locally registered one, and
only one of those mistakes loses somebody.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The Promo module was a mockup. Three hardcoded rows, a toggle that changed
nothing, and no promo code anywhere in lib/domain or lib/data. A cashier
looking at it would reasonably conclude promotions were running.
Engine (domain/services/promo_engine.dart)
- Five campaign types: percent or flat off the bill, percent off a category
or a product, and buy-X-get-Y.
- Conditions: date range (inclusive of the closing day), days of the week,
minimum bill value, and a cap on what a percentage can take off — without
one an unusually large trolley gives away more than the campaign was costed
for.
- Stacking is conservative by default. All stackable campaigns apply together;
of the exclusive ones only the single best does, chosen by what it is worth
to the shopper with priority breaking ties. Two percentages compounding
produce a discount nobody signed off, and the shop finds out at the end of
the month.
- The total is capped at the subtotal, so no combination of campaign, tier and
manual discount can turn a sale into a payout.
- buy-X-get-Y counts whole groups only, and prices the free unit at what is
actually being charged — a line already carrying a manual discount must not
refund more than it took.
Kept out of Cart deliberately: Cart owns arithmetic that must never be wrong,
this owns policy a shop changes weekly.
Storage (schema v6, plus promos_json on orders at v7)
- Campaigns persist locally, because a shop mid-promotion with a dead line
still has to honour the price on the shelf edge.
- A bill records the campaign name and the amount given, not a link to the
row. A campaign edited or deleted later cannot change what a past sale
shows, and a reprinted receipt still names what the shopper was given.
- On read-back the promo amounts are subtracted from the manual discount,
because bill_discount already contains them. Restoring both at full value
would discount the bill twice — the same shape as the bug that used to
overstate synced totals.
At the till
- Every cart mutation re-evaluates, so a promo cannot survive the line that
earned it being removed.
- A resumed parked bill is re-evaluated rather than restored: a campaign that
has since ended must not be honoured because the bill was parked while it
was running.
- Campaigns are named individually on the billing panel and the printed
receipt, so a shopper who came in for an advertised offer can see it applied.
Editor
- Full CRUD, admin-only, with validation for the cases that would save happily
and then silently never fire — a targeted campaign with no target, a
percentage over 100, an end date before the start.
Tests: 199 -> 210. Covers each campaign type, the eligibility conditions, the
stacking rules, the impossible-to-go-negative guarantee, GST recomputation
against the reduced total, round-tripping, and the double-count guard.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Turns the orders table into a queue that empties itself. Bills were only
uploaded when a cashier pressed Sync at end of day; a till that was never
pressed held a day's takings indefinitely.
Drain engine (lib/data/sync/sync_engine.dart)
- Triggers on sale committed, network regained, 5-minute poll, head-office
request, and the manual button.
- Single flight: a busy till firing a trigger per sale would otherwise have
several passes reading the same pending rows and send every bill twice.
A trigger arriving mid-drain is queued and replayed, so nothing is dropped.
- Exponential backoff with +/-20% jitter to a 5-minute ceiling. The jitter
matters: a store's terminals all fail at the same instant when the line
drops, and would retry in lockstep without it.
- Halts rather than loops on a failure retrying cannot fix (bad credential,
refused batch). Pressing Sync clears the halt.
Transports (lib/data/remote/)
- OrderTransport interface; MQTT, HTTP and simulated implementations. The
repository does not know which is in use.
- MQTT: QoS 1 uplink, application-level ACK correlated by batch_id on a return
topic, retained Last Will for terminal-offline detection, downlink for
catalogue pushes and remote sync requests.
- A broker PUBACK is never treated as acceptance. It means the broker holds
the bytes, not that the ledger took the sale. Only ids the back office names
are marked synced; silence leaves a bill pending.
- HTTP carries a stable idempotency key across retries of the same bills.
Retention
- Accepted bills are kept 7 days instead of deleted, so a batch the back
office later loses can be re-sent in full. Purged after that; archived
totals stay forever.
- forBusinessDate now reads pending rows only. A retained bill exists in both
the orders table and day_archive, and summing both would overstate the day.
Fixes found while building this
- SyncEngine._refreshPending wrote state.copyWith(pending: await ...). Dart
evaluates the receiver before the awaited argument, so a connectivity drop
during the wait was silently overwritten by the stale snapshot. Caught by
the first run of the new engine tests.
- PrinterSettingsController wrote state after four awaits with no mounted
check, throwing "used after dispose" when Settings was left mid-load. This
was pre-existing and reached the cashier as a red screen.
Also
- Header pill now reports real sync state: LIVE / n QUEUED / SYNCING /
SYNC HALTED, with an explanation of where the bills are.
- Settings shows the route, last upload, next retry and retention window.
- docs/sync-contract.md states what the back office must implement, including
the idempotency requirement that at-least-once delivery makes mandatory.
Tests: 90 -> 129 passing. New coverage for backoff shape and jitter band,
single flight, halting, ACK correlation and partial acceptance, at-least-once
duplicate handling, retention and purge, and no double-counting after a sync.
Suite run six times clean.
Not addressed: bills already synced by an older build went up overstated and
still need server-side reconciliation. Broker credentials have no Settings
editor yet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Bills were persisted correctly but read back wrong. The read path rebuilt a
cart from its lines alone, dropping bill-level discounts and loyalty, so every
figure derived from a stored bill was overstated: the upload payload, the day
archive and the shift report. A discounted 529 bill read back as 620.
Money and data integrity
- order_dao: restore bill_discount and points_redeemed when rebuilding a cart;
keep the reconstruction tier-less so the membership discount is not applied
twice. Trust the recorded total and points via SaleTransaction.storedTotal.
- checkout_sale + order_dao.commitSale: write the bill, its stock movement and
the loyalty update in one transaction. Previously a failure part-way through
left a persisted bill the cashier believed had failed, inviting a duplicate.
- checkout_sale: re-check every line against live stock. A parked bill resumed
after its stock was sold passed validation and oversold.
- catalogue_dao: allocate the invoice sequence in one transaction; the previous
read-modify-write could hand two sales the same number and fail UNIQUE.
- local_store: replay unsynced sales after a catalogue import, so a mid-shift
re-import cannot restore stock that has already been sold.
- payment_controller: stamp the signed-in operator on the bill instead of the
hardcoded seed session, and pass the terminal id through.
- cart: reconcile per-slab GST against the bill total so the parts sum to the
whole on a tax invoice.
Sync and reporting
- sync_repository: drain unsynced bills in a loop rather than silently capping
at one page; stop on rejection so rejected rows cannot loop forever.
- sync_log_dao (new): persist the sync history to the sync_log table, which the
schema already defined but nothing used. It was in memory, so the only record
that bills had been uploaded died at restart.
- Scope shift reports by cashier. day_archive is re-keyed to
(business_date, cashier_name) so a till stays settleable after its bills are
uploaded and deleted. Schema v4 with a migration that carries v3 rows across.
Input and UI
- barcode_service: consume machine-paced keystrokes so a scan cannot also land
in the focused field, and raise the bar to 60ms/char while a text field has
focus so typing a mobile number is not read as a scan. Clock and focus check
injected so the behaviour is testable.
- primary_button: make the label flexible; label plus trailing total overflowed
the Charge button by up to 131px.
- app_router: redirect instead of null-casting when the receipt route is
entered without its transaction.
- customer_repository: reduce the search query to digits so a punctuated mobile
number matches.
Cleanup
- Remove TransactionRepository.save, CustomerRepository.recordSale and
OrderDao.insertOrder, all superseded by commitSale.
- dart fix across the tree; 251 analyzer issues down to 3 info-level.
Tests: 23 passing / 15 failing -> 90 passing. Fixed the two defects that broke
the existing suite (containsAll type argument, reset() needing a catalogue) and
deleted the leftover template test. Added coverage for the order round trip,
the day archive after a real sync, stock safety, checkout atomicity, the v3->v4
migration, scanner-versus-human input, and an app-level smoke test that renders
every module.
Note: bills already uploaded with a discount went up overstated. This stops it
happening again but does not correct historical server data.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
