The problem this solves
In many manufacturing and distribution businesses, orders still arrive through a mix of phone calls, messaging apps, emailed spreadsheets and visits by sales staff. Someone in the back office re-keys each one into the ERP, checks the price list and the customer’s credit, and replies with confirmation. Errors creep in, distributors wait for answers, and management sees the order book only after the fact.
This blueprint shows how Twara Technologies would design a self-service B2B portal that lets channel partners order directly against the company’s own rules, while the ERP remains the system of record for stock, pricing and finance. It is a reference design; a typical implementation adapts the account model, pricing logic and integrations to the client’s actual sales network.
Architecture
The portal is a layer of experience and business rules in front of the ERP, not a replacement for it.
[Distributor web portal] [Field sales app] [Admin console]
\ | /
+-------- [API gateway + auth] --------+
|
[Order service] [Pricing service] [Catalogue service] [Account service]
|
[Message queue / outbox]
|
[ERP integration adapters] <--> [ERP: stock, prices, invoices, credit]
|
[Search index] [Reporting store] [Notification service]- Partners and sales staff use a responsive web portal or a mobile app, both served by the same APIs.
- Domain services handle catalogue, pricing, orders and accounts. Each owns its data and rules.
- The integration layer pulls master data (products, prices, stock, credit balances) from the ERP on a schedule or by event, and pushes confirmed orders back. A queue with an outbox pattern ensures an order is never lost if the ERP is briefly unavailable.
- A search index gives fast, typo-tolerant product search across large catalogues.
- Notifications confirm orders, dispatches and invoices by email, SMS or messaging channels the client already uses.
Key design decisions
Build, buy or compose. Commerce platforms with B2B features (for example Adobe Commerce, Salesforce B2B Commerce or SAP Commerce Cloud) provide much of the catalogue and cart out of the box but can be costly to license and awkward to bend to local scheme structures. Open-source frameworks such as Medusa or Saleor, or a custom build on a mainstream stack (React or Next.js with a Node.js, Java or .NET back end), give more control. The blueprint favours a custom or composable approach when pricing and scheme logic is the main differentiator, and a packaged platform when standard B2B features suffice.
Where pricing is calculated. Calculating price in the ERP for every cart change guarantees accuracy but can be slow. Replicating price rules into the portal is fast but risks drift. The design caches ERP price lists and scheme rules, calculates in the portal for browsing and the cart, and revalidates against the ERP at checkout.
Synchronous or asynchronous ERP calls. Real-time calls for stock and credit give the freshest answer but tie portal availability to the ERP’s. The blueprint uses asynchronous order submission with clear status messaging (“received”, “confirmed”, “dispatched”) and limits synchronous calls to the few checks that genuinely need them.
Integration method. SAP, Oracle, Microsoft Dynamics and Tally-based environments each expose data differently: APIs, middleware, file exchange or database views. The adapter layer isolates these differences so the rest of the portal does not change if the ERP does.
Offline in the field. Sales representatives often work in areas with poor connectivity. The field app stores catalogue and account data locally and queues orders for sync, with conflict rules for prices that changed while offline.
Security and compliance
The most serious risk in a multi-account portal is one partner seeing another’s prices, orders or statements. Broken access control sits at the top of the OWASP Top 10:2025 (A01:2025), and the design treats authorisation as a first-class concern: every API call is checked against the caller’s account and role on the server, never by hiding links in the interface, and automated tests attempt cross-account access on each release.
Other measures in the blueprint:
- single sign-on for staff, and strong authentication with optional multi-factor for partner users;
- approval limits and segregation of duties for credit overrides and price exceptions;
- full audit history of orders, approvals and price changes;
- dependency and supply-chain checks in the build pipeline, reflecting A03:2025 in the same list.
Contact details of partner staff and retailers are personal data under India’s Digital Personal Data Protection Act, 2023. Rule 6 of the DPDP Rules, 2025 lists the minimum safeguards, including access control, logging and monitoring of access to personal data, and backups, and the blueprint’s logging and retention settings are designed around them. Where the portal is hosted in India by a body corporate, CERT-In’s Directions of 28 April 2022 on incident reporting and log retention also apply. Client counsel should confirm the final position.
Phased rollout
- Discovery. Map the sales network, order channels, pricing and scheme rules, credit policy and ERP interfaces. Identify a small group of willing pilot partners.
- Core portal. Catalogue, account-specific pricing, cart and order submission to the ERP, with order status and invoice download.
- Pilot and refine. Run with pilot partners alongside existing channels, compare portal orders with ERP records, and adjust pricing and usability issues.
- Scale. Onboard the wider network in waves, add the field sales app, credit workflows and scheme management.
- Extend. Add analytics, recommendations based on order history, payment collection and further integrations, supported under an ongoing maintenance arrangement.
Risks and how the design handles them
| Risk | How the design responds |
|---|---|
| Partners keep ordering by phone | Quick-order and reorder features built for repeat buyers, field app for staff-assisted orders, and onboarding in waves |
| Portal prices differ from ERP prices | Cached rules with revalidation at checkout and reconciliation reports |
| ERP downtime blocks ordering | Queued submission with clear status, so orders are accepted and processed when the ERP returns |
| Cross-account data exposure | Server-side authorisation on every request and automated cross-tenant tests |
| Scheme logic becomes unmanageable | Rules held as configuration with an admin console and test cases, not hard-coded |
| ERP replacement later | Adapter layer isolates ERP specifics from the rest of the platform |