Why the same order never posts twice
Before posting an order, the app checks whether it is already in your ERP and posts it only if not, even if the order notice arrives more than once.
Can the same Zid order end up in your ERP twice?
No. Before posting any order, the app checks whether that order is already in your ERP, and posts it only if it is not. That holds even if the order notice arrives more than once, and when a sync is retried.
What a duplicate does to your books
An order in your ERP is a sale, and it moves numbers in your books. Post the same order twice and the sale is counted twice, and so is the tax. If your books track stock, the same quantity comes off twice as well.
Sales and tax come out higher than they are, and the books show less stock than the shelf. Finding the duplicate later means going through the ERP orders, matching them against Zid, and cancelling the extra copy. The longer it goes unnoticed, the more there is to go through.
If the same order arrives more than once
A paid order reaches the app as a notice sent by Zid. The app is built to stay correct even if the order notice arrives more than once. An order that was already sent can also be synced again, for example when a failed sync is retried.
Either way, there is one order in Zid, and there should be one in the ERP. So the app has three guards against duplicates:
- A unique key per store and order on the incoming notice.
- A unique index in the app’s database that refuses to save the same order twice.
- A check in the ERP for an existing document before a new one is created.
The third guard is the check before posting, and it runs on every order.
The check before posting
The notice arrives
The paid-order notice reaches the app from Zid.
Check the ERP
The app checks whether this order is already in your ERP.
Post only if it is not there
If the order is not in the ERP, it is posted with the customer, items, tax and shipping. If it is already there, it is not posted again.
Read it back
The app reads the order back from the ERP to confirm it was posted.
1. The notice arrives
When an order is paid in your Zid store, Zid sends the order notice to the app. The notice is identified by a unique key per store and order. Even if the order notice arrives more than once, work on the order starts with a check.
2. The app checks the ERP
Before posting anything, the app checks whether this order is already in your ERP. It runs that check every time: on the first notice or a repeat, on the first sync or a retry.
3. The order is posted once
If the order is not in the ERP, it is posted with the customer, items, tax and shipping. If it is already there, it is not posted again, and the ERP keeps one order for that Zid order.
The customer is handled before posting too. 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.
4. The order is read back
After posting, the app reads the order back from the ERP. So the confirmation comes from the ERP itself.
The same order, without the check and with it
An example: one order, its notice received twice. The first column posts every notice it gets. The second checks before posting.
| Without the check | With the check | |
|---|---|---|
| First notice | The order is posted | Checked, then posted |
| Second notice | The order is posted again | Checked, not posted |
| Orders in the ERP | Two orders for one sale | One order |
| Sales and tax | Counted twice | Counted once |
| Stock, if your books track it | Quantity deducted twice | Quantity deducted once |
What you see in Zid and in the ERP
In your ERP you see one order for each Zid order, with the customer, items, tax and shipping.
Once the document is created in your ERP, its number is written as a comment on the Zid order. The ERP document number appears as a comment on the Zid order with every system, so you can go from the order in Zid to its matching document in the ERP.
Updating the order status in Zid is available with Dynamics 365 Finance and Operations, and is switched on during setup. When Dynamics 365 Finance and Operations shows the order as “Invoiced”, the Zid order moves to the status chosen during setup.
Questions merchants ask
If the order notice arrives more than once
The app checks before it posts. On the first notice the order is not in the ERP yet, so it is posted. On the second notice it is already there, so it is not posted again.
A sync failed
If an order fails to sync, the assistant in the app can retry it once you approve. The retry does not create a duplicate order in the ERP, because the app checks before every post.
A return after the order was posted
Returns have their own path. With Odoo, ERPNext and Wafeq, a return posts to the ERP as a credit note, and the rule is one credit note per return. Returns are not supported on Dynamics 365 Finance and Operations or on a custom system connected through a public API.
A customer who has ordered before
With Odoo, ERPNext and Wafeq, the app looks the customer up in your ERP before the order is posted. If they already have a record, the new order is linked to it, and if not, a new record is created, so the same customer does not get a new record with every order. With Dynamics 365 Finance and Operations, orders post under one customer account chosen during setup.
Our record
These figures come from Zid Integrations data.
- lost orders
- Zero
- orders delivered to ERPs
- Over 14,000
Systems and plans
The app works with Odoo 18 and 19, Microsoft Dynamics 365 Finance and Operations, ERPNext, Wafeq, and any system with a public API. Our team does the setup with you, the connection is tested on your store’s orders, and you go live after a test report you approve, in about two weeks.
Posting orders to your ERP, and returns with Odoo, ERPNext and Wafeq, starts on the Starter plan, which covers 100 orders a month. Details and prices for each plan are on the app’s page in the Zid App Market.
To run the check-before-posting on your own store’s orders, install the app from the Zid App Market.
