Per-warehouse configuration

Your buildings are different. Your rules should be too.

Every vendor says “flexible”. This page shows what that word means in Linari, with the production configuration of three live warehouses — the philosophy behind the rules, the trade-off each one carries, and how a rule actually changes after go-live.

Every value on this page is read from a live production database, not written by marketing.
Two live warehouses, two philosophies

Control-first and speed-first — on the same release.

The clearest way to understand per-warehouse rules is to look at two real buildings that made opposite choices, and are both right.

Live warehouse A · control first

The strict distribution centre.

High-value stock, expiry liability, zero tolerance for a wrong box. Its configuration reads like a checkpoint:

  • Location scan and item scan mandatory on every pick.
  • Expiry-first rotation, looking across alternative barcodes, with a 30-day hold-back threshold.
  • Receipts validated against the delivery plan; zero over-receipt tolerance.
  • Short pick? Allocate what is available and flag the rest — the exception is visible until resolved.
  • Pick-plan cut-off at 15:00, enforced.
Live warehouse B · speed first

The fast fresh-produce site.

Stock turns in hours, not months. Scanning every crate would cost more than it saves — so its configuration gets out of the way:

  • Scan mandates off — the crew works at line speed.
  • No expiry threshold and no cut-off: goods move as they arrive.
  • Over-receipt allowed — a heavier crate is normal, not an incident.
  • Stock held by weight, because that is how fresh produce is actually sold.

Same codebase. Same release. Same database. Different building, different physics.

The evidence

Three live warehouses, side by side.

Eleven operating rules, three buildings, one system.

Operating ruleAmbient DCFresh produceThird site
Pick-plan cut-off time15:00not used12:45
Delivery-plan validated on receiptrequiredoffoff
Expiry threshold before stock is held back30 daysnot used12 days
Rotation strategyexpiry-first, including across alternative barcodessite defaultsimpler rule
Picker must scan the locationmandatoryoffoff
Picker must scan the itemmandatoryoffoff
Short pick behaviourallocate what is available, flag the restsite defaulthold the line
Over-receipt tolerancenoneallowednone
Case / box quantity handlingoffoffon
Stock held by weightyesyesno
Point at which available stock is deductedearlier stagelater stagelater stage

Read from the production database on 2026-08-17 — not from a brochure. In the demo, ask us to open two of these side by side and change one rule while you watch.

A decision guide, not a feature list

Which pain does each rule remove — and what does it cost?

Rules are not free. Each row below is the honest version of the conversation we will have when we configure your building: the problem, the rule, and the trade-off you accept when you turn it on.

The pain

Newer stock ships while a pallet with an earlier expiry sits on the rack — and the write-off lands on you.

The rule that stops it

Expiry-first rotation with a hold-back threshold. One live site also rotates across alternative barcodes, so the oldest stock goes first even under a different barcode for the same product.

The honest trade-off

The picker walks to where the oldest stock is, not the nearest face. You trade steps for shelf life — usually a good trade for anything with a date on it.

The pain

Wrong item or wrong shelf: the box that reaches the customer is not the box on the order.

The rule that stops it

Mandatory location scan and mandatory item scan — each independently switchable per warehouse.

The honest trade-off

Every scan costs a second. A strict DC pays it on every pick; a fast fresh site may honestly be better off without it.

The pain

One missing product blocks a forty-line order, and the truck leaves late.

The rule that stops it

Partial allocation: allocate what is available, keep the order moving, and hold the shortfall as a visible exception. Paired with a replenishment report that names which locked location to empty and which orders it releases.

The honest trade-off

Someone must own the exception queue — flagged shortfalls that nobody works are just a prettier form of chaos.

The pain

The supplier delivers more than ordered, and the overage becomes untracked stock.

The rule that stops it

Over-receipt tolerance per warehouse: reject anything above the order — or accept a defined overage where that is normal business.

The honest trade-off

Zero tolerance means trucks occasionally wait while a discrepancy is resolved at the dock. Decide per building which costs you more.

The pain

Orders promised for today were never physically shippable today.

The rule that stops it

Pick-plan cut-offs per warehouse — 15:00 in one live site, 12:45 in another. An order that misses the cut-off is planned for the day it can genuinely leave.

The honest trade-off

Sales sees a later promise date. That is not the system being slow — that is the system refusing to lie.

The pain

A check before dispatch would catch errors — but checking everything everywhere would halve throughput.

The rule that stops it

Checking as a per-warehouse gate, with a separate QC stage and a configurable delay on pallet confirmation so QC has time to intervene. Live in two warehouses, off where it is not needed.

The honest trade-off

A hard gate stops orders — including, sometimes, orders a manager wanted to push through. That is what a gate is for.

After go-live

How a rule actually changes.

Your process will change on a Monday. Here is what happens between “we need this changed” and the floor working differently — for every change, every time.

Step 1You describe the change

“From Monday, warehouse 2 must scan locations too.” It becomes a tracked ticket, not a phone call.

Step 2It lands in your test environment

Configured on your own data, connected to your ERP — not on a slide.

Step 3Your team validates it

Supervisors and operators run the changed flow on real handhelds and sign it off.

Step 4It ships with a release note

A written record of what changed and why — one you can read, and point to later.

Step 5Production, watched

The rule goes live in the building it belongs to. The other warehouses do not move.

Ask us in the demo to show the last ten changes we shipped for a live customer — the ticket, the test and the release note for each one.

Straight answers

What people ask about configuration.

Is this configuration, or custom code per site?

The rules on this page are configuration on one shared codebase — the same release and the same database serve all three warehouses in the table. When a customer’s process is fundamentally different, the operational layer can be adapted while the same inventory model, audit trail and integration layer hold underneath.

Can rules go finer than per warehouse?

The operating rules above are per warehouse. Several behaviours are naturally finer-grained — barcodes are per product and per supplier, rotation reads each product’s batch and expiry, and tolerances apply order by order. Where your operation needs a distinction the configuration cannot express, that becomes a tracked change, tested in your environment first.

Who is allowed to change a rule?

Nobody flips production settings casually — including us. A change follows the lifecycle above: ticket, test environment, your sign-off, release note, production. That is slower than a checkbox and much faster than a quarter-long change request.

What happens to the other warehouses when one changes?

Nothing. That is the point of per-warehouse configuration: warehouse 1’s scan mandate does not leak into warehouse 2, and both keep running the same release.

Ask us to change a rule while you watch.

Open two live warehouse configurations side by side in the demo, pick a rule, and watch the behaviour change. It is the fastest way to find out whether a vendor’s “flexible” means anything.

Book an operational demo →