Magento & Adobe Commerce Connector

Enterprise B2B storefronts fail on pricing before they fail on anything else. A buyer logs in, sees a price the storefront calculated from a customer group and a tier table, places the order, and then receives an invoice priced from a trade agreement in the ERP that nobody synchronised. The credit controller finds out later that the order should never have been accepted because the account was already over its limit. None of that is exotic. It is the predictable result of two systems holding two independent opinions about what a customer pays and what they are allowed to buy.

A generic middleware map struggles here because the two models genuinely differ. On the storefront side there are websites, stores and store views, customer groups, tier prices, catalogue price rules, shared catalogues, company accounts with hierarchies, requisition lists and negotiable quotes. On the Dynamics 365 Finance and Operations side there are customer groups, price groups and discount groups, trade agreements in PriceDiscTable, sales agreements, credit limits and credit management holds, multiple sites and warehouses, sales tax groups and item sales tax groups. Flattening one onto the other loses exactly the information the B2B business depends on.

ECOSIRE builds a connector shaped around that reality, as a Finance and Operations extension model in X++ with no overlayering, deployed through your normal pipeline.

What ECOSIRE builds

### Catalogue and product data Released products, product masters with their variant dimensions, attributes and category hierarchy are published from Finance and Operations to the storefront through its REST and async bulk endpoints, with the category mapping agreed during scoping rather than assumed. Unit of measure conversions travel with the product so a case, a pallet and an each are not three unrelated listings. Publishing is scoped per website and store view, so a product can exist for one storefront and not another without maintaining two catalogues by hand.

### Pricing that does not diverge This is the part that earns the build. Prices and discounts are resolved on the ERP side from trade agreements and sales agreements, then projected onto the storefront model as customer group prices, tier prices or shared catalogue entries depending on which structure your storefront uses. Where a customer has genuinely bespoke pricing that cannot be expressed as a group, the connector can call back to Finance and Operations for a live price at cart or quote time instead of publishing a table that would be wrong. We agree during scoping which of those two modes each price type uses, and why, so nobody is guessing later.

### Customers, companies and credit Storefront customers and company accounts map to CustTable records with the correct customer group, price group, payment terms and delivery terms, and the hierarchy in a company account is preserved rather than collapsed to one billing entity. Credit limit and credit management status flow outward, so an account on hold can be blocked at checkout or routed to a quote instead of silently generating an order the ERP will reject. New customer registrations create prospects for review rather than creating live customer accounts unattended, unless you explicitly want the opposite.

### Orders, inventory and fulfilment Storefront orders create sales orders with the storefront order identifier, website and store view stamped on SalesTable, lines mapped to released products, tax handled through your sales tax groups, and delivery mode mapped to your DlvMode setup. Available quantity is published from InventSum for the sites and warehouses you nominate, mapped onto the storefront source and stock model where multi-source inventory is in use. Packing slips and invoices flow back as shipments, invoices and credit memos, including partial shipments, so the buyer sees the same document trail your finance team sees.

### Returns, payments and reconciliation Return requests raised on the storefront create return orders in Finance and Operations for disposition, and credit memos are generated from the posted credit note rather than being keyed twice. Payments captured by the storefront are imported into a customer payment journal for settlement against the invoices they cover, with a working list of anything that does not match. Where you operate on account rather than card, the invoice remains the financial event and the storefront simply reflects it.

### Operations, throughput and monitoring All traffic runs on the batch framework with dedicated jobs per flow, so a slow catalogue publish cannot delay order intake. High-volume operations use the storefront async bulk endpoints and are chunked with retries and a parked queue. Every message has a correlation identifier, an inbound and outbound payload record, and a status, exposed as data entities over OData for Power BI or a Power Platform monitoring app, with business events for alerting through Power Automate.

Who this is for

This is for organisations running a serious B2B or hybrid storefront in front of Finance and Operations, where pricing is contractual rather than a single list, where credit terms matter, and where the cost of a wrong price is an argument with a customer rather than a rounding difference. It suits multi-store and multi-legal-entity setups, where one storefront estate serves several selling entities and each has its own tax, terms and warehouses. It suits teams currently maintaining a spreadsheet-driven price upload and knowing that it is one busy week away from being wrong.

It is a poor fit for a simple direct-to-consumer store with one price list and card payment only, where a lightweight integration would do the job for less money.

How delivery works

Everything is built to order. There is no instant download and no trial, because the connector is written for your two systems after we understand them.

1. Scoping call. We map your storefront structure, customer group and catalogue model, how prices are actually decided, credit rules, the legal entities, sites and warehouses in scope, your tax setup, and your platform and application version on both sides. 2. Fixed quote. A written scope and a fixed price, agreed before development starts. Work discovered outside that scope is quoted separately rather than absorbed. 3. Build. We develop the extension model against your version, integrating with a storefront environment you provide, and test against representative customers, price structures and orders from your data. 4. Install in test, then production. The package deploys to your sandbox through your LCS pipeline and connects to your storefront staging environment, where your team runs the documented test pack including price parity checks across a sample of customers. Production follows on your change window after sign-off. 5. Support. An agreed support window after go-live covering defects in what we built, with a documented escalation route.

Typical lead time from signed quote to a package ready for your sandbox is two to four weeks, driven mainly by how many pricing structures need to be represented faithfully.

What this is not

We build and support the integration layer. We do not maintain your storefront, write storefront theme code, or take responsibility for extensions on that side that alter pricing after our data lands. Where a storefront-side module is needed to expose or consume something, we specify exactly what it must do and work with whoever maintains that platform for you. We claim no certification or partnership with any platform vendor; this is an independent build against published APIs, delivered with its source code.