Quick commerce breaks the assumptions Odoo's standard e-commerce and inventory flows are built on. A 10-minute delivery platform does not want your company-wide qty_available — it wants the free-to-promise quantity in one specific dark store, refreshed within seconds, because an oversell there is a rider dispatched to a shelf with nothing on it. It also expects you to honour a rider arrival slot and a per-store cut-off time, to answer a substitution decision within a minute, and to accept a settlement file where the payout is the order value minus commission, rider fee, promotion co-funding and a platform penalty. Odoo core gives you stock.quant per location, sale.order and stock.picking — the correct primitives, and no channel adapter, no per-store availability feed, no slot model, and no place to book a channel fee against the order that earned it.

We build a dedicated Odoo module — a normal __manifest__.py addon, no core patching — that maps each dark store to a warehouse or internal location and computes a channel-facing availability figure per product.product x location. The compute is a stored @api.depends field over stock.quant reservations, open channel orders and a per-product safety buffer, so it survives a stock move without a full recompute sweep. A queue-backed outbound worker pushes deltas to the platform's inventory endpoint on the cadence each channel allows, batching by store and collapsing repeated changes to the same SKU so a receipt of 400 lines does not become 400 API calls.

Order intake runs the other way. The channel posts to a controller, or we poll — whichever the platform supports — and every payload lands in a raw inbound record before anything is created, so a malformed order is a support ticket rather than a lost sale. We resolve the store to a warehouse, validate against the cut-off schedule for that store and day (including holiday overrides), and create the sale.order with the promised slot on it. Confirmation reserves stock from that warehouse's location only. Shortages and substitutions are first-class: the picker flags a line short, an automated action fires the channel's substitution or cancellation call, and the resulting credit note or line amendment is written back so the order total, the picking and the channel record agree. Courier handoff is a state machine on the picking — ready, assigned, picked_up, delivered, failed — with each transition posting to the channel and recording the rider identifier and timestamps for dispute evidence. Settlement files import into a reconciliation model that matches payout lines to orders and books commission, rider fee and penalties to the analytic accounts you nominate, leaving an unmatched queue instead of a plugged difference.

Everything is built to standard Odoo conventions so your team can maintain it: models under models/ using models.Model, access rules in ir.model.access.csv plus record rules that scope a store manager to their own dark store, list/form/kanban views and an OWL operations board in views/, QWeb reports for the daily store pick sheet and the settlement variance report, and cron-driven automated actions for polling, retries and reconciliation. Integration surfaces are exposed over the standard XML-RPC/JSON-RPC API, so a WMS or a rider app can read and write the same records. It targets Odoo 17.0, 18.0 and 19.0 and runs on Community; if you are on Enterprise we wire the extras you already pay for — barcode-driven picking, Studio-authored fields, the accounting reconciliation widget — rather than reimplementing them.

This is build-to-order, not a download. We start with a scoping call to confirm which platforms you sell through, how your dark stores map to Odoo warehouses, what each channel's API actually returns, and how you want fees posted. You get a written scope and a fixed quotation before any code is written. Typical delivery is one working week from confirmed scope, depending on how many channels are in the first release and how quickly platform API credentials and sandbox access come through — a single-channel build is fast, three channels with three different settlement formats is not. We build on a staging copy of your database, run UAT with your operations team against real order shapes, and go live with a rollback plan. Source code and the git repository are handed over to you.