B2B eCommerce development in Baku should solve a very specific operational problem: letting business customers place repeat orders under the commercial and control rules that already govern the relationship. For distributors, wholesalers and manufacturers, that means more than publishing products and adding a cart. The platform must know which company is buying, which people can act for that company, what they may buy, at what price, on which terms, and whether the order can proceed.
In most cases, the B2B platform should not replace the ERP. The ERP remains the system of record for products, customer accounts, contractual pricing, credit, sales orders, invoices and fulfilment. The eCommerce layer makes the approved parts of that information usable by customers without turning every routine purchase into an email, phone call or spreadsheet task.
A B2B ordering platform is not a consumer storefront
A public B2C store can often display one catalogue, one price and a limited set of delivery rules. B2B commerce is account-aware. The same SKU may be visible to one customer but unavailable to another. Its price may depend on a sales agreement, customer group, quantity break, business unit, delivery location or currency. A buyer may be able to build a cart but not submit it without approval from a manager.
That makes the core transaction a policy decision, not merely a checkout flow. For every order line, the platform should be able to establish:
- the legal customer account and branch on whose behalf the user is acting;
- whether that account is entitled to see and buy the item;
- the applicable price, discount, unit of measure, tax and delivery terms;
- whether available-to-promise stock can support the requested quantity and date;
- whether credit status permits release, requires review or blocks submission; and
- whether the order needs internal customer approval, seller review or direct ERP creation.
This is why a wholesale ordering system needs explicit domain modelling for accounts, entitlements, order states and exceptions. Treating those rules as scattered front-end conditions produces inconsistent orders and difficult-to-audit manual work.
The capabilities that distinguish serious B2B commerce
Company accounts, branches and purchasing roles
A customer organisation may have multiple purchasers, approvers, cost centres, delivery sites and legal entities. A useful design separates the individual identity from the commercial account and gives each person a bounded set of capabilities. A buyer might create and amend a draft; an approver might release orders above a threshold; a finance user might see invoices but not submit orders; a local administrator might add users for one branch only.
Permissions must be enforced by the server for every resource and action, not just represented by hidden navigation. A user who alters an order ID in a URL or API request must not gain access to another company’s price, document or history. Least-privilege and default-deny controls are particularly important because customer-specific commercial data is exactly the type of data that can be exposed by weak object-level authorization. A platform built through POLADO Web Platforms & Applications should include this access model from the discovery stage, while UI/UX & Product Design can make dense purchasing roles understandable in everyday use.
Customer-specific catalogues and contract pricing
A customer-specific pricing portal should not assume a single stored price per product. Commercial pricing may originate from a contract, trade agreement, account affiliation, price list, quantity tier, campaign, product variant, pack size or delivery condition. The customer needs a clear result, but the operation also needs traceability: was the displayed amount a contract price, a volume price, a provisional estimate, or a price requiring commercial review?
A sound design keeps the pricing authority close to the relevant commercial system. The portal can call an ERP pricing service in real time, read from a controlled synchronised price projection, or use a hybrid approach. In all cases, the ERP or pricing authority should validate the final order before it becomes a confirmed commercial commitment. Do not reproduce complex pricing formulae independently in browser code and assume the result will remain correct after contracts or master data change.
Product visibility follows the same principle. The catalogue should be filtered before the user searches or adds items, based on account eligibility, product status, territory, assortment and business rules. If substitutions are allowed, show them as governed alternatives rather than silently replacing a requested product.
Approval orders need a state model, not a notification email
Approval order workflow development means defining controlled states and transitions. A robust order might move through Draft, Submitted, Customer Approval Pending, Seller Review, Credit Hold, Accepted by ERP, Partially Accepted, Rejected, Cancelled and Fulfilled. Each transition needs a clear actor, trigger, permission check and audit record.
Consider a buyer who submits a high-value order above the company’s approval limit. If an approver later changes quantity, address or delivery date, the platform must decide whether the approval remains valid. That rule should be explicit. It may return the order to approval, allow changes within a defined tolerance, or require seller review. Record who acted, when they acted, the previous and new status, the reason and the affected lines. This is far more reliable than treating email replies as the system of record.
Credit status, availability and delivery logic
“In stock” is rarely a sufficient B2B answer. Buyers may need to know whether stock is sellable, reserved, available from a specific warehouse, subject to allocation, or expected on a future date. The platform must also state what it can honestly promise. If stock is cached, label the update behaviour and perform the necessary final validation before acceptance.
Credit is similarly nuanced. You may choose not to expose a credit limit or balance to every buyer, but the buyer should receive an unambiguous operational outcome: the order can proceed, it is awaiting review, or the account needs contact with finance. Delivery choices also require rules beyond a postcode: route schedules, minimum order values, warehouse coverage, hazardous-material constraints, temperature handling, cut-off times and contractual freight terms can all determine the valid options.
How to build an ERP-integrated B2B ordering platform
Start by assigning ownership for every important datum. A typical split is:
- ERP: product master data, customer accounts, commercial agreements, inventory, credit, official sales orders, invoices and fulfilment status.
- B2B platform: user identities, account-to-user relationships, saved carts, shopping lists, approval routing, customer experience and notifications.
- Integration layer: API translation, authentication, queuing, retry handling, idempotency, observability and reconciliation.
Then decide where live calls are necessary. Product images and descriptions usually tolerate synchronisation. Availability, credit and final price may require a current response, depending on the business risk. A hybrid pattern is often practical: synchronise browsing data for fast search, then validate commercial and fulfilment-critical details at cart or submission time.
Order submission needs special care. Give each portal order a durable external reference and make the ERP create operation idempotent. If a customer clicks twice, retries after a timeout, or loses their connection after the ERP has accepted the order, the result must be one ERP order, not two. Store both the portal reference and ERP document number, track each transmission attempt, and provide an operations path for reconciliation rather than a risky generic “submit again” button. This integration discipline complements the approach described in Technical Support & Consulting, especially where release safety, monitoring and incident response matter.
Design exceptions as first-class workflows
The highest-value operational design work is often in the cases that do not complete automatically: missing contract price, blocked account, unavailable quantity, discontinued item, invalid delivery site, partial acceptance, substitution request or temporarily unavailable ERP service. These should create visible, owned work rather than opaque technical failures.
For example, an item without an applicable price can become a commercial-review request; a credit issue can enter a finance queue; an ERP outage can leave the order in “received, processing pending” rather than falsely confirmed; a partially accepted order can show accepted, backordered and rejected quantities separately. Internal teams need queues with reason codes, ownership, timestamps and safe actions—not another inbox of unstructured messages.
Should you add a commerce layer, extend a portal or build a purpose-built platform?
- Add an eCommerce layer over the ERP when repeat ordering, account catalogues, contract prices and order visibility are the central need, the ERP exposes viable interfaces, and the commercial process is broadly standard.
- Extend an existing customer portal when customers already use it for documents, service requests or account interactions and ordering naturally belongs in the same authenticated experience.
- Build a purpose-built operational platform when multi-entity trading relationships, non-standard allocations, complex approval matrices, field-sales-assisted orders, specialised distribution rules or cross-system exception handling are central to how the business operates.
Decision checklist before funding development
- Which ERP, WMS, CRM and finance systems own the data needed for an order?
- Where are account hierarchy, user roles, approval limits and delivery addresses maintained?
- What is the acceptable delay for catalogue, price and availability updates?
- Which order conditions demand human approval or commercial review?
- How will amendments, partial fulfilment, substitutions, cancellations and returns be represented?
- What happens if the ERP accepts an order but the portal does not receive the response?
- Which customer data must be hidden from buyers, branch users and other legal entities?
- Which operational team owns each exception, and what evidence must be retained?
The right B2B platform does not remove sales and operations teams. It removes repetitive re-entry, routine status chasing and avoidable pricing questions so those teams can concentrate on exceptions and customer relationships. If your organisation is ready to turn email-and-spreadsheet ordering into a controlled digital channel without replacing the ERP, POLADO can help map the process, define the integration boundary and deliver a phased B2B ordering platform.