Supplier ordering pipeline

Inklura generates your supplier orders from real customer demand, in a just-in-time model: each send to a supplier covers a window of customer delivery dates, and physical stock can legitimately sit at zero between two receptions. Drafts update when demand changes, and a supplier email only leaves after your review, or after the pre-send check for a supplier on automatic sending.

Pipeline overview

flowchart LR
  subgraph EV["Events"]
    CO["Customer order<br/>created, updated, cancelled,<br/>status change"]
    PS["PrestaShop update"]
    RC["Supplier-order reception<br/>or cancellation"]
    MA["Manual stock adjustment"]
  end
  CO --> W["Supplier-ordering<br/>engine"]
  PS --> W
  RC --> W
  MA --> W
  P30["Check pass<br/>every 30 min"] --> W
  REC["Reconciliation<br/>every morning"] --> W
  W --> SO["Draft orders<br/>+ expected inflows"]
  SO -->|"preparation<br/>every morning"| REV["Email<br/>review queue"]
  REV -->|"send"| SENT["Sent"]
  SENT --> LIV["Reception<br/>and stock update"]

Three sources feed the same calculation:

Source	Cadence	Role
Event-driven recalculation	a few seconds after the event, if enabled for your workspace	updates the affected suppliers' drafts when an order or a stock level changes
Check pass	every 30 minutes	adds new demand and recalculates existing drafts, including removing lines whose demand has gone
Daily reconciliation	every morning	full recalculation: fixes any remaining drift and cancels drafts left orphaned

Only one calculation runs at a time for a given site. If you start a recalculation from the back office while another one is running, it is refused with a "try again in a minute" message ("Réessayez dans une minute").

What triggers a recalculation

Event-driven recalculation is enabled workspace by workspace. When it is, the engine recalculates the affected suppliers' drafts on every event that changes demand or supply:

Customer order: create, update, cancel, status change, delete;
Supplier order: cancellation, reception;
PrestaShop store: orders created or updated in real time (see PrestaShop sync);
Manual stock adjustment from the back office.

A burst of changes on the same products is merged into a single recalculation, which only touches the suppliers of the products involved. Without event-driven recalculation, these changes are picked up by the next 30-minute pass.

Send slots

Each supplier record carries:

recurring send slots (a day and a time, for example Tuesday 10:00);
a delivery lead time in days, which decides which slot each customer order lands on (for a supplier attached to a grouped order, the slots and lead time of the supplier placing the grouped order are used);
an optional reception lead time, used only to estimate when the goods will arrive.

A customer order is assigned to the slot that still allows on-time delivery. The engine looks for a slot inside this window:

earliest send = delivery date − (delivery lead time + 1 spare day)   // start of day
latest send   = delivery date − delivery lead time                    // end of day

If no slot falls inside that window, the engine takes an earlier slot that still allows delivery by the requested date (the goods arrive early, but on time).

A customer order without a delivery date is placed using its invoice date.

Example: a supplier with two slots

Example: a merchant whose supplier has two send slots (Tuesday 10:00 and Thursday 18:00) and a delivery lead time of 2 days. A customer orders for delivery on Friday:

delivery date = Friday
earliest send = Friday − (2 + 1) = Tuesday     // start of day
latest send   = Friday − 2       = Wednesday   // end of day

The only slot inside the [Tuesday, Wednesday] window is Tuesday 10:00: the demand lands there. A Thursday delivery also falls on Tuesday; Saturday and Sunday deliveries move to the Thursday 18:00 slot.

Warning

The delivery lead time decides which send each customer order lands on. If receptions arrive earlier or later than expected, adjust the supplier's reception lead time rather than the delivery lead time: changing the latter would move customer orders to a different send, or leave some without a slot. See The weekly cycle.

Slots that have already passed

The engine never creates a draft on a slot that has already passed, and a supplier send can never be dated before the customer order that created the demand.

When a customer order arrives too late for any remaining slot to deliver on time, the demand is excluded: it is not added to any upcoming supplier email, because goods arriving after the customer delivery would be no help. You handle the case directly (existing stock, a one-off purchase, moving the delivery). The pre-send check of the next order flags it as "before reception" (see Safety nets). With several slots per week, this stays rare.

Note

A customer order already covered by a send that went out is never put back into the next send, even when its delivery date is close or past. This prevents ordering the same goods twice.

Quantity computation

For each product and each slot, the engine computes:

need       = customer demand for the slot (+ base replenishment, if any)
with overage = need + round up (need × overage %)
suggested  = max(0, with overage − retained stock)
packages   = round up (suggested / package size)
units      = packages × package size        // units actually ordered

Retained stock is the stock the engine agrees to subtract. It is 0 for a product without stock tracking, and for a made-to-order supplier (unless the product's stock was validated). Negative stock counts as 0. The engine also subtracts customer deliveries already due but not yet validated, and adds goods already on their way that no customer order claims. The Stock gaps page shows, under "Retained" ("Retenu"), the starting stock of this calculation.
Drawn down in order: when a product's demand spans several slots, stock is consumed slot by slot. The first slot absorbs the stock, later slots order the remainder.
Round up to the package: no quantity is lost to rounding. A line is created even at quantity 0: it records which customer orders are covered. A line at 0 is left out of the email sent to the supplier, and an order whose lines are all at 0 is not sent: demand is already covered, it is not an error.

The package size comes from the product's packaging (packaging type or quantity per package), and defaults to 1.

Which products are included

A product enters the calculation if it has a default supplier and at least one of the following: stock tracking turned on, a base replenishment, generic-product status, or customer demand inside the calculation window. A product without stock tracking but with customer orders is therefore ordered from the next pass. A deactivated product stays included while it has demand to deliver. Only demand whose delivery date is still ahead counts.

The reconciliation compares the expected state of your supplier orders with the recorded state and applies the smallest set of corrections. A draft order that no longer matches any demand is cancelled (not deleted), with a cancellation reason recorded.

One product, one supplier, one send

Each product is ordered from a single supplier: its default supplier. The engine creates or updates exactly one supplier order per (supplier, send slot) pair. A recalculation always lands on the existing order instead of creating a second one.

When a product's demand spans several slots, it produces one line per slot, on each slot's order. Every line shows which customer orders it covers.

Generic products

A generic product is a purchasing product that groups several shop references (its "children") under a single supplier line. Typical case: several formats sold to the customer, ordered from the supplier in a common unit (the kilogram, say).

Each child is linked to the generic with a conversion factor:

generic quantity = child quantity × conversion factor

Only the generic appears for the supplier. Linked children never produce a supplier line of their own, so the same need never appears twice in the email.
Demand adds up: each child's demand is converted and added to the generic's. The total is rounded up to the unit, then to the package, like any product. A fraction of a unit therefore orders a whole package:

Example: 2 orders of a child × 1 × 0.05 = 0.10  →  rounded up 1  →  1 package

Stock is read from the children. A generic has no stock of its own: the engine subtracts each child's retained stock, converted with the same factor. A tracked child's stock counts even when the generic's supplier is made-to-order.

Overage

Overage is added to the need before stock is subtracted (see the computation above). A new supplier has a "Default overage" ("Majoration par défaut") of 5%; set it to 0% to order exactly.

A product's own percentage ("Majoration spécifique (%)" on the product record, or the "Majoration (%)" column in a supplier's product list) takes precedence over the supplier's, even when it is 0%. See Settings.

Supplier-order lifecycle

stateDiagram-v2
    [*] --> Draft : automatic or manual generation
    Draft --> Draft : recalculation, email preparation
    Draft --> Sent : send after review
    Draft --> Cancelled : cancellation
    Sent --> Draft : back to draft
    Sent --> Confirmed : complete reception
    Sent --> Cancelled : cancellation
    state "Delivery" as LIV {
        [*] --> Pending
        Pending --> Partial : partial reception
        Partial --> Complete : reception completed
        Pending --> Complete : full reception
        Pending --> Issue : problem reported
    }
    Sent --> LIV : reception
    Confirmed --> LIV : reception

The order status (DRAFT, SENT, CONFIRMED, CANCELLED) and its delivery state (PENDING, PARTIAL, COMPLETE, ISSUE) are tracked separately. An order becomes CONFIRMED when its reception is complete; you can also change its status by hand. Only a sent order can be put back to draft.

Expected inflows

Each supplier-order line creates an expected inflow ("virtual inflow" in the back office). It does not raise the displayed stock; it feeds projections, for example in "My stock".

A recalculation brings the expected inflows back in line with the current lines.
A cancellation removes the order's expected inflows.
A reception records the real inflow in stock, then removes the expected inflows: the stock has become physical.
Undoing a reception reverses the movement and restores the expected inflows.

Supplier emails: prepare, review, send

Preparation (every morning): for each draft due to be sent, the email is rendered (subject, content, recipients) and placed in the review queue. Nothing is sent.
Review (back office): the review queue shows the email exactly as it will leave. You can edit the subject and recipients, postpone the send, re-prepare the email, or cancel the order. See Back-office surfaces.
Send: before sending, the current lines are compared with those at preparation time. If they changed (a customer order came in meanwhile, for example), the send is refused with a "re-prepare, then resend" message ("Re-préparez puis renvoyez"). The same applies if the order's slot changed. What you reviewed is exactly what leaves.

Recipients, in order of priority: the ones you entered in the review queue, otherwise the "Recipient email" addresses on the supplier record, otherwise the supplier's general email. If no usable address is found, the email is not sent.

Warning

A cancelled order is never sent, even if its email was already prepared.

If automatic sending is active for a supplier, its drafts leave on their own shortly after slot time, after a pre-send check. How it works and its limits are covered in Safety nets.

After the send: reception

After sending, the order waits for its reception. The expected reception date is computed from the send slot and the supplier's reception lead time (or, when empty, its delivery lead time).

You confirm the reception in the back office: stock goes up by the number of units received (packages × package size). This is the normal path.
If you forget, the platform automatically validates the reception of a sent order once its expected reception date is at least 12 hours in the past (default delay). The delay avoids validating a delivery that has not happened yet.

The hour-by-hour schedule is in the daily timeline, and how stock movements are recorded is in Write paths.

The life of a customer order

A customer orders on your store (PrestaShop, or an order entered in Inklura) with a desired delivery date. That date, not the purchase date, decides the supplier send slot.

The order arrives in real time (or during the periodic sync). An expected outflow ("virtual outflow") is recorded; physical stock does not go down yet.

The engine recalculates the drafts of the ordered products' suppliers: right away if event-driven recalculation is active for your workspace, otherwise at the next 30-minute pass.

The demand is assigned to the send slot that still allows on-time delivery. The slot quantity is the demand minus retained stock, rounded up to the package. The draft line keeps a reference to the customer order and creates an expected inflow.

In the morning, the supplier email is prepared and placed in the review queue. Nothing leaves.

You review, adjust if needed, and send. If the lines changed since preparation, the send is refused until you re-prepare the email. The order becomes sent.

The goods arrive. You confirm the reception: stock goes up and the order's expected inflows are removed. If you forget, the platform validates the reception automatically 12 hours after the expected date.

You validate the customer delivery (order by order, or "Validate today's round"): stock goes down. It may go negative if the goods left before their reception was entered; the next reception makes up for it. The next demand starts from this stock.