Many warehouse buyers discuss WMS integration only after selecting an autonomous forklift supplier. This can create unnecessary engineering changes because the AGV fleet, WMS, ERP, conveyors, PLCs, and warehouse processes need to exchange information in a defined sequence.
Providing the supplier with the right WMS information before the purchase order allows the integration scope to be defined much more accurately.
Start by identifying the systems that currently control warehouse inventory and tasks.
Provide the WMS name, ERP if relevant, version, deployment architecture, available integration methods, and the team responsible for system integration.
The AGV supplier should not assume that every WMS exposes the same interface simply because it supports APIs.
The supplier needs to understand what the WMS is asking the AGV system to do.
For example:
Receive pallet at inbound
Move pallet to staging
Put pallet into rack
Retrieve pallet from rack
Move pallet to outbound
Return empty pallet
Each task should have a defined source, destination, pallet identification, priority, status, and completion condition where applicable.
A typical integration needs more than a “start” message.
The systems may need to exchange task creation, acknowledgement, vehicle assignment, execution status, completion, failure, cancellation, and recovery information.
The exact message structure depends on the WMS and fleet-management system selected.
The WMS and fleet system need a common understanding of warehouse locations.
The buyer should provide the naming or identification method used for receiving stations, staging areas, rack locations, production interfaces where applicable, and shipping points.
Location IDs should be mapped consistently between systems to avoid a task being sent to a destination that the AGV software interprets differently.
Possible integration methods can include REST APIs, WebSocket connections, TCP/IP interfaces, database interfaces, message brokers, or industrial communication through PLCs.
The correct choice depends on the customer's architecture and the supplier's supported interfaces.
“API supported” should therefore be replaced by an actual interface specification in the project documents.
Exception handling is often more important than the normal task flow.
The integration should define what happens when:
A pallet is missing
A destination is occupied
A pallet cannot be picked
An AGV loses communication
A task is cancelled
A destination becomes unavailable
The fleet manager reports a vehicle fault
The WMS should receive an appropriate status rather than waiting indefinitely for a task that can no longer be completed.
Warehouse tasks may have different priorities.
For example, an urgent outbound order may need different dispatch treatment from a normal replenishment task.
The buyer should define whether priority is controlled by the WMS, fleet manager, or a combination of both.
If the WMS identifies pallets by barcode, RFID, database ID, or another method, this information should be included in the integration design.
The buyer should clarify when the pallet identity is created, when it is verified, and which system is considered the authoritative source of inventory information.
The IT team should define network segmentation, authentication, encryption, account permissions, logging, remote access, and data retention requirements before integration begins.
If the fleet software requires an external cloud service or remote technical support, identify what information leaves the warehouse network and which external destinations are required.
| Integration Area | Responsibility |
|---|---|
| WMS configuration | WMS team |
| Fleet manager | AGV supplier |
| API mapping | Define jointly |
| Network | Customer IT |
| PLC interface | Define supplier / integrator / customer |
| End-to-end testing | Define jointly |
Providing representative sample tasks can significantly improve integration discussions.
Give the supplier examples of inbound tasks, put-away tasks, retrieval tasks, outbound tasks, cancellations, failures, and recovery scenarios where possible.
The supplier can then demonstrate how these tasks will be translated into AGV missions before software development is finalized.
The final purchase specification should identify the integration method, message definitions, responsibilities, test cases, security requirements, documentation, and acceptance conditions.
This prevents “WMS integration” from becoming an undefined project item after the AGVs have already been manufactured.
Chinese
English
