Every warehouse system claims two-way ERP integration. The differences show up later: what exactly flows, what happens to a bad message, and who can fix a failure at 8 a.m. without calling a developer. This page answers all three.
Integration is not a checkbox — it is a set of specific messages with specific validation. Here is the catalogue.
Nothing takes effect just because it arrived. Every message is validated against the warehouse’s own rules first.
The warehouse reports reality; the business system stays authoritative.
Transports fit your ERP, not the other way round: file, database and service interfaces, with scheduled jobs for recurring exchanges. Proven across tens of millions of integration records in current and earlier Linari deployments.
These are real rejection reasons from live operations. Each one is a problem caught at the boundary instead of discovered on the floor.
A rejected message is not a failure of the integration — it is the integration doing its job. The failure would be letting bad data through and finding it in a stock count three weeks later.
This is the story that matters more than any feature list — what your morning looks like after a bad night.
The nightly store-order file references a product that is not active in warehouse 2.
Listed on the monitoring screen with the reason in plain language — not buried in a server log.
Master data is corrected in the ERP — the system of record — not patched by hand in the warehouse.
Re-interface, from the screen. No developer, no database session, no lost trail.
Allocation, tasks, dispatch — and the audit trail shows the whole story, including the failure.
A monitoring screen shows integration errors as they occur, with the reason in plain language — and for supported message types, a replay action an operator can use without a developer and without losing the operational trail.
Products, orders and prices are born in the ERP and stay owned by it. The warehouse enforces operating rules on top and reports reality back — it never becomes a second, competing source of truth.
Validation happens when the message arrives, against the same rules the floor runs on. A broken order is held with its reason — it cannot silently corrupt stock, allocations or history.
The person who can see the failure can also resolve it: fix the cause in the ERP, press replay. 2 a.m. problems become 8 a.m. routine, not emergency phone calls.
That is exactly why the interface layer is file, database and service based rather than a fixed connector list: it meets your ERP where it is. In the technical conversation we map your message types to the interfaces and show the same pattern running live against a customer’s ERP.
Products, barcodes, locations and opening stock are loaded during implementation into your test environment first — the same interfaces, on your own data — and validated by your team before production go-live.
Nobody — and that is the design. The failure is recorded with its reason and waits, visible, on the monitoring screen. In the morning the cause is fixed in the ERP and an operator replays the message. Nothing is lost in between.
Duplicate deliveries are recognised and ignored. A resent file does not double your receipts or your stock.
Tens of millions of integration records across current and earlier Linari deployments, exchanged on schedules that run every day, in both directions.
Show us the message that keeps breaking between your ERP and your warehouse. We will show you what it looks like when it fails visibly, gets fixed at the source, and gets replayed — with the trail intact.