The system says 40. The shelf has 12. Which number will your next purchase order believe?
Warehouse management system · Georgia · Kenya
A warehouse management system built for real warehouse operations. Proven in Georgia.
Linari is a warehouse management system that controls the decisions between the receiving dock and the dispatch door — stock, locations, reservations, rotation rules, quality checks and operator tasks. Seven warehouses across two countries run on it today.
Bring one difficult scenario from your own warehouse. We will run it in the system — not in a slide deck.
Three live warehouses. One system.Georgia · production
Operating rule
WH 1
WH 2
WH 3
Pick-plan cut-off
15:00
none
12:45
Expiry threshold
30 days
none
12 days
Expiry-first allocation
across alternative barcodes
across alternative barcodes
on
—
off
Mandatory location scan
on
off
off
Mandatory item scan
on
off
off
Partial allocation
on
—
off
Case / box handling
off
off
on
Weight-based stock
yes
yes
no
Same codebase, same release, same database. Three warehouses that work differently because their operations are different.
Figures are taken from the production databases of the live Georgia and Kenya operations. "Order lines" counts shipping-order detail lines created per calendar day; the same definition is used for every number on this page. Customer references and visits to a working site are available under NDA.
The real problem
Warehouses do not fail in the features menu.
They fail in small decisions repeated hundreds of times a day. A serious WMS makes those decisions visible, repeatable and enforceable.
Your pickers are walking around the warehouse instead of picking from the right location.
A pallet with an earlier expiry is still on the rack while newer stock has already shipped.
Something shipped wrong — and nobody can tell you who touched it, where, or when.
Every one of these is a decision the system should have made before the operator had to improvise.
One system. Different warehouse rules.
Most vendors say they are flexible. Here is what that means in practice.
Every warehouse carries its own operating configuration. The same release behaves differently in each building, 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 |
| Delivery-plan validated on receipt | required | off | off |
| Expiry threshold before stock is held back | 30 days | not used | 12 days |
| Rotation strategy | expiry-first, including across alternative barcodes | site default | simpler rule |
| Picker must scan the location | mandatory | off | off |
| Picker must scan the item | mandatory | off | off |
| Short pick behaviour | allocate what is available, flag the rest | site default | hold the line |
| Over-receipt tolerance | none | allowed | none |
| Case / box quantity handling | off | off | on |
| Stock held by weight | yes | yes | no |
| Point at which available stock is deducted | earlier stage | later stage | later stage |
In the demo, ask us to open two of these warehouses side by side and walk the differences. It is the fastest way to find out whether a vendor's "flexible" means anything.
Dock to dispatch
One warehouse management system, one operational chain.
Not a list of disconnected modules. One operational chain where stock status, location, reservation and task decisions stay consistent from the receipt to the truck.
01 · Receiving
Catch the problem at the dock, not at month-end.
Every receipt is scanned against its purchase order. Quantity, barcode, batch and expiry are validated while the truck is still in the yard and the supplier can still be held to it.
Supplier and alternative barcodes
A product can carry several barcodes, including supplier-specific ones. They are recognised on receipt — and rejected when they belong to another product or another warehouse.
Batch and expiry captured at entry
Rotation data is recorded at the moment of receipt, so every later picking decision can rely on it.
Over-receipt tolerance
Configurable per warehouse: accept a defined overage, or reject anything above the ordered quantity.
Receipt against the delivery plan
Where the operation requires it, a receipt can be validated against the planned delivery before stock is accepted.
02 · Put-away
Stock stays visible between the dock and the rack.
Put-away is executed as a tracked task on a handheld, so goods that have been received but not yet placed are never invisible to the rest of the operation.
Task-driven, scan-confirmed
Placement is confirmed against the location, not written down and entered later.
Case or piece
Warehouses that work in cases can hold and move stock at case level; others work in pieces. Set per warehouse.
Picking-face priority
Locations are ranked so that picking faces are treated differently from bulk storage when stock is allocated.
Location and zone structure
Aisle, bay, level and zone are first-class, so location logic and reporting follow the physical building.
03 · Picking
Picking that understands stock — not just orders.
Linari resolves the warehouse rules before the task ever reaches the operator. Rotation, reservations, barcode alternatives and location priority are applied per warehouse.
Expiry-first or first-in-first-out
The rotation strategy is chosen per warehouse. One live site runs expiry-first across alternative barcodes — so the oldest stock goes first even when it carries a different barcode for the same product.
Reserved stock is held
Stock allocated to an order is held against it. Another workflow cannot consume it while the allocation stands.
Picking-face priority
The worker is sent to the right face first, before falling back to less efficient locations.
Partial allocation, per warehouse
Optional: keep workable stock moving and flag the shortfall as an exception, instead of blocking the whole order. On in one live warehouse, off in another.
Replenishment that names the blocked orders
A report shows which locked location to move stock out of, how much, and exactly which customer orders become allocatable as a result.
Order changes after confirmation
Quantities can be adjusted after an order is confirmed and released — used hundreds of thousands of times across both live countries.
04 · Checking / QC
Checking can be a hard gate, not a formality.
Where the operation requires it, an order is verified before it can be dispatched. Checking is switched on per warehouse and runs on handhelds in the packing area.
Verified against the goods
The check confirms what is physically in the box, not what the paperwork said should be in it.
Separate QC stage
A distinct quality-control step runs alongside checking where the operation needs one.
Pallet confirmation held for QC
Pallet confirmation can be delayed by a defined interval so QC has time to intervene before dispatch. Live in two warehouses.
Exceptions are held, not hidden
A failed check stops the order and stays visible until a responsible person resolves it.
05 · Dispatch
The plan matches what the warehouse can actually ship.
Delivery days are derived from real cut-off times, and loading is executed against pallets and orders that have already passed their checks.
Cut-off driven planning
An order that misses today’s cut-off is planned for the day it can genuinely leave. Cut-off times differ per warehouse — 15:00 in one live site, 12:45 in another.
Pallet and manifest control
Pallets are built, confirmed and manifested as tracked objects, not as a note on a printout.
Waybills
Waybill documents are generated and held against the shipment record.
Confirmation back to the business system
Invoice and dispatch data flow back into the ERP through the same interface layer that brings orders in.
06 · Stock control
Stock moves for a reason, and the reason is recorded.
Transfers, corrections and status changes are operations in their own right — each one leaving a complete before-and-after record.
Transfer between locations and warehouses
Moves are executed as tracked tasks. Earlier generations of the system ran over half a million of them.
Controlled inventory modification
Corrections are a recorded operation with a reason, not a silent edit to a quantity.
Stock status changes
Moving stock between sellable, blocked and other states is tracked with its own history.
Stock counting
Cycle counting by location, with worker tasks, recount rounds and recorded discrepancies. Proven in an earlier Linari generation; see below.
ERP integration
When a message fails, you can see it — and send it again.
Every warehouse system claims two-way ERP integration. The question that matters is what happens on the day it breaks. In Linari, a failed message is a visible record with a replay action, not a silent gap someone discovers three weeks later.
✓
Both directions
Products, barcodes, purchase orders, store orders, stock and invoice data.
Products, barcodes, purchase orders, store orders, stock and invoice data.
✓
Failures are listed, not buried
A monitoring screen shows integration errors as they occur.
A monitoring screen shows integration errors as they occur.
✓
Replay from the interface
Supported message types can be re-sent by an operator without a developer and without losing the operational trail.
Supported message types can be re-sent by an operator without a developer and without losing the operational trail.
✓
Proven at volume
Tens of millions of integration records across current and earlier Linari deployments.
Tens of millions of integration records across current and earlier Linari deployments.
Integration monitoringStore orders · today
Store order interfaceProduct not active in this warehouse
FailedRe-interfaceSupplier order interfaceBarcode belongs to another warehouse
FailedRe-interfaceStore order interfaceRe-sent after master data corrected
ProcessedViewInvoice exportDispatch confirmation returned to ERP
ProcessedViewRepresentation of the integration monitoring screen. Ask to see the real one, with live data, in the demo.
Traceability
Every movement records what the stock was, and what it became.
Linari does not store a change and leave you to reconstruct the balance. Each stock movement carries the available and real quantity before and after the operation, with its reference, operation number and document.
Available before → after
Real before → after
Operation & reference
Location & batch
Stock movement historyOne product · one location
Picking · order allocation
Available36 → 24
Real36 → 36
Put-away · from receipt
Available12 → 36
Real12 → 36
Transfer · to picking face
Available0 → 12
Real0 → 12
Illustration of the recorded structure. Every movement in production carries these values.
Execution on the floor
The warehouse management system goes to the operator, not the other way round.
Receiving, put-away, transfer, picking, checking and counting are executed on a handheld in the aisle. The operator sees the next controlled action — not the complexity behind it.
Scan-driven tasks
Role-based screens
Barcode validation
Per-worker task lists
What happens when the network drops
The handheld works against a live connection to the server, so every scan is confirmed centrally and two operators can never work from a stale picture of the same location. Offline task execution is not currently supported. Before go-live we walk the building with you and find the dead spots — that is a site-survey problem, and it is cheaper to solve with an access point than with software.
LINARI · PICKING10:42
NEXT TASK
Go to
location P-12-04
Scan location barcodeP-12-04
Product 374110Expiry-first selected · exp. 14 Sep 2026
Pick 12 piecesReserved for this order
CONFIRM PICK
Earlier generations
Capabilities this platform has already carried at scale.
Linari has been through several generations. These capabilities ran in production in earlier Georgian deployments — they are part of the platform’s history rather than of every current installation, and we will say so plainly rather than implying otherwise.
Cross-docking
Goods committed to an outbound order moved through the building without being stored twice — recorded on millions of stock movements.
Storage-group slotting
Products mapped to their permitted locations across millions of product-location rules, driving where stock was allowed to go.
Cycle counting
Counting by location with worker tasks, recount rounds and recorded discrepancies, run over tens of thousands of count lines.
Dock management
Docks defined and used as part of the loading and dispatch flow.
Driver and delivery
Drivers and delivery records held in the system as part of the outbound process, across thousands of driver records.
Zoned warehouses
Warehouses divided into dozens of zones, with location structure and reporting following the physical building.
Adaptability
A warehouse management system is half of the decision. The team behind it is the other half.
Any vendor can demo a screen. What matters over five years is whether they understand your operation, can change the system safely, and are still there after go-live.
01
We speak in warehouse decisions, not feature names.
Rotation rules, reserved stock, picking-face priority, alternative supplier barcodes, case-level handling, expiry thresholds. In a real operation these are everyday behaviour, and the system treats them that way — the awkward cases were in the design from the start, rather than added after the first peak season.
02
When the process is fundamentally different, the foundation still holds.
One customer's operation was different enough that counting, picking, put-away, packing and dispatch all had to work another way. They run on the same foundation as every other Linari site — the same inventory model, the same audit trail, the same integration layer, the same security and warehouse scoping, the same handheld architecture — with the operational layer above it replaced.
03
Your process changes on Monday. So can the system.
Most vendors answer an operational change with a quotation and a quarter. With us, a change is a tracked ticket, it is tested in your own test environment before it reaches production, and it is written up in a release note you can read. Ask us in the demo to show you the last ten changes we shipped for a live customer.
This is not a young product. Linari grew out of a warehouse system that has been running in daily production for over a decade, rebuilt across several generations into what our customers use today.
Where we fit
Linari is not the right system for every warehouse.
Most warehouse software pages pretend they have no competition. You already know you have three realistic paths, so we would rather be straight about them.
Your ERP may be enough
Stay where you are when…
- One person still holds the stock picture in their head, and that works.
- Locations, batches and expiry are not what decides your picking.
- Your team is comfortable working from printed lists rather than scanned tasks.
- Your ERP's warehouse module covers your rules today, and you expect that to hold.
Linari fits
Talk to us when…
- Your warehouse rules are more complex than your ERP module can express.
- Rules differ by site, by customer or by product — and one global setting cannot cover them.
- Expiry, batch or reservation decides which stock may be picked, not just how much you have.
- Work must be executed and confirmed by scan in the aisle.
- Your ERP stays the business system, and the warehouse must stay reconciled with it.
- Your process will keep changing after go-live.
A global platform may fit better
Look elsewhere when…
- You need one template rolled out identically across many countries, implemented by local partners.
- Your plans include automation or robotics ecosystems.
- Procurement requires a vendor of that size — a legitimate constraint, and we will not argue with it.
If the first or third column describes you, you will hear it from us in the first meeting. We would rather lose a deal than a reference.
For your IT team
The questions your IT director will ask first.
Answered plainly, including where the answer is «not today». Full technical documentation is available on request.
- Platform
- .NET web application with a Microsoft SQL Server database.
- Schema changes
- Applied as versioned database packages, per environment, with a test environment ahead of production.
- Roles and permissions
- Role-based, with field- and record-level access control.
- Scoping
- Users and data are scoped by warehouse and business unit throughout the system.
- Network dependency
- The handheld requires a live connection. Offline task execution is not supported.
- Integration
- File, database and service interfaces, with scheduled jobs for recurring exchanges.
- Failure handling
- Failed integration messages are listed on a monitoring screen and supported types can be replayed from it.
- Logging
- Application and performance logging with per-request timing retained in the database.
Implementation
Four stages, each with something you can hold.
Every warehouse is different, so we will not quote you a number of days before we have seen yours. What we commit to is this sequence — and to being on your floor rather than only in your meeting room.
A process map you sign off
We walk the building — goods in, locations, rotation rules, exceptions, and what actually happens on a peak day. You receive a written description of your own process and approve it before anything is configured.
A configured, integrated test environment
Your warehouse structure, locations, products, users and operating rules, connected to your ERP and running on your own data — in a test environment you can log into.
Operational validation by your own team
Your supervisors and operators run real scenarios on real handhelds: your SKUs, your barcodes, your awkward cases. Nothing reaches production until the people who will use it have signed it off.
Go-live and continuous improvement
Our people are in the warehouse for the first operating days and through the first peak. After that, changes keep coming — tracked, tested and documented.
You do not have to commit to everything at once. Start with one warehouse and one peak period, judge us on how the floor runs during it, and decide about the rest afterwards.
Book an operational demo.
Bring one difficult scenario from your own warehouse — reserved stock, expiry rotation, a rule that differs by customer, a stubborn ERP interface. We will run it in the system, not in a slide deck. A warehouse specialist answers within one working day.