Which system knows what?
ERP software organizes business activity, while a warehouse management system handles warehouse-related work. Fleet software coordinates vehicle execution. Real installations may have additional layers; who makes a particular decision matters more than a software category name.
Knowing that a pallet is ready at station A may be enough for a local collection if destination and permission are clear. An inventory transaction may also need item, carrier, batch and storage-location data. The same physical trip can therefore require a very different data exchange.
Three possible stages of introduction
| Stage | Order and feedback | Prerequisite | Typical fit |
|---|---|---|---|
| Local flow | Operator or sensor creates demand; the process confirms handover | Unambiguous local source, destination, permissions and faults | Bounded replenishment or empty-container return without automatic stock posting. |
| Limited connection | Existing software supplies selected data and receives completion | Stable identifiers and a clear business definition of completion | Retaining existing software while automating transport. |
| Continuous coordination | Orders, priorities, load data, transactions and exceptions are synchronized | Ownership and recovery across every participating system | WMS-led operations where physical movement and business records are tightly linked. |
These are planning models, not product packages. A simple flow may remain local permanently. Conversely, an isolated pilot proves little about the final operation if complex inventory transactions are essential from the outset.
What connecting a legacy application involves
Older software is not automatically unsuitable. The decisive factors are accessible interfaces, reliable data and maintainable ownership. An old application with a documented service can be easier to connect than a new, heavily customized system with unclear responsibilities.
Possible architectures include an existing service, approved file exchange or an adapter application. These are general options, not claims that every compared platform directly supports every method. The selected route must provide suitable read/write access, timeliness and error handling.
Direct production-database edits should not be treated as a convenient substitute for a missing business interface. Agree supported, maintainable procedures with the system owner first; otherwise technically successful writes can bypass application-level checks.
Define the transport-order data
| Information | Purpose | Decision required |
|---|---|---|
| Unique order identifier | Match requests and feedback | Does it remain stable on retry and restart? |
| Source and destination | Define the transport relation | Who maps business locations to physical stations? |
| Load or carrier | Select suitable handling and vehicle | Which attributes are mandatory? |
| Permission and readiness | Start only permitted work | Who confirms load present, accessible source and free destination? |
| Time or priority | Resolve competing requests | Who may change priority after acceptance? |
| State and completion | Distinguish receipt from execution | Does completion require a confirmed handover? |
| Failure or cancellation | Make outstanding work explicit | Who decides on retry, replacement or manual processing? |
Keep the data model as small as possible while meeting the process requirements. Excess fields create coordination work; missing fields transfer decisions to operators or later exceptions.
Receipt is not completion
A clear order model distinguishes requested, accepted, executing and physically completed work, with explicit error and cancellation states. A successful interface response generally confirms receipt or acceptance; it must not silently become evidence of a successful load transfer.
Consider a pallet already delivered when its completion message fails to reach the WMS. Blindly repeating the transport could move another pallet. Recovery must reconcile the known order state and physical situation before execution is repeated.
A local pilot may initially handle this in one application. A later enterprise connection adds another boundary across which the state must remain understandable. Stable identifiers are therefore useful even in a small pilot.
Sensors do not settle every process decision
A sensor can detect an occupied preparation point. The process still needs to establish whether the load is complete, released and assigned to the correct destination. A camera or light curtain may support those decisions without automatically resolving all of them.
- Occupied position: what load is present, and is it ready?
- Free destination: is it available or reserved for another order?
- Repeated signal: new demand or the same state reported again?
- Uncertain detection: wait, ask an operator or show a clear fault?
Test delayed staff activity, temporarily obscured loads and occupied stations. The target is a dependable workflow rather than a successful detection in an ideal image.
What the suppliers publish
SyncroBot describes a local start with one robot and optional connections to existing enterprise software. [Source]
SYNAOS documents local triggers without ERP/WMS. [Source]
Idealworks reports a connection to Noerpel’s existing WMS. [Source] MiR documents enterprise REST interfaces. [Source] InOrbit BES connects business orders with robot execution. [Source]
A project describes an implementation, an API provides an access route, and optional integration describes responsibility boundaries. All matter to procurement. Compare the providers.
An interface acceptance sequence
- Create a valid order and trace its identifier to physical completion.
- Resend the same message and check the agreed retry behaviour.
- Request an unknown destination and unsuitable load; inspect the rejection.
- Interrupt communication before, during and after handover.
- Occupy and release a destination; observe reservations and waiting work.
- Cancel during execution; reconcile load position and remaining work.
- Restart a system and verify that open states are retained.
- Change a station and identify updates and approvals on each side.
Record the expected outcome, actual result, software version and responsible person. Keep demonstrated features separate from development commitments. This provides useful evidence without invented scores or blanket promises.
Sources and context
Base review: 18 September 2026. Manufacturer information is not an independent comparative test.