Designing Price, Credit Limit and Order Flow in a B2B Dealer Portal
How a dealer portal differs from a webshop
The difference is how price and payment behave. In retail e-commerce the price is the same for everyone and payment is taken at order time. In B2B the price varies by customer, channel and quantity, payment is usually on terms, and the order must pass a credit-limit check. A dealer portal is therefore not a catalogue but an externalised transaction surface of the ERP.
Write the pricing model down first
In practice the price is formed by applying layers in order: list price, customer group or channel discount, customer-specific agreed price, quantity tier, campaign or seasonal discount, and finally a term surcharge or early-payment discount. The critical question is whether these layers are applied sequentially or multiplied, because the same discount set can produce two different results. If the rule is not written, the portal and the ERP will produce different prices and invoice disputes follow. Calculating price in one place — preferably the ERP — and having the portal display it is the lowest-friction structure.
Credit limit and risk control
At order time the checks are: open account balance, overdue debt, collateral, the value of open but unshipped orders, and the status of dishonoured cheques or notes. Leaving pending orders out of the limit calculation is a common and costly mistake, because orders that exceed the dealer's limit then accumulate at the shipping stage.
Behaviour on limit breach should be one of three options, configurable per dealer: block the order, route it for approval, or accept it with a warning.
The ERP side of the order flow
Three outcomes are handled separately when the portal hands an order to the ERP. On success the ERP order number should be written back and shown to the dealer. On a transient failure the order stays in a "transferring" state and is retried, without leaving the dealer's screen ambiguous. On a permanent rejection the reason should be shown in language the dealer understands, and the record must not be lost. An operation key prevents a retry from creating a second order; see the [API integration guide](/en/blog/api-integration-guide).
The screens dealers actually use
Adoption is driven less by the order screen than by account statements and due-date tracking, shipment tracking, fast reordering from history, return and damage reporting, invoice and dispatch note viewing, and open quotation tracking. Without these, dealers keep phoning and the portal investment does not pay back.
Deciding on stock visibility
Showing the exact stock figure is not always right. A common approach is to show a status — available, limited, none — calculated after deducting allocated stock. If exact quantities are shown, a reservation mechanism is needed to prevent overselling under concurrent orders.
Frequently asked questions
Should price be calculated in the portal or the ERP?
In the ERP. The portal displays the calculated price and revalidates it at order time. Two pricing engines will eventually produce two answers.
How should dealer user permissions be structured?
At least two roles are needed inside each dealer: a user who can place orders and a user who can see financial information such as statements, limits and prices. A single-role design limits adoption because the dealer cannot delegate internally.
Does the portal need a mobile app?
Yes if a field team enters orders, and it is expected to work offline; that scenario is covered in the [mobile application guide](/en/blog/mobile-app-development-guide). For office-only use a responsive web interface is enough.