A typical week

The daily timeline describes what the engine does hour by hour. This page moves up to the week, where most hard-to-explain stock gaps appear. Two calendars run in parallel: the physical one (collections, delivery rounds, counts) and the application one (send slots, expected reception dates, automatic seals). They do not line up exactly.

Tip

The application dates a reception at the planned time (send + reception lead time), not at the real time the goods arrive. The gap, the risk windows, the right time to count and the settings to adjust all follow from that difference.

Example: a merchant who sends supplier orders in two waves per week, collects the goods the morning after each send, and delivers customers from Wednesday to Saturday. Times are in local time. Your slots will differ, but the mechanics (send slot + reception lead time + automatic-validation grace) are the same for every merchant.

The rule, right away

Count what is physically on the shelf at the moment you count; the application aligns the rest. Only one thing to avoid: the windows where the goods are already on the shelf but not yet "received" on the application side. A count that lands in one of them gets doubled: the application adds the goods again at the next seal.

Window (example) Status Why
Tuesday, from collection to 14:00 (~5 h) ⚠️ at risk Wave 1 on the shelf but "not received yet" for the application
Thursday, from collection to 18:00 (~9 h) ⚠️ at risk Wave 2 on the shelf but "not received yet" for the application
The rest of the week ✅ safe Including Friday afternoon

To make those windows irrelevant: confirm the reception (or validate the round) when it happens, in the back office. The manual gesture dates the arrival at the real time and replaces every assumption; the automatic seal is only a safety net. The rest of the page explains why these windows exist and where they fall.

The two supplier waves

Each vendor has send slots, a delivery lead time (which decides the slot a customer order is attached to) and a reception lead time (which decides the expected arrival date). In the example, the delivery lead time is 2 days and the reception lead time 1 day, and most of the volume falls into two waves:

Wave Send slot Expected reception (1-day reception lead) Auto-seal if unconfirmed
Wave 1 Monday 14:00 Tuesday 14:00 Wednesday ~03:01
Wave 2 Wednesday 18:00 Thursday 18:00 Friday ~07:01

The expected reception date is simple: send date + reception lead time (or the delivery lead time when the reception lead time is empty). See Supplier orders. This date, not the real arrival date, is what automatic validation uses to assume the reception, and what the anchor law uses to decide whether a count already includes the goods.

The week, on both calendars

Day Merchant side (physical) Application side (planned dates)
Monday Preparation; wave 1 goes out at 14:00 Wave 1 emails out, drafts frozen
Tuesday Wave 1 collection (morning), the shelf is restocked 14:00: wave 1 expected reception (send + 1 day)
Wednesday Customer rounds; wave 2 goes out at 18:00 ~03:01: wave 1 reception assumed (12 h grace elapsed); wave 2 emails out
Thursday Wave 2 collection (morning); customer rounds 18:00: wave 2 expected reception
Friday Customer rounds ~07:01: wave 2 reception assumed
Saturday Customer rounds Each round is sealed the same evening (~23:01) if nobody confirmed it
Sunday No activity Background tasks only (syncs, recalculations)

The animation below replays the week with illustrative quantities. Watch the two counters: the real shelf (solid green line) gets the goods at collection time; the stock as the application sees it (dashed purple) only gets them at the automatic seal, a few hours later (1-day reception lead time + 12 h grace). The amber band between the two curves shows the gap, and the red zones are the windows where a physical count would be 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.

Note

All times on this page are local time. Seal times (~03:01, ~07:01) match the 2-hourly automatic-validation passes described on the daily timeline; send slots (14:00, 18:00) are the ones you set on the vendor record.

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

Even with a 1-day reception lead time, a small gap remains. The goods are physically on the shelf on collection morning (Tuesday and Thursday around 09:00), but the application only dates them at the planned time (Tuesday 14:00, Thursday 18:00) and only seals them after the 12 h grace (Wednesday ~03:01, Friday ~07:01). Two consequences, limited to a few hours:

  1. Stock shows up a few hours late in the application, unless the reception is confirmed manually, which dates it at the real time.
  2. A count taken inside the risk window gets doubled. The anchor law only includes events whose planned date precedes the count. A count taken between the real collection and the planned time (Tuesday 09:00 → 14:00, Thursday 09:00 → 18:00) already contains the goods, which the application still thinks are "not received yet" and adds again at the next seal: +N extra units on top of an otherwise correct count.

The closer the reception lead time is to reality, the shorter these windows. With an empty reception lead time, the expected date would fall back to the delivery lead time (2 days in the example) and the windows would last more than a day.

When to count stock

The rule above covers supplier receptions. One refinement for same-day customer orders: their delivery date carries a time of day. An order whose delivery time has passed is treated as gone (it will not be decremented a second time: do not count those goods). An order due later in the day will be decremented at its time (do count those goods if they are 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 occasional:

  1. Set the vendor's "Reception lead time" (vendor record, Delivery settings card). Empty means it inherits the delivery lead time. ⚠️ Do not lower the delivery lead time instead: that field also decides which email covers which customer order (a customer delivery goes to the latest send slot no later than the delivery date minus the delivery lead time). In the example, the value 2 is what attaches Wednesday and Thursday deliveries to the Monday email, and Friday and Saturday ones to the Wednesday email. Lowering it to 1 would move Thursday deliveries to the Wednesday email, whose goods only arrive on Thursday, leaving no day to prepare them.
  2. Confirm the reception at collection time. The gesture at arrival is the normal path: it dates the reception at the real time, and automatic validation has nothing to assume. The automatic seal is only a safety net.
  3. Cancel a wrongly assumed reception. On the Stock ledger page, the "Assumed receptions" panel ("Réceptions supposées") lists everything the safety net sealed, with a "Cancel" button ("Annuler") on each row: the stock is removed, projections are restored, the order goes back to pending and will not be sealed again by the next pass. When the history no longer allows a safe reversal, the button reads "Blocked" ("Bloquée") and shows the reason on hover; without write access to vendors, the row is read-only. See Back-office screens.

The 12 h grace period is deliberately not on this list: shortening it would bring seals closer to planned dates, at the risk of sealing deliveries that have not happened yet. The per-vendor reception lead time is the setting to tune. See Configuration.

Customer deliveries

Like receptions, customer deliveries are assumed done 12 h after their planned date: an unconfirmed Friday 11:00 round becomes eligible at 23:00 and is sealed by the ~23:01 pass the same evening, with the matching stock decrement. Here too, "Validate today's round" on returning from the round is the normal gesture; the safety net only catches what was forgotten, 12 to 14 hours after the planned time.