A distributor routes each order by the shopper's city
A business with warehouses in several cities: each Zid city is served by one warehouse, and each order reaches the ERP routed to that warehouse.
A distribution business with warehouses in several cities sells through a Zid store and runs an ERP. In this setup, each Zid city is served by one warehouse, and every order reaches the ERP already routed to the warehouse that serves the shopper’s city.
The order is then prepared from the ERP, and the Zid order status updates when the ERP invoices.
The problem before routing
A business like this has several warehouses and customers in many cities. When every online order lands in one place, each order raises a question: which warehouse ships it?
Such businesses usually face one of two situations:
- The warehouse is picked by hand. Someone checks the shopper’s city, then passes the order to the warehouse that serves it.
- Orders ship from one fixed warehouse, even when another warehouse serves the shopper’s city.
In the first, every order waits on a manual decision, and the decisions grow with the orders. In the second, the order leaves a warehouse far from the shopper while another one serves their city.
There is a second gap. Without a connection, the Zid order status usually needs a separate update after the ERP invoices, so the merchant can see in Zid that the order was invoiced.
| One destination for every order | Routed by the shopper's city | |
|---|---|---|
| Where the order goes | Every order lands in one place | Each order is routed in the ERP to the warehouse for the shopper's city |
| Choosing the warehouse | A manual call on each order, or one fixed warehouse | One warehouse per city, set during setup |
| Preparing the order | Starts once someone decides which warehouse owns the order | Starts from the ERP once the order arrives |
| Order status in Zid | A separate update after invoicing | Updated in Zid when the ERP invoices |
A general comparison of the problem and the setup.
The setup
Our team does the setup with the merchant. Every store follows the same steps: install the app and choose a plan, pick the data to connect and the system, enter the API keys (with help getting them if needed), approve the scope of work, then test on the store’s own orders. The connection goes live once the merchant approves the test report.
What is specific to this store is the city map. During setup, each Zid city gets one warehouse, and every order follows that map.
One warehouse per city
During setup, each Zid city is assigned the one warehouse that serves it.
Paid in Zid
The order is paid in the store and its notice reaches the app.
Customer record
Depending on your ERP, the customer is linked to their ERP record or a new record is created, or orders post under one customer account chosen during setup.
Posted to the right warehouse
The order is posted to the ERP with the customer, items, tax and shipping, routed to the warehouse for the shopper's city, exactly once.
Read back
The order is read back from the ERP to confirm it was posted.
Invoiced, status in Zid
The order is prepared from the ERP, and when it is invoiced the Zid order status updates.
One warehouse per city
The rule is simple. Each Zid city is served by one warehouse, and an order goes to the warehouse that serves its ship-to city. Our team sets the city list and the map once during setup, so no order needs a fresh decision.
If the ship-to city is not on the list, the order goes to the warehouse of the Zid location fulfilling it, and otherwise to the default warehouse.
From payment to the ERP
Once the order is paid in Zid, depending on the ERP, the customer is linked to their ERP record or a new record is created, or orders post under one customer account chosen during setup. The order is then posted with the customer, items, tax and shipping, routed to the warehouse for the shopper’s city.
The same order never posts twice. Each Zid order has one matching order in the ERP, even if its notice arrives more than once.
The read-back check
After posting, the app reads the order back from the ERP, so the confirmation comes from the ERP itself.
Invoicing and status in Zid
The order is prepared from the ERP. When the ERP invoices it, the Zid order status updates, so the merchant can see in Zid that it was invoiced.
What runs today
In this setup, the connection:
- Routes each order to the warehouse that serves the shopper’s city.
- Posts each paid order to the ERP with the customer, items, tax and shipping.
- Links the customer to their ERP record or creates one, or posts orders under one customer account chosen during setup, depending on the ERP.
- Reads each order back from the ERP to confirm it.
- Posts each order exactly once, even when its notice repeats.
- Updates the Zid order status when the ERP invoices.
The kind of result
Every order reaches the ERP already routed to the warehouse for the shopper’s city. Picking a warehouse needs no manual call on each order, because the city map was set once during setup.
Orders are prepared from the ERP. Each one arrives with the customer, items, tax and shipping, already read back from the ERP to confirm it was posted.
Each order’s status shows in Zid after the ERP invoices it, with no manual update.
Numbers across all stores
These figures come from Zid Integrations data and cover every store that uses the app.
- automated operations between Zid stores and ERPs
- Over 1 million
- orders delivered to ERPs
- Over 14,000
- lost orders
- Zero
Figures across all stores that use the app, not this store's.
What another merchant can take from this
The first lesson is that routing starts with the list of cities. If you ship from more than one warehouse, these steps help before and after go-live:
- List every city your store ships to before you go live.
- Give every city one warehouse, including cities far from all of them, so none is left without one.
- Agree up front which warehouse will serve any new city you start shipping to.
- Review the test report with orders from several cities, and check that each reached the warehouse for its city.
- Revisit the city map whenever a warehouse opens or closes.
- Make the ERP the reference for your warehouses, since each order arrives there already routed.
Routing rests on the same base as every connection: each order posted to the ERP once, then read back to confirm it.
Plan and systems
Multi-warehouse routing is on the Business plan, which covers 2,000 orders a month and adds priority support. It sends each order to the warehouse that serves the shopper’s ship-to city, from a city list our team sets during setup. Details of each plan and current prices are on the app’s page in the Zid App Market. Trials run 7 days on monthly billing and 30 days on yearly billing.
The app works with several ERPs and any system with a public API. For any new store, our team does the setup with you, and you go live in about two weeks from install, after a test report you approve.
To route your store’s orders to the warehouse that serves each shopper’s city, install the app from the Zid App Market.
