A typical week

The daily timeline describes what the engine does hour by hour. This page zooms out one level — the week — because that's where most "I don't understand my stock anymore" reports are born: two calendars run in parallel, the physical one (collections, delivery rounds, counts) and the application one (send slots, expected reception dates, automatic seals), and they don't coincide exactly.

The week described here is the real production configuration of a typical merchant (farm-produce grocery, ~100 vendors), but the mechanics — send slot + reception lead + auto-validate grace — are the same for every tenant.

The rule, right away

Count what is physically on the shelf, at the moment you count — the app aligns the rest. Only one thing to avoid: the two short windows where the goods are already on the shelf but not yet "received" on the application side. A count that lands there gets doubled: the app re-adds the goods on top at the next seal.

And the shortcut that makes those windows moot: confirm the reception (or validate the round) at the physical moment, in the UI. The manual gesture dates the arrival at the true instant and short-circuits every assumption — the automatic seal is only a net. The rest of the page explains why these windows exist and where they fall.

The two supplier waves

Every vendor carries send slots (sendSchedules), an ordering lead (deliveryDays, drives slot assignment — 2 by default) and a reception lead (receptionLeadDays, drives the expected arrival date — 1 day for all amisferme vendors). In production, most of the volume falls into two waves:

The expected reception date is mechanical: expectedDeliveryDate = send + (receptionLeadDays ?? deliveryDays) (see Supplier ordering). This date — not the real arrival date — is what auto-validate reads to assume the reception, and what the anchor law reads to decide whether a count already absorbed the goods.

The week, on both calendars

The animation below replays the week with illustrative quantities. Watch the two counters: the real shelf (solid green line) gains the goods at collection time; the stock as the app sees it (dashed purple) only gains them at the automatic seal, a few hours later (1-day reception lead + 12 h grace). The amber band between the two curves materializes the gap, and the red zones are the windows where a physical count would get doubled. Click anywhere on the timeline to test a counting moment: the verdict tells you whether it would be safe or doubled, and by how much.

The residual gap: collected in the morning, "received" at the planned hour

Even with the 1-day reception lead, a small gap remains: goods are physically on the shelf on collection morning (Tuesday ~09:00, Thursday ~09:00), but the application only dates them at the planned hour (Tuesday 12:15, Thursday 22:15) and only seals them after the 12 h grace (Wednesday ~02:01, Friday ~12:01). Two consequences, now bounded to a few hours:

1. Stock shows up a few hours late in the app — unless the reception is confirmed manually, which dates the arrival at the true instant.
2. A count taken inside the risk window gets doubled. The anchor law only absorbs events whose planned date precedes the count. A count taken between the real collection and the planned hour (Tuesday 09:00 → 12:15, or Thursday 09:00 → 22:15) already contains the goods… which the app still thinks are "not received yet" and re-adds on top at the next seal: +N phantom units on top of an otherwise correct count.

When to count stock

The rule above covers supplier receptions. One refinement, on the same-day client orders side: their deliveryDate carries a time of day. An order whose delivery time has already passed is treated as gone (no second decrement — don't count those goods); an order due later in the day will still be decremented at its time (do count those goods if they're still there). Simplest habit: count in the evening after the rounds, or in the morning before departures.

Tuning the week

Three levers, from most effective to most ad-hoc:

1. Set the vendor's "Délai de réception" (vendor form, delivery-settings card — the receptionLeadDays field, shipped 2026-07-16 and backfilled to 1 day for all amisferme vendors). Empty = inherit the ordering lead. ⚠️ Never lower deliveryDays instead: that field also decides which email covers which client order (send window = client delivery − lead − 1 day spare). With the two weekly slots, the value 2 is precisely what puts Wednesday/Thursday deliveries on the Monday email and Friday/Saturday ones on the Wednesday email — lowering it to 1 would send Thursday orders to the wrong email and leave Saturday orders with no slot at all (rule pinned by reception-lead-days.test.ts).
2. Confirm the reception at collection time. The UI gesture at the physical moment is the primary path — it dates the reception at the true instant, and auto-validate then has nothing to assume. The automatic seal is only a safety net, not the nominal mode.
3. Cancel a wrongly assumed reception. On the Stock page (/manage/ecommerce/inventory/stock-ledger), the "Assumed receptions" panel lists everything the safety net sealed, with a "Cancel reception" button (removes the stock, restores the projections, reopens the order — and the order will not be re-sealed by the next sweep). See Back-office surfaces.

The global grace (AUTO_VALIDATE_GRACE_HOURS, 12 h) is deliberately not on this list: shortening it brings seals closer to planned dates but reopens the risk of sealing deliveries that haven't happened yet — the per-vendor lead time is the thing to tune, not the grace. See Flags & configuration.

What about client orders?

Symmetrically to receptions, client deliveries are assumed done at deliveryDate + 12 h: an unconfirmed Friday 11:00 round is sealed during the night from Friday to Saturday (~00:01 sweep), with the corresponding stock decrement. Here too the UI seal ("Validate today's round") on returning from the round is the primary gesture; the safety net only catches what was forgotten, roughly 12 to 14 hours after the planned time.

In short

• Two calendars: the physical one (collections Tuesday/Thursday, rounds Wednesday→Saturday) and the planned one (send + lead, seal + grace). They diverge exactly as much as the expected reception date strays from the real arrival.
• A count is safe after the last wave's expected reception hour, or before its collection — never in between. Today, the windows to avoid are ~3 h (Tuesday) and ~13 h (Thursday).
• The manual gesture (confirm reception / validate the round) at the physical moment short-circuits every assumption: it is always the best option.