Quick commerce breaks the assumptions Business Central was built on. A standard sales order assumes a shipment date measured in days, availability calculated across a location, and a picking process a warehouse operator starts when they get to it. Quick-commerce platforms assume the opposite: they ask what is on the shelf of one dark store right now, they close an order slot in ten minutes, and they expect a courier assignment and a live status stream back within seconds. Out of the box, Business Central gives you Item Ledger Entry, Warehouse Entry, locations and bins, and a solid sales order pipeline — but it has no notion of a delivery slot, no cut-off calendar, no substitution policy for an out-of-stock line, and no place to book a courier or reconcile a platform's commission and picking fees against the payout you actually received.

What we build is an AL extension — delivered as a per-tenant extension or, where you want it, an AppSource-track app — that adds those concepts natively rather than bolting on a middleware layer. Dark stores are modelled on Business Central locations with a Dark Store Setup table carrying the platform mapping, the buffer policy and the publishing cadence. A dedicated availability codeunit reads Item Ledger Entry and Warehouse Entry net of open reservations and open quick-commerce orders, applies your safety buffer per item category, and publishes a per-store, per-SKU quantity through a custom API page (REST API v2.0, OData v4) that the platform or your integration middleware polls or receives by webhook. Publishing runs on job queue entries so cadence is configurable per store — every few minutes for fast movers, on-change for the rest.

Order intake lands on a staging table with its own page, not straight into Sales Header. That matters: a quick-commerce order arriving after its slot cut-off, or referencing a store that is closed, must be rejected or re-routed before it becomes a document. The cut-off engine holds per-store slot calendars and lead times, and stamps every incoming order with its promised slot; only orders that pass validation are released into a sales order via a codeunit that maps SKUs, applies the platform's price list, and reserves inventory against the dark store location. Substitution and shortage handling is driven by policy tables — swap to a mapped alternate, part-ship, or cancel the line — and every decision is written back to the platform through the same API surface so the app and the customer see the truth.

Courier handoff creates a dispatch record, pushes the pick-ready signal, and consumes status callbacks (assigned, picked up, delivered, failed) that post through to warehouse shipment and, where you want it, to the posted sales invoice. Fee reconciliation imports the platform's settlement file, matches commission, picking and delivery fees line by line against the order, and posts the variance to a G/L account you nominate — so the payout that hits the bank is explainable. Event subscribers are used throughout rather than base-app modification, permission sets ship with the extension, and Dataverse / Power Platform connectivity is available where you want Power BI fill-rate dashboards or a Power Apps picking screen on top.

This is build-to-order, and we are explicit about what that means. There is no AppSource button to press today. You request a quotation, we run a scoping call, and we write down the platforms you sell through, your dark-store footprint, how your SKUs and barcodes map to each channel's catalogue, your slot calendar, your substitution rules and your Business Central version and deployment (SaaS or on-premises, current release wave). From that confirmed scope we build, and typical delivery is two to four weeks. You get the AL source for your version, installation and configuration on your tenant, UAT on a sandbox before anything touches production, a documented rollback, training for your operations and finance teams, and a post-go-live support window while the first settlement cycles run through.