B2B dealer portal: where the ERP integration actually breaks

Dealer portal projects usually start with the screens: product list, basket, order history. That part takes a fortnight and demos well.

The project breaks at the line where the order is written into the ERP. If the answers to the following four questions are wrong, the portal keeps working and quietly loses the trust of the people using it:

1. Where did the price shown to the dealer come from?
2. When it says "in stock", which stock does it mean?
3. What happened to the order when the dealer exceeded their limit?
4. How many orders were created when the dealer pressed the button twice?

This article is about those four lines, and about the API limits that decide how the rest of the system has to be built.

1. Price is read from the ERP, never calculated in the portal

A dealer price is rarely a single list. Sitting on top of it are customer-specific prices, discount tiers, volume breaks, campaigns and payment-term adjustments. All of those are defined in the ERP, and all of them change in the ERP.

When the portal copies that logic, the failure is predictable: the sales manager updates a discount tier, the portal knows nothing about it and carries on selling at the old price. The difference surfaces after the invoices are issued, and someone has to decide whether to honour it or claw it back.

The rule: price is read from the ERP, at the moment of ordering, for that specific customer. If the portal caches prices for performance, the cache is short-lived and the figure is re-validated immediately before the order is written.

2. Stock means free stock

The second classic mistake is showing the physical warehouse quantity as "in stock".

A portal showing physical stock promises the same 40 units to three different dealers. All three place an order, two receive short shipments, and the telephone calls arrive at the sales desk — the exact problem the portal was bought to remove.

The free-stock calculation belongs in the ERP. A portal that keeps its own reservation table creates a second version of the truth, and the two stop agreeing within weeks.

3. Credit limit is checked before the write, not after

The dealer's open balance and credit limit live in the ERP. The portal reads both before writing the order and produces one of three outcomes:

• Within limit — the order is written normally.
• Over limit — the order is accepted but held for approval and routed to the account manager.
• Account blocked — the order is refused, with the reason stated plainly.

The middle case is the one most projects skip, choosing one of the two extremes instead: either the limit is never checked and finance finds out later, or the order is refused outright and the dealer goes back to telephoning. Accepting the order while making the shipment conditional on approval keeps both sides working.

4. Duplicate orders: de-duplicate on a document number

The dealer pressed the button, the connection dropped, nothing appeared on screen, so they pressed it again. How many orders exist?

Disabling the button in the interface does not answer this, because the first request has already left the browser. The only real fix is an idempotency key:

• The portal generates its own document number for every order, for example WEB-2026-000118.
• The order is written to the ERP carrying that number.
• A second request with the same number returns the status of the existing record instead of creating a new one.

That number also becomes the shared language of support calls: the dealer asks what happened to WEB-118, and the sales team searches the same number in the ERP.

Writing the order: what changes per ERP

The write path differs by system, but the principle does not: the record is created through the ERP's own business logic. Direct INSERT statements against the tables produce an order that appears in a list while stock is never decremented, cost is never calculated and no accounting entry is made.

SAP Business One

The Service Layer is SAP Business One's OData-based REST interface. It sits in front of the DI Core — the same business object layer the desktop client uses — so an order written through it runs the same validation as one keyed in by hand. Service Layer and the older DI API share their object definitions, which makes moving between them predictable.

Two version facts matter when you scope the work. From FP 2405, OData version 3 is deprecated and OData version 4 is the primary protocol supported by the Service Layer. Separately, SAP recommends Service Layer v2, as that is the version receiving new features, fixes and long-term support.

The Service Layer does not replace the DI API entirely: complex queries and certain transaction-handling and system-level operations still call for it. In practice a dealer portal writes orders through the Service Layer and reaches for the DI API only where a specific operation is not covered.

Dynamics 365 Business Central

Orders are written through API v2.0, by posting to the company's sales orders endpoint with the customer, order date and lines in the JSON payload. Where the standard endpoints do not expose a field you need, custom API pages are published in AL using the APIPublisher, APIGroup and APIVersion attributes; they appear as OData v4 endpoints alongside the standard ones. Batch requests let several operations travel in a single HTTP call.

The limits that decide the architecture

Business Central publishes hard limits, and a dealer portal is exactly the workload that meets them:

The consequence is a design rule rather than a tuning exercise: reference data is cached, only the order write goes live. The product catalogue, price lists and stock levels are pulled on a schedule and served from the portal's own store; the write path — order creation, credit check, status — talks to the ERP in real time. A portal that queries the ERP on every page view works fine in a demo with three dealers and throttles at two hundred.

The same reasoning applies to SAP Business One, where session handling and Service Layer capacity make per-view live queries equally unwise.

Surviving an outage: put a queue in the seam

Without a queue, orders placed during a maintenance window disappear silently — and the disappearance is only discovered when a dealer telephones to ask.

What stays in the ERP

The portal does not take everything over. These belong in the ERP and should stay there:

• Invoicing and statutory documents. They follow legislation, and the vendor updates them when the legislation changes. The portal reads the document status and number and displays them.
• Accounting and the customer ledger. The portal reads the balance; it does not author it.
• Costing. Because the order is created inside the ERP, the costing chain runs by itself.

For distributors selling across borders, the invoicing rules are the part most often underestimated — see e-invoicing in Saudi Arabia and the UAE and EU export compliance for manufacturers.

Why dealers are not given ERP logins

The commercial case usually arrives before the technical one: packaged ERPs are licensed per user.

Opening ERP sessions for fifty dealers means fifty additional users, and that charge repeats every year. A portal connects to the ERP through a single service account; whether there are five dealers or five hundred, the ERP licence does not change.

There is a second reason. An ERP session opens the door to company-wide data. A portal shows a dealer only their own account, and that boundary is enforced in the application rather than negotiated in ERP permissions.

Go live in three steps, not one

1. Read first. Dealers see their balance, statement and free stock. No ordering yet. This alone reduces telephone traffic and validates the field mapping.
2. Orders, in approval mode. Orders collect in the portal and the account manager approves each one before it is written to the ERP. Run the first week like this; mapping errors surface here rather than in the ledger.
3. Direct writes. The approval step is removed and orders go straight through. Over-limit orders continue to be held.

This splits the go-live risk into three. Portals opened in a single step spend their first week reversing orders taken at the wrong price.

One test before you go live

Run a single chain end to end: dealer places an order → sales order appears in the ERP → delivery note → invoice. Then read the figures from the ERP and compare them with what the portal displayed.

If there is a rounding difference, the cause is almost always discount sequencing or tax rounding, and it is far cheaper to find in test than in production.

Running a different system? The same seam on the other common mid-market platforms is covered in Odoo integration and Sage integration.

To scope a dealer portal on the ERP you already run, tell us about your process. The first call takes 30 minutes and costs nothing; you can see the bands on the pricing page beforehand, and the delivery side is described on the dealer portal page.

Frequently asked questions

What is a B2B dealer portal?

A web application where distributors and dealers see their own account balance, their own price list and current stock, then place orders themselves. The order is written into the ERP instead of arriving by phone or email. Dealers are not given ERP logins, so no per-user ERP licence is consumed; the portal connects with a single service account.

Should the portal calculate prices or read them from the ERP?

Read them from the ERP, at the moment of ordering, for that specific customer. Customer-specific prices, discount tiers, volume breaks, campaigns and payment-term adjustments are defined in the ERP and change there. When pricing logic is copied into the portal, the day someone updates a discount tier in the ERP the portal keeps selling at the old price, and the gap is only noticed after invoices are issued.

What stock figure should a dealer see?

Free stock, not physical stock: warehouse quantity minus what open orders have already reserved. Portals that display physical stock promise the same units to several dealers at once, and short shipments follow. The free-stock calculation belongs in the ERP; the portal should read it rather than keep its own reservation table, which would create a second version of the truth.

How do you handle a dealer ordering beyond their credit limit?

Check before the order is written. The portal reads the credit limit and open balance from the ERP. Within limit, the order is written normally. Over limit, the order is still accepted but held for approval and routed to the account manager. Blocked account, the order is refused with the reason shown. Rejecting outright pushes the dealer back to the telephone, which is the problem the portal was built to remove.

How is an order written into SAP Business One?

Through the Service Layer, SAP Business One's OData-based REST interface, which sits in front of the same DI Core business object layer the desktop client uses — so the order goes through the same business logic and validation. From FP 2405 onwards OData v3 is deprecated and OData v4 is the primary protocol, and SAP recommends Service Layer v2 as the version that receives new features and long-term support. The older DI API is still relevant for system-level operations and for cases the Service Layer does not cover, such as complex queries and certain transaction handling.

How is an order written into Dynamics 365 Business Central?

Through API v2.0, by posting to the sales orders endpoint for the company with the customer, order date and lines in the payload. Where the standard endpoints do not expose what you need, custom API pages are published in AL using the APIPublisher, APIGroup and APIVersion attributes, which surface as OData v4 endpoints alongside the standard ones.

Do Business Central API rate limits affect a dealer portal?

Yes, and they usually decide the architecture. The published limits are 6,000 OData requests per user per rolling five-minute window, a maximum of five requests processing concurrently, and 100 simultaneous connections per user; production environments are throttled at 600 requests per minute and sandboxes at 300. A portal that queries stock live on every product view will reach these figures with a few hundred active dealers, so reference data is cached and refreshed on a schedule while only the order write goes through live.

How do you stop the same order being written twice?

Give every order a document number generated by the portal and write it to the ERP with that number. If the connection drops and the client retries, the second request carrying the same number returns the status of the existing record instead of creating a new one. Disabling the button in the interface does not solve this, because the first request has already left the browser.

What happens to orders if the ERP is unavailable?

In a correctly built portal, nothing is lost. A queue sits between the portal and the ERP: while the ERP is down for maintenance or restart, orders accumulate and are processed in sequence once the connection returns, using the same document number for de-duplication. The dealer sees the order as received and being processed. Without a queue, orders placed during a restart disappear silently and are only discovered when someone telephones.