BigCommerce Connector

The problem

A BigCommerce storefront and a Dynamics 365 Finance & Operations deployment usually meet in a spreadsheet. Someone exports orders each morning, pastes them into a sales order import template, and hopes the customer account already exists. Item availability on the storefront reflects last night's snapshot, so oversells happen on fast-moving SKUs. B2B price lists — the whole reason the storefront was chosen — are maintained twice: once as trade agreements in F&O and once as customer-group price lists in BigCommerce, and they drift within weeks. Finance then reconciles storefront settlement totals against posted invoices by hand.

None of this is a BigCommerce problem or an F&O problem. It is an absence of a durable, restartable integration that understands both object models.

What ECOSIRE builds

We build a dedicated integration model for F&O, delivered as X++ extensions only — no overlayering, no changes to Microsoft's application code. Everything lands in your own package so it survives platform updates and can be deployed through your normal LCS pipeline.

Outbound: catalog and inventory

Released products, product variants, dimension groups and unit conversions are projected to BigCommerce products and variant options. We map product master data to a staging table in the integration model, so you decide precisely which released products publish — by item group, product lifecycle state, retail channel category or a custom flag on InventTable. On-hand quantities are read from the InventSum-backed availability query for a nominated set of warehouses and sites, then pushed as inventory levels. A batch job runs the delta on a schedule you choose; a separate full-refresh job exists for reconciliation.

Outbound: pricing and B2B price lists

This is where most storefront integrations stop and where B2B sellers need the most. Sales price and discount trade agreements (PriceDiscTable) are evaluated per customer price group and projected into BigCommerce price lists and price list assignments. Customer-specific pricing, quantity breaks and currency-specific agreements are all handled, with an explicit rounding and tax-inclusive/exclusive decision made during scoping so storefront display matches what the sales order will actually post.

Inbound: customers and orders

Storefront customers are matched to F&O customer accounts by an external identifier stored on the customer record, with a documented rule for creating new accounts from a customer template — customer group, payment terms, delivery mode, sales tax group and default dimensions all set deterministically. Orders arrive as sales orders through a data entity, with storefront order numbers retained for traceability, freight and handling charges mapped to misc. charge codes, and discounts mapped to line discount or charge lines as agreed. Tax is either recalculated in F&O from the customer's tax group or accepted from the storefront and reconciled — we implement whichever your finance team signs off on, not a hidden default.

Outbound: fulfilment and financials

Packing slip posting raises a shipment update to BigCommerce with tracking numbers and carrier, so the storefront sends its own shipping notification. Invoice posting can push the invoice reference and settlement status. Where you use advanced warehouse management, shipments confirmed on the warehouse mobile app flow through the same event path, so a mobile-driven pick and ship reaches the customer's order status without anyone touching a desk.

How it runs

All traffic is queued. Inbound and outbound messages land in integration tables with a status, an attempt count, a payload snapshot and the last error. A batch job processes each queue under the F&O batch framework, with configurable batch groups so you can pin the work to a dedicated AOS. Failures are retried with backoff and, past a threshold, parked for a human — they never silently disappear. An operations form lists every message with filters by status, entity and date, and lets an administrator requeue a single record or a selection.

Authentication, endpoints, mapping tables and job cadence are configured in a parameters form per legal entity, so a multi-company deployment can run several storefronts side by side without code changes. Where your architecture calls for it, we expose the same data through OData on custom data entities, or route events through Power Platform instead of direct calls — that decision is made in scoping based on your existing integration estate.

Who it is for

Manufacturers and distributors running F&O who sell to trade customers through a BigCommerce storefront and maintain real negotiated pricing. Retailers with a mixed B2B and B2C footprint who need one inventory truth across both. Groups running several legal entities where each entity has its own storefront, currency and tax profile.

It is not aimed at organisations with a single tiny catalog and no pricing complexity — the value here is in the trade agreement and multi-entity handling.

How delivery works

1. Scoping call. We walk through your BigCommerce configuration, your F&O version and deployment topology, the entities you need in scope, your tax and pricing rules, and your warehouse setup. You get a written scope document listing every mapping and every decision.

2. Fixed quote. Based on that scope, a fixed price and a delivery date. The listed price is the starting point for a standard build; anything beyond the documented scope is quoted separately before we start it.

3. Build. We develop in our own environment against your version, in a dedicated model with its own package, following your naming conventions if you have them.

4. Install in test. We deliver a deployable package to your LCS project or hand it to your DevOps pipeline, install into your sandbox, configure it with you, and run through the agreed test cases with your data. Nothing goes near production until you have signed off on the sandbox.

5. Production. The same package promotes through your normal release process, with a cutover plan covering initial catalog publish, the first inventory sync and the point at which manual order entry stops.

6. Support. A defect-fix window follows go-live, covering anything that does not behave as the signed-off scope describes.

Lead time for a standard build is two to four weeks from the point the scope is agreed and we have access to a sandbox.