A B2B dealer portal is only useful as long as it shows the same information as your ERP. If stock or prices in the portal differ from the ERP, dealers order the wrong thing and the sales team is back on the phone fixing it. This guide sums up the decisions you need to make when connecting the ERP to the portal.
The ground rule: the ERP is the single source of truth
Product records, stock, price lists, customer accounts and invoices live in the ERP; the portal displays them. The only record born in the portal is the order itself, and that is passed on to the ERP. Updating the same information by hand in two places leads, sooner or later, to two different truths.
Which data flows which way?
From the ERP to the portal:
- Products: stock code, name, brand, OEM and cross-reference codes, unit, VAT rate
- Stock quantities (or just "in stock / out of stock")
- Price lists, dealer group discounts, promotions, exchange rates
- Customers: dealer code, company name, addresses, dealer group
- Account balance, statement entries and invoices
From the portal to the ERP:
- Orders: dealer code, lines (stock code, quantity, price), delivery address, note
Feedback: if the order's approval in the ERP and the shipped and cancelled lines are written back to the portal, dealers stop calling to ask where their order is.
Method: files or API?
- File transfer (Excel, CSV, JSON): the easiest way to start. A list is exported from the ERP and uploaded to the portal. The drawback is that freshness depends on whoever uploads the file; it suits the initial setup and bulk corrections.
- API connection: the ERP, or a small transfer program in between, sends data to the portal's API at regular intervals and fetches new orders. This is the lasting solution. A public API reference matters, so that your own developers or your ERP partner can write the connection.
- Ready-made connector: some ERP partners offer ready modules for specific portals. If one exists it is the fastest route; if not, the API is enough.
How often to sync?
- Stock: every few minutes for fast movers; sending only changed items is lighter than sending the whole list.
- Prices and discounts: when they change, or once a day.
- Account balance and statement: once or a few times a day.
- Orders: as often as possible; dealers want to see quickly that their order has reached the ERP.
Code matching
Most of an integration is making codes identical on both sides:
- A product should be identified by its ERP stock code; the portal should not invent its own.
- A dealer should match their ERP customer code.
- OEM and cross-reference codes should be kept in separate fields, and search should ignore spaces, dashes and dots in them.
Error handling
In a transfer of thousands of items, a few faulty lines are normal (a missing field, an unknown brand, a negative price). A good integration does not reject the whole batch because of them: it accepts the valid lines and reports the faulty ones with a reason. Better that these reports land in front of someone than vanish silently.
Security
- Connections should use HTTPS only.
- Each integration should have its own API key, which can be revoked and replaced when needed.
- Where possible, the key should be accepted only from your own server's IP address.
- There should be a request limit, so that a badly written loop can't slow the portal down.
Getting started
- List the fields your ERP can export and its API options.
- Fill the portal from a file first and check that codes match.
- Then set up regular syncing for stock and prices, and after that the order transfer.
- In the first weeks, compare the portal and the ERP on a few sample products and dealers.
The guide about the portal itself: What is a B2B dealer ordering portal?. To see a portal with sample data, explore the live demo.