Connecting warehouse software to an ERP starts with operational decisions. Which system owns the product record? What does available stock mean? When should an order become shipped? Put those answers into a shared checklist before deciding that a working connection is ready for everyday use.
This guide is for warehouse and operations managers planning an integration. It offers requirements to discuss with your software supplier and business-system owner. The examples describe proposed test scenarios rather than guaranteed behavior in any particular connector.
Map one complete order first
Choose an order that represents normal business and follow it from entry through picking, packing, and dispatch. Identify which system performs each step and where another team needs an update. Include the person who checks the final records.
Write down the reference that connects the records. Ask staff how they would find the same order in each system during a customer inquiry. If the references differ, confirm that the relationship remains visible to the employees who need it.
Then choose an exception, such as a partial shipment or a canceled line. Discuss what each team expects to see. A connection that transfers the ordinary order successfully still needs clear behavior when the physical work changes.
Decide where important records are maintained
List the data that crosses the connection: products, customers, orders, quantities, and relevant status updates. Assign an owner for creating and changing each record. Keep the list focused on the data your operation actually needs.
Define which edits are allowed in the warehouse system and which must start in the ERP. A connection described as two-way does not by itself explain every field or permission. Ask for the agreed directions and restrictions in a form your team can review.
Include changes to existing records. Test an updated customer delivery detail or a product description change, then inspect the result in both systems. Decide how already-released work is treated when an upstream record changes.
Check identifiers, units, and locations
Use representative items to test how the systems match product identifiers. Include an item with several barcodes or a different purchasing and selling unit if your business uses those patterns. Record the expected mapping explicitly.
Confirm the conversion rules before processing quantities. A carton and an individual unit must have a shared interpretation across the connection. Ask the supplier to demonstrate a receipt and an order using the relevant units.
Review location scope as well. One system may need a warehouse total while the other tracks individual shelves. Establish which quantities are exchanged and how your operation interprets temporary locations, inspection holds, and stock in transit.
Define quantities and statuses in plain language
Agree the meaning of on-hand, reserved, and available stock in the proposed setup. Ask which transactions change those values and when the other system receives the update. Do not assume that two screens using the same word calculate it identically.
Set the order-status triggers around the physical workflow. Picked, packed, booked with a carrier, and collected are distinct events your business may need to distinguish. Choose the events that matter and verify their mapping.
Test a partial completion. If part of an order ships while another line remains open, both teams need to understand the outstanding work. Review the records together instead of judging success from a single completed message.
Agree which system owns each decision
Use this table as a workshop checklist. It identifies decisions to document and scenarios to demonstrate. Confirm the exact supported behavior with the supplier responsible for your proposed connection.
| Data or event | Decision to document | Scenario to test |
|---|---|---|
| Customer and product records | Source and allowed edits | A changed identifier or duplicate |
| Stock quantities | Meaning, location scope, and update timing | Two transactions close together |
| Order status | Trigger and destination for each update | A partial shipment |
| Error recovery | Owner, alert, and safe retry method | An interrupted update |
| Permissions | Who can change or approve records | An unauthorized action |
Give errors a visible owner and recovery path
Ask where failed updates appear and who checks that view during the working day. Agree the information needed to investigate an error, including record references and the intended action. Avoid a process that depends on someone noticing a stale screen by chance.
Demonstrate an interrupted update. Confirm how staff can tell whether the transaction completed, remains pending, or needs intervention. Ask the supplier to show the supported recovery action and how it avoids creating an unintended duplicate.
Define escalation between operations and technical support. The warehouse team needs to know whether work can continue, which records need review, and who authorizes recovery. Put those responsibilities into the pilot documentation before a busy day exposes the gap.
Reconcile outcomes during the pilot
Select a small set of transactions and compare their final results in both systems. Include a receipt, a pick, a shipment, and a stock correction where those events are part of the agreed integration scope. Use known quantities and references.
Test updates close together if several employees can act on the same stock or order. Inspect the resulting records and ask how conflicts are handled. Evaluate the behavior your actual setup provides rather than relying on a general description of synchronization.
Check permissions with the people who will use the system. Someone who can record a count may not be authorized to approve an adjustment. Confirm that user roles match the workflow and that a rejected action leaves a clear next step.
Plan the handover into normal operation
Write acceptance criteria before the final pilot review. Include correct records, understandable exceptions, trained owners, and a documented way to recover interrupted work. Assign responsibility for each unresolved item rather than treating it as a minor note.
Agree the rollout scope and the process for stopping expansion if an important problem appears. Keep a clear record of work already performed during the pilot. A controlled handover should help the team understand what is live and who supports it.
How Raptool fits
Raptool WMS describes two-way synchronization with Fortnox and names connections including Visma.net, Business Central, SAP S/4HANA, and NetSuite. Its warehouse workflows cover receiving, picking, packing, shipping, and stock counts.
Use the relevant Fortnox, Visma, or SAP page as a starting point for discussing your business system. Confirm the exact product and version, data scope, update timing, and recovery behavior in the proposed configuration.
Bring representative records and the checklist to a demonstration. Ask Raptool and your ERP owner to walk through the complete transaction and an exception together. The useful outcome is a connection your operations team can explain, verify, and support in daily work.
FAQ
What should we define before connecting a WMS and ERP?
Agree the records each system owns, the identifiers they share, the meaning of quantities and statuses, and the rules for handling errors. Validate those decisions with representative orders.
Does two-way sync mean every field can be edited in both systems?
Do not assume it does. Confirm the direction, permissions, conflict rules, and supported updates for each record or field in the proposed connection.
How do we avoid duplicate orders during recovery?
Ask the supplier to demonstrate the exact retry and duplicate-handling behavior. Operations staff need a documented recovery process that preserves the intended transaction.
Which ERP systems does Raptool WMS mention?
The Raptool WMS page names Fortnox, Visma.net, Business Central, SAP S/4HANA, and NetSuite among its connections. Confirm your exact product, version, scope, and required workflows.
When is an integration pilot complete?
Set acceptance criteria before testing. Include ordinary transactions, exceptions, permissions, reconciliation, and responsibility for unresolved errors before approving a broader rollout.
Tags
Want to see how this could work in your warehouse? Book a demo and we will walk you through it.
Book a demo
