Bukalapak Marketplace Connector

Key Features

Bukalapak seller API client codeunit with token storage in isolated storage, automatic refresh, exponential-backoff retry and a full request/response log table for support

Channel order and channel order line tables holding the raw marketplace payload, so imports are idempotent and re-processable without calling the API again

Configurable status mapping from Bukalapak order states to the Business Central document flow: sales order, warehouse shipment, posted sales invoice, credit memo or held exception

Table extensions adding channel, marketplace order id and payout reference to `Sales Header`, `Sales Line`, `Item` and `Item Ledger Entry` for end-to-end traceability

Availability push calculated from inventory on hand less reservations, with optional per-location filtering and a configurable safety-stock buffer per listing

Event-subscriber-driven reactive stock sync on item ledger entry insertion and sales posting, alongside scheduled full reconciliation, so oversell windows stay short

Price synchronisation from a nominated price list or customer price group, with a marketplace-specific uplift or per-listing override

Listing export with a maintainable item and variant to Bukalapak category and attribute mapping table, including required-attribute validation before publish

Automatic shipment confirmation and tracking push-back triggered on posted warehouse shipment or sales shipment, with carrier code translation

Settlement statement import that decomposes payouts into commission, service fee, shipping subsidy, promotion and adjustment lines against the payout reference

Automated settlement posting to general journal or purchase invoice using G/L accounts and dimensions you nominate, so the payout reconciles to the bank statement line

`Job Queue Entry` templates per sync direction with independently configurable cadence, error handling and failure notification

Dedicated permission sets (read, edit, setup) plus a role-centre activity page showing queue depth, last successful sync per direction and unresolved exceptions

API pages (REST API v2.0 / OData v4) exposing channel orders, listings and settlement lines to Power BI, Power Automate and Dataverse

Application Insights telemetry on sync runs, API failures and mapping misses, using your own instrumentation key

Built to order, done for you

No DIY setup — a working app, built, installed and supported by ECOSIRE.

You order

Start with a one-time build price. We scope it with you at kickoff.

We build & install

ECOSIRE builds, configures and installs it on your Dynamics 365 Business Central.

Go live + support

You go live in about 2–4 weeks, with a post-launch support window.

About this Product

Selling on Bukalapak while running Dynamics 365 Business Central usually means two disconnected worlds. Orders are re-keyed from the seller dashboard into sales orders, stock is adjusted by hand across warehouse and marketplace, tracking numbers are pasted back one at a time, and the settlement report at the end of the payout cycle never matches the bank statement because commission, service fees, shipping subsidies and promotional discounts were never posted anywhere. Business Central out of the box has no marketplace concept at all — no channel-order table, no listing entity, no fee mapping — so the gap gets filled with spreadsheets, a part-time data-entry role, and inventory that is wrong often enough to cause oversells.

What we build is an AL extension for your Business Central tenant that treats Bukalapak as a first-class sales channel. New tables hold the raw marketplace payload (channel order, channel order line, listing, settlement transaction) so nothing is lost in translation, and table extensions add channel provenance to Sales Header, Sales Line, Item and Item Ledger Entry — you can always trace a posted invoice back to the marketplace order it came from. A set of codeunits handles the integration edges: an HTTP client for the Bukalapak seller API with token storage in isolated storage, refresh, retry with exponential backoff and full request/response logging; a mapping engine that translates marketplace order states into your document flow (new to sales order, packed to warehouse shipment, delivered to posted sales invoice, cancelled or returned to credit memo or a flagged exception); and a synchronisation engine driven by Job Queue Entry records so cadence is configurable per direction rather than hard-coded.

Stock and price flow the other way. Availability is calculated from the fields you actually trust — inventory on hand less reserved quantity, optionally per location or per a nominated marketplace buffer — and pushed to Bukalapak on a schedule or reactively via event subscribers on item ledger and sales posting. Listing export maps Business Central items and variants to Bukalapak categories and attributes through a maintainable mapping table, so a new SKU is published without leaving the ERP. Shipments push back automatically: once a warehouse shipment or sales shipment is posted, the carrier and tracking number are confirmed to the marketplace within the seller SLA window. Settlements are the part most connectors skip — we import each payout statement, break it into commission, service fee, shipping subsidy, promotion and adjustment lines, and generate the corresponding general journal or purchase invoice entries against the accounts your controller nominates, so the payout reconciles to the bank line rather than being plugged.

The extension ships with its own permission sets, telemetry to Application Insights where you use it, a role-centre-linked activity page showing queue depth and last-sync status, and setup pages for credentials, mapping and posting accounts. It is built as a per-tenant extension for Business Central online (or as an on-premises extension if that is where you run), targets the release wave you are actually on, and is written to survive upgrades: no base-application modifications, no data-per-company assumptions we have not agreed, and interfaces where you are likely to want your own logic. Where you already invest in Power Platform, the marketplace tables are exposed through API pages (REST API v2.0 / OData v4) so Power BI, Power Automate and Dataverse can read them without a second integration.

This is build-to-order, not an AppSource download. We start with a short scoping call, confirm your Bukalapak account structure, Business Central version and localisation, item and variant model, warehouse setup and finance posting rules, then write a fixed scope. Typical delivery is 2-4 weeks from confirmed scope. You get the AL source, installation on your sandbox first, a UAT pass with your own orders and a rollback plan, then production deployment, training and a post-go-live support window. Nothing is sold as instantly downloadable, and nothing is claimed to work against a marketplace API contract we have not verified against your live seller account.

What you get

Installable AL extension source built and compiled against your exact Business Central version and release wave (SaaS per-tenant extension or on-premises extension)

Installation and configuration on your sandbox environment, then production — setup pages, permission set assignment and job queue entry creation included

Technical documentation: object ID range, table/page/codeunit inventory, event subscribers used, API endpoints called, mapping tables and extension points

End-user guide plus a live training session for your operations and finance teams, recorded so new staff can be onboarded later

UAT on your sandbox using your own Bukalapak orders and payout statements, with a signed-off test script and a documented rollback plan

Post-go-live support window for defect fixes and configuration adjustments, with the length agreed at scoping

Private git repository handover with full commit history, a branch for your version, and build instructions

Configuration workbook recording credential locations, account mapping, category and attribute mapping, and job queue schedules as deployed

Who this is for

Marketplace operations manager

Owns daily Bukalapak fulfilment and is tired of re-keying orders and chasing tracking numbers before the SLA clock runs out. Needs orders to land in Business Central automatically with the right status, and shipments confirmed back without anyone opening the seller dashboard.

Finance controller or accountant

Cannot close the month because marketplace payouts never tie to the bank. Needs commission, service fees, shipping subsidies and promotions posted as real entries against nominated accounts and dimensions, with each line traceable to its payout reference and originating order.

Inventory and warehouse lead

Runs one physical stock pool across retail, wholesale and Bukalapak, and pays for every oversell. Needs available quantity pushed from real Business Central availability with a configurable buffer, reactively on posting rather than once a night.

IT manager or Business Central partner lead

Responsible for the tenant staying upgradeable through every release wave. Needs a clean AL extension with its own object range and permission sets, no base-application modification, documented event subscribers, telemetry, and source code they can hand to another developer.

How Bukalapak Marketplace Connector Compares

Criterion	ECOSIRE	Custom Build	Competitor	Dynamics 365 Business Central Native
Fit to your process	Built to your confirmed scope — your fulfilment flow, warehouse model and posting rules	Fits perfectly if your team knows both AL and the marketplace API well	Generic flow; you adapt your process to the app's assumptions	No marketplace concept exists; the process lives in spreadsheets
Settlement and fee posting	Payout decomposed into commission, fees, subsidies and promotions, posted to your nominated accounts	Achievable, but usually the last feature built and the first cut for time	Often order sync only; settlement left as a manual journal	Manual journals from a downloaded statement each payout cycle
Time to a working system	2-4 weeks from confirmed scope, including sandbox UAT	Months once discovery, API learning and testing are counted honestly	Fast to install, then weeks of workarounds for the parts that do not fit	Immediate, because nothing is automated
Source code and ownership	Full AL source plus a private git repository handed over	You own it, and you own every future fix as well	Sealed app; changes depend on the vendor's roadmap	Not applicable
Upgrade and release-wave safety	Own object range, no base-app modification, documented event subscribers	Depends entirely on the developer's discipline	Vendor handles waves, on the vendor's schedule not yours	Microsoft-maintained, but there is no connector to maintain
Stock accuracy under load	Reactive event-driven push plus scheduled reconciliation and a per-listing buffer	Usually a nightly batch, because reactive sync is extra work	Fixed sync interval; buffers may not be configurable per listing	Manual adjustment; oversells are discovered after the fact
Ongoing cost shape	One build fee, then an optional support agreement you can end	Developer time indefinitely, including for every API change	Per-tenant or per-order subscription that grows with your volume	No licence cost, paid instead in data-entry hours and oversells
Reporting and Power Platform access	API pages (REST v2.0 / OData v4) over orders, listings and settlements	Only if specified up front and budgeted	Varies; internal tables are frequently closed	Standard BC APIs, but no marketplace data to expose

Frequently Asked Questions about Bukalapak Marketplace Connector

How long does delivery take, and what happens first?

This is build-to-order, so nothing downloads instantly. We begin with a scoping call of about 30 minutes to confirm your Bukalapak account structure, Business Central version and localisation, item and variant model, warehouse setup and finance posting rules. From confirmed scope, typical delivery is 2-4 weeks: build, sandbox install, UAT with your own orders and payout statements, then production deployment and training. Wider scope — multiple seller accounts, several companies, unusual fulfilment models — is quoted with its own timeline rather than squeezed into that window.

Which Business Central versions and deployments do you support?

We build against the release wave you are actually running, for Business Central online as a per-tenant extension or for on-premises. We compile and test on your version rather than shipping one binary for everyone, which is why the version is confirmed at scoping. If you are mid-upgrade, say so at scoping and we will target the version you will be on at go-live.

What happens to support and updates after go-live?

A post-go-live support window is included and its length is agreed at scoping — during it we fix defects and adjust configuration at no extra cost. After that, ongoing support and release-wave maintenance are available as a separate agreement. Because you receive the source and the git repository, you are never locked in: your own team or another partner can maintain it. If Bukalapak changes its seller API, we will tell you what the change means for your build and quote the adaptation.

Will this break when Business Central upgrades to the next release wave?

The extension modifies no base-application objects. It uses its own object ID range, table and page extensions, and event subscribers — the pattern Microsoft supports through upgrades. That said, no one can honestly promise an untouched extension survives every future wave forever, because subscribed events do get deprecated. We document every event we subscribe to, so a wave-readiness check is a short predictable task rather than an investigation.

How are stock levels kept accurate enough to avoid overselling?

Availability is derived from Business Central itself — inventory on hand less reservations, optionally filtered to nominated locations — not from a separate cached number. On top of the scheduled full reconciliation, event subscribers on item ledger entries and sales posting push a reactive update, so the window between a sale and the marketplace knowing about it is short. You can also set a safety-stock buffer per listing so a fast-moving SKU never advertises its last unit.

How does settlement reconciliation actually work in the ledger?

We import each Bukalapak payout statement into a settlement table and decompose it into its component lines — commission, service fee, shipping subsidy, promotion, adjustment. Those lines post to the general journal or a purchase invoice using G/L accounts and dimensions your controller nominates at scoping. Each line keeps its payout reference and links back to the originating channel order, so when the bank line arrives the payout matches instead of being plugged to a suspense account.

Do we get the source code, and who owns it?

Yes. You receive the full AL source and a private git repository with commit history and build instructions. Ownership terms for your build are set out in the quotation — we do not ship you a sealed binary you cannot open. That is deliberate: a marketplace connector is business-critical, and you should never be one vendor relationship away from being unable to change it.