Short answer: a B2B distributor portal connected to an ERP should treat the ERP as a governed operational source, not as a remote database that every screen queries directly. The portal needs a clear account model, explicit ownership for pricing and stock, safe order submission, idempotent integrations and a degraded mode for the moments when internal systems are slow or unavailable.
Distributor portals are deceptively complex. The visible interface may look like catalogue, search, basket and account pages, but underneath sit customer hierarchies, price agreements, credit rules, multiple delivery sites, historic orders and product data. Architecture determines whether that complexity becomes useful self-service or a fragile collection of exceptions.
The ERP often already contains the legal or commercial customer record. The portal adds digital users. Define how one maps to the other. A single company may have multiple buyer logins, several bill-to or ship-to entities, branches and permission levels.
Use stable ERP customer identifiers rather than treating an email address as the account key. People change; commercial accounts persist.
The identity layer should answer who the user is and how they authenticate. The account layer should answer which company, branches, permissions and commercial conditions the user can access. Keeping these concepts separate makes SSO, user changes and multi-company access easier to manage.
Distributor pricing may depend on account, group, product family, quantity, date, promotion and market. Decide whether the ERP calculates the price on demand or whether relevant price data is synchronised to the portal.
Direct calculation provides freshness but increases dependency and latency. Synchronisation improves portal independence but requires rules for updates and conflict. Hybrid models are common: base conditions synchronise while exceptional calculations are requested.
Ask what the customer actually needs to know. Exact units? Availability by warehouse? Lead time? Expected date? A traffic-light state? Do not build a high-cost real-time integration if the commercial promise is only approximate availability.
Conversely, do not show “in stock” from a six-hour cache if buyers rely on the portal for same-day ordering. Data freshness is a product decision.
Network retries happen. Users double-click. Queues retry. An integration should be able to receive the same logical order twice without creating duplicate ERP orders.
Assign a unique external order key, store submission state and make ERP creation idempotent where possible. Payment callbacks and order status updates need the same discipline.
A portal order may move through draft, submitted, accepted, rejected, processing, shipped and completed states. The ERP may use different status codes. Map them explicitly rather than displaying raw internal values.
The customer needs meaningful state. Operations needs traceability between portal state and ERP state.
If the portal only shows orders created through the portal, a customer sees an incomplete relationship. Pulling or synchronising ERP order history creates a single place to reorder, retrieve documents and track activity regardless of how the original order was entered.
Some customers require one user to prepare and another to approve. Others use spending thresholds or cost centres. These workflows should be configurable at account level instead of hard-coded for one customer.
Approval events also need notifications and audit history so a delayed order can be explained.
The ERP may hold credit limit, overdue balance, payment terms and blocks. Decide which information should be visible and to which user roles. Sometimes a simple “account on hold — contact finance” state is safer and clearer than exposing detailed finance data.
Invoices, delivery notes, certificates, product documentation and return forms are frequent reasons customers contact distributors. Connecting documents to orders and products can remove a large amount of routine service work.
Protect account documents through authorised delivery. A private URL should not become public simply because the user copied it.
ERPs are excellent operational systems but often poor places for enriched product content. A PIM can own descriptions, attributes, taxonomies, media links and translations while ERP owns commercial and stock data.
The portal combines them. CODE Industrial’s B2B product catalogue development approach separates these responsibilities so product experience can improve without destabilising operations.
Do not rely on silent scheduled jobs. Track the last successful synchronisation, pending records, failed records and error reason. Operators should be able to find one customer, product or order without searching raw server logs.
Correlation IDs help trace the same transaction across portal, integration service and ERP.
Catalogue updates, document processing and some order operations can run asynchronously. Queues absorb peaks and allow controlled retries. The user experience should expose a meaningful status rather than pretending an asynchronous operation completed instantly.
A distributor portal should have a defined degraded mode. Public catalogue pages may remain available. Logged-in users may still access cached history and documents. New ordering may be paused or held in a queue depending on risk.
The correct behaviour is business-specific, but “the whole website returns an error” should not be the default architecture.
The portal should not connect with an all-powerful ERP account. Use scoped service credentials, network controls, secret rotation and logging. Protect customer-specific pricing and account data at API level as well as in the interface.
Create automated tests for representative account types: standard customer, contract-price customer, blocked account, multi-branch customer, approval customer and administrator. Portal projects become risky when commercial rules can only be validated manually.
Measure account activation, repeat use, quick-order adoption, zero-result searches, document downloads, abandoned quotations and self-service operations. This tells the business whether the portal is replacing friction rather than merely adding visits.
Sales teams can also use account signals appropriately: repeated searches for a product family or configuration activity can indicate emerging demand.
Keep useful product and application information public where commercial policy allows. Private pricing and account stock do not require the entire catalogue to be hidden. Public structure helps prospects discover the distributor and helps AI systems understand products, sectors and capabilities.
Phase one often focuses on identity, accounts, personalised catalogue/pricing, order capture, history and documents. Phase two may add approvals, advanced quick order, returns, service workflows or deeper personalisation. Later phases can integrate CRM signals or regional distributor structures.
CODE Industrial’s B2B distributor portal development work starts with the operational model and integration boundaries before interface detail.
Not for every data type. The right frequency depends on the customer promise. Some prices or credit states may need high freshness while product enrichment can update less frequently.
Potentially, if the business can safely queue them and the customer receives a clear pending status. Some organisations prefer to disable submission during outages.
No. A PIM or CMS can own enriched technical and editorial content while ERP remains the source for commercial and operational data.
Ambiguous ownership and silent failure. If teams cannot say which system owns a field or identify failed synchronisations quickly, the portal becomes difficult to trust and operate.
Integration design should identify who is allowed to correct customer, product and pricing data when something is wrong. If portal teams patch values locally while ERP teams patch the source, the systems diverge. Create a simple ownership matrix and a correction workflow. For every high-value field, operators should know the source, owner, expected update frequency and escalation route. This governance work is less visible than interface design, but it determines whether customers continue to trust the portal months after launch.
Before launch, test representative distributor accounts against the real ERP rules. Contract pricing, credit status, stock visibility, delivery locations and order history should reconcile correctly for edge cases as well as for the standard customer journey.