A build-to-order AL extension connecting OnBuy to Dynamics 365 Business Central — importing orders, pushing stock and prices, exporting listings, confirming shipments and posting settlement fees. ECOSIRE scopes, builds, installs and supports it for your tenant. Built to order by ECOSIRE for Dynamics 365 BC (build-to-order) — indicative price from $499.00 USD; request a quote for a scoped proposal.
Illustrative previewA build-to-order AL extension connecting OnBuy to Dynamics 365 Business Central
— importing orders, pushing stock and prices, exporting listings, confirming shipments and posting settlement fees.
ECOSIRE scopes, builds, installs and supports it for your tenant.
No DIY setup — a working app, built, installed and supported by ECOSIRE.
Start with a one-time build price. We scope it with you at kickoff.
ECOSIRE builds, configures and installs it on your Dynamics 365 Business Central.
You go live in about 2–4 weeks, with a post-launch support window.
Selling on OnBuy while running Dynamics 365 Business Central usually means two systems that never agree. Orders are rekeyed from the OnBuy seller dashboard into sales orders, so the ERP runs hours behind the marketplace and the same-day despatch cut-off is missed. Available inventory is maintained twice, so a line sold in the warehouse stays listed on OnBuy until someone remembers to adjust it — and an oversell on a marketplace is a metric that follows your account. At month end the OnBuy remittance arrives as a single bank line covering hundreds of orders net of commission and fees, so somebody reconciles it in a spreadsheet and posts a plug entry to make the bank balance. Business Central has no native concept of a marketplace channel: no OnBuy setup page, no listing table, nowhere to hold a marketplace order reference, and nothing that turns a settlement report into general ledger entries.
ECOSIRE builds an AL extension for your tenant that makes OnBuy a first-class channel inside Business Central. The extension adds its own setup table and page for credentials, marketplace, currency and posting defaults; table and page extensions carrying the OnBuy order ID, listing reference, fulfilment method and channel flag onto Sales Header, Sales Line, Item and Item Variant; and codeunits owning each integration direction. Inbound order polling runs on a job queue entry at your chosen cadence, creating sales orders — or posted invoices, if you prefer — with a mapped customer, a marketplace dimension for reporting, and a status map translating OnBuy order states into your document flow. Outbound stock and price synchronisation is driven by event subscribers on Item Ledger Entry and reservation entries, so a change in sellable quantity queues a delta update rather than a nightly full push. Every call is written to an integration log table with request, response, HTTP status and retry count, so a failed message is inspected and replayed from a page instead of guessed at from a log file.
Listing export treats the Business Central item card as the source of truth. We build a mapping layer between your item categories, item attributes and units of measure and the OnBuy category and attribute schema, so a new item is published without leaving the ERP. Where OnBuy requires a value your item master does not hold, the extension surfaces it as a mapping gap on a validation page before a listing is attempted, rather than failing silently at the API. Shipment confirmation runs the other way: posting a sales shipment or warehouse shipment raises an event that pushes despatch confirmation, carrier and tracking number back to OnBuy, closing the despatch clock without anyone touching the seller portal.
Settlement is where most marketplace projects stop and ours does not. The extension ingests the OnBuy settlement report, matches each line to its originating sales document, and generates the journal entries for commission, fees, refunds, adjustments and the net payout — posting to the accounts you nominate during scoping, with the payout line ready to apply against the bank receipt. Reconciliation becomes a review of exceptions rather than a rebuild of the month. All of it respects Business Central's own machinery: dedicated permission sets so an accounts user and a warehouse user see different pages, API pages (REST API v2.0 / OData v4) exposing channel data to Power BI, Power Automate or a Dataverse virtual table, and telemetry emitted to your Application Insights resource if you use one.
This is a build-to-order product, not an AppSource download. You request a quotation, we run a scoping call, and we agree in writing exactly which OnBuy behaviours you need — which order states create documents, how customers and items map, which fee types post where, and whether you are on SaaS or on-premises. From confirmed scope, typical delivery is two to four weeks. We build against your Business Central release wave, deploy to a sandbox first for UAT with your own data, then install into production behind a rollback plan. You receive the AL source, the git repository and the documentation, so the extension is yours and no other vendor holds the keys to your marketplace channel.
Owns the OnBuy account and its performance metrics. Needs listings published from the item master without a second data-entry pass, stock accurate enough to avoid oversells and the account penalties that follow, and despatch confirmations sent inside the marketplace cut-off without anyone logging into the seller portal.
Fulfils the orders. Needs marketplace orders to arrive in Business Central as ordinary sales documents that flow through the existing pick, pack and shipment process, with tracking pushed back automatically on posting rather than typed into a separate screen.
Signs off the numbers. Needs the OnBuy remittance to reconcile line by line to posted documents, commission and fees to hit the right general ledger accounts automatically, and channel profitability visible in the same dimension analysis used for every other revenue stream.
Owns the tenant and its extensions. Needs a clean AL extension in a registered object range that survives release-wave upgrades, uses supported extensibility rather than base application modification, and arrives with source and documentation so it can be maintained without a vendor dependency.
| Criterion | ECOSIRE | Custom Build | Competitor | Dynamics 365 Business Central Native |
|---|---|---|---|---|
| Fit to your OnBuy workflow | Built to your confirmed scope — your order states, customer mapping, fee accounts and dimensions | Exactly what you specify, if your developer knows both OnBuy and AL well | Generic marketplace model; you adapt your process to the app's assumptions | No marketplace concept at all — OnBuy orders are rekeyed by hand |
| Time to a working system | Two to four weeks from confirmed scope, including sandbox UAT | Typically several months across discovery, build and rework | Installs in minutes, then weeks of configuration and workarounds | Immediate, but the manual process never actually goes away |
| Settlement and fee reconciliation | Settlement report matched to documents and posted as journal entries, with an exception page | Possible, but usually the first thing descoped when budget tightens | Often order sync only; fees left to a spreadsheet and a plug entry | One bank line per remittance, reconciled manually every month |
| Source code ownership | Full AL source plus the git repository handed to your organisation | Yours, assuming the contract assigns IP and the code was committed | Compiled app only; you cannot inspect or change behaviour | Not applicable — nothing to own |
| Release-wave upgrade path | Tested against each Business Central preview wave; updated build supplied under support | Your team's responsibility twice a year, indefinitely | The vendor's roadmap decides when your version is supported | Handled by Microsoft, but there is nothing to upgrade |
| Error visibility and recovery | Integration log with request, response, status and one-click replay of a failed message | Depends entirely on whether logging made it into scope | Usually a status column; root cause needs a vendor support ticket | The error is a person forgetting to rekey an order |
| Cost shape | Fixed quotation for the build, then an optional annual support arrangement | Day rates, with the usual overrun risk on an unfamiliar API | Per-tenant or per-order subscription that scales with your success | No licence cost, paid instead in staff hours and oversell penalties |
| Security and access control | Credentials in isolated storage; separate permission sets for setup, sync, finance and logs | As good as the developer's habits on the day | Vendor-defined permission model, often all-or-nothing | Marketplace credentials live in a browser and a shared password note |
This is a build-to-order extension, so nothing is downloaded on the day you buy. We start with a scoping call — usually around 30 minutes — to confirm which OnBuy order states create documents, how customers and items map, which fee types post to which accounts, and your Business Central version and deployment model. Once that scope is confirmed in writing, typical delivery is two to four weeks, including sandbox deployment and UAT. Unusually complex requirements, such as multi-entity or multi-currency settlement rules, are quoted with their own timeline rather than squeezed into that window.
No. It is built for your tenant against your requirements and delivered as a per-tenant extension, installed by us into your sandbox and then production. That is deliberate: OnBuy account configuration, item mapping and fee posting differ enough between sellers that a one-size app usually needs configuration work anyway. If you would rather have it packaged for AppSource distribution — for example if you are a partner reselling it — say so at scoping and we build to the AppSource technical validation requirements instead.
Every build includes a post-go-live support window, agreed in writing at quotation, during which defects against the delivered scope are fixed at no charge. After that, ongoing support and release-wave compatibility work are available as an annual arrangement. Business Central ships two major waves a year; we test the extension against each preview and supply an updated build where a change affects it. Because you hold the source and the git repository, you can equally have your own partner maintain it — the handover is genuine, not a licence to look.
In most cases yes. The extension uses supported extensibility only — table extensions, page extensions, event subscribers and codeunits in a registered object range — so it does not modify the base application and does not conflict with other extensions at source level. Where you already run another e-commerce or shipping extension subscribing to the same events, we identify that during scoping and agree the sequencing so both continue to fire correctly. We test against your sandbox with your extensions installed before anything reaches production.
Yes. The extension is written in AL and runs on both. On SaaS it uses isolated storage for credentials and job queue entries for scheduling. On-premises works the same way, with the additional consideration that outbound HTTPS access to the OnBuy API must be permitted from the service tier and that HttpClient calls run in the context of your service account. Tell us your deployment model at scoping and we build and test against it.
Availability is calculated from Business Central's own reservation-aware availability rather than a raw inventory quantity, so units reserved against open orders are never offered on OnBuy. Changes are detected through event subscribers on inventory movement and queued as deltas, so the marketplace is updated within your configured window rather than overnight. You can also configure a buffer quantity per item or item category — holding back a few units on fast-moving lines is often cheaper than chasing an oversell.
The extension ingests the OnBuy settlement report, matches each line to the sales document it came from, and creates general journal entries for commission, fees, refunds and adjustments against the accounts you nominate during scoping. The net payout posts as a line ready to apply against the incoming bank receipt, so reconciliation becomes a review of unmatched exceptions rather than a manual rebuild. Lines that cannot be matched are held on an exception page with the reason, never posted silently to a suspense account.

A build-to-order Business Central AL extension that maps your 3PL warehouses into native sales and purchase flows — sending fulfillment orders, ingesting ASN and shipment confirmations, and reconciling on-hand quantities against each 3PL's stock balances.

A build-to-order Business Central (AL) extension that validates, standardizes and geocodes shipping addresses in real time at order entry, flags residential vs. commercial and surcharge risk, and catches duplicate customers before delivery failures cost you money.

A build-to-order Business Central extension that streamlines physical and cycle counting with barcode scanning, simultaneous multi-user count sheets, zone-based counting, and variance reconciliation that posts clean Item Journal entries — installed and supported by ECOSIRE on your tenant.

Closes mobile-scanning, label-printing and rapid-count gaps in Dynamics 365 Supply Chain Management's warehouse module. ECOSIRE builds, installs and supports a per-tenant AL extension on your own environment — no generic AppSource compromise.
A build-to-order AL extension connecting OnBuy to Dynamics 365 Business Central — importing orders, pushing stock and prices, exporting listings, confirming shipments and posting settlement fees. ECOSIRE scopes, builds, installs and supports it for your tenant.