ERP-integrated dealer portal architecture: the portal must not replace the ERP
The most common mistake in dealer portal projects is letting the portal try to do the ERP’s job. Price calculation, stock deduction and ledger entries belong in the ERP. The portal is a transaction layer that shows this data correctly to dealers and pushes order intent back. Without that boundary you end up with two sources of truth, and six months later nobody knows which one is right.
Layers
- System of record (ERP): products, price lists, ledgers, stock, orders, invoices.
- Integration layer: translation, queueing and retry logic. A portal wired directly into the ERP goes down whenever the ERP slows down.
- Portal database: a read-optimised copy — catalogue, dealer prices, stock view, order drafts.
- Interface: separate permissions and views for dealers, sales reps and management.
Sync or async?
Not every field needs the same freshness:
| Data | Method | Freshness |
|---|---|---|
| Product catalogue | Scheduled sync | Daily |
| Dealer price list | Scheduled + change trigger | Hourly |
| Stock | Short-lived cache | 5–15 minutes |
| Balance / credit limit | Live query at checkout | Real time |
| Order submission | Queue + retry | Asynchronous |
Two mechanisms that decide success
Idempotency: the portal sends an order, the ERP is slow to answer, the portal retries — and the order lands twice. The only reliable fix is a unique key generated by the portal and checked by the ERP before processing.
Reconciliation: a nightly job must compare portal orders with ERP orders and report mismatches. It is the only way to catch an integration that has quietly broken.
Where should business rules run?
Pricing, discount and payment-term calculation stay in the ERP. But orderability rules can live in the portal: minimum pallet, truck fill rate, product group authorisation, routing to approval when the credit limit is exceeded. These change often and are expensive to change inside an ERP.
Audit trail
“Who did what, when?” is not a technical preference in enterprise projects — it is a requirement. Price changes, order approvals, limit overrides and permission changes must all be recorded with actor, timestamp and old/new value, and must not be deletable.
What to measure
Success is measured by the drop in phone and WhatsApp orders, order entry time, the number of corrections caused by wrong price, product or quantity, and the share of dealers actively ordering through the portal. Capture the baseline before the project starts — otherwise you cannot prove the improvement.