Linari is not a list of disconnected modules. It is one chain where stock status, location, reservation and task decisions stay consistent from the receipt to the truck — planned and watched in the web back office, executed by scan on handhelds, and reconciled with your ERP through a recoverable interface.
Most warehouse problems live in the gap between what the office believes and what the floor did. Linari closes that gap by running both on one stock picture, updated scan by scan.
The back office is where orders, stock and exceptions become decisions:
The handheld shows one controlled action at a time — the decisions are already made:
This is the path every store order takes — and at each step, what the system creates and enforces.
A store order lands through the interface layer and is validated against warehouse rules.
STORE ORDERRotation strategy picks the stock — expiry-first where enabled — and the reservation locks it to this order.
RESERVATIONPick tasks are assigned per worker; each scan is confirmed centrally as it happens.
PICK TASKSA short pick is flagged and visible — allocate-and-flag or hold-the-line, per your warehouse rule.
EXCEPTIONWhere enabled, the order is verified against the goods in the box before it may leave.
CHECKPallets are confirmed as tracked objects and the waybill is held on the shipment record.
PALLET · WAYBILLInvoice and dispatch confirmations flow back through the same recoverable interface.
ERP CONFIRMATIONEvery step above writes to the same audit trail: available and real quantities before and after, with operation, reference and operator. How traceability works →
Each stage below is a live capability, not a roadmap item — with its own rules, screens, and straight answers to the hard questions.
Every receipt is scanned against its purchase order while the truck is still in the yard. Quantity, barcode, batch and expiry are validated at the door — while the problem is still the supplier’s problem.
Supplier and alternative barcodes · batch and expiry at entry · over-receipt tolerance per warehouse · receipt validated against the delivery plan where required.
Explore Receiving →Placement is a tracked handheld task confirmed by scan, so goods that are received but not yet on the shelf are never invisible to the rest of the operation.
Case or piece per warehouse · picking faces ranked above bulk · aisle, bay, level, zone as first-class structure.
Explore Put-away →Rotation, reservations, barcode alternatives and location priority are resolved before the task reaches the operator. One live site runs expiry-first across alternative barcodes.
Reserved stock held · partial allocation per warehouse · replenishment that names blocked orders · order changes after release.
Explore Picking →Where you need it, an order is verified against the goods physically in the box before it can leave. A failed check stops the order and stays visible until resolved.
Hard gate per warehouse · separate QC stage · pallet confirmation delayed for QC — live in two warehouses.
Explore Checking / QC →Delivery days are derived from real per-warehouse cut-offs, and loading runs against pallets and orders that have already passed their checks.
Pallets tracked and manifested · waybills on the shipment · confirmations back to the ERP.
Explore Dispatch →Transfers, corrections and status changes are recorded operations carrying before-and-after quantities, reference and operator. Nothing edits a quantity in silence.
Tracked transfers · corrections with a reason · status states with history · counting proven in an earlier generation.
Explore Stock control →Every warehouse carries its own operating configuration, because the operations in those buildings are genuinely different.
| Operating rule | Ambient DC | Fresh produce | Third site |
|---|---|---|---|
| Pick-plan cut-off time | 15:00 | not used | 12:45 |
| Expiry threshold before stock is held back | 30 days | not used | 12 days |
| Rotation strategy | expiry-first, across alternative barcodes | site default | simpler rule |
| Picker must scan location / item | mandatory | off | off |
| Short pick behaviour | allocate available, flag the rest | site default | hold the line |
Read from the production configuration of three live warehouses. See the full table →
Rules can only be enforced on data that is structured for them. Products, locations and people are first-class objects — synchronised with your ERP, scoped per warehouse.
A product carries multiple barcodes — including supplier-specific ones — recognised at every scan and rejected when they belong to another product or warehouse. Batch and expiry live on the stock, not in a spreadsheet.
Aisle, bay, level and zone are first-class structure. Picking faces rank above bulk storage, and location logic follows your physical building — not the other way round.
Suppliers, customers and carriers as partners; users with roles, field- and record-level access, scoped by warehouse and business unit. A user in one warehouse does not touch another’s data.
The operation does not end at the scan — it ends at the paperwork the driver, the customer and the accountant need.
Waybills and shipment documents are generated by the system and held against the shipment record — not printed from a side spreadsheet.
Operational reports and printed documents use editable templates, so your paperwork can look the way your operation and your country’s practice require.
Every operational screen is a filterable grid the office team can slice and export — orders, stock, movements, exceptions.
One system. Receiving, put-away, picking, checking, dispatch and stock control read and write the same stock picture — the same reservations, batch and expiry data, and audit trail. A rule set in one stage is respected in every other, and the ERP interface feeds all of them through one layer.
That is the point of the per-warehouse configuration: cut-offs, rotation strategy, scan mandates, short-pick behaviour, case handling and more are set per building — on the same release and the same database. Three live warehouses run visibly different rules today.
The office plans and watches: orders, stock, exceptions, replenishment, integration, people. The aisle executes: receiving, put-away, picking, checking, transfers and counting on Android handhelds, one controlled action at a time. Both surfaces work on the same live data.
Start with one warehouse and one peak period. Before that: a process map you sign off, a test environment on your own data connected to your ERP, and validation by your own team on real handhelds. Judge us on how the floor runs, then decide about the rest.
Bring one difficult scenario from your own warehouse. We will run it from the ERP order to the confirmed pallet in front of you — office screens and handhelds side by side.