Quick Commerce Connector

Fonctionnalités clés

Per-dark-store availability computed from `stock.quant` free-to-promise, open channel orders and a per-SKU safety buffer, stored via `@api.depends` so stock moves trigger targeted recomputes

Outbound inventory sync worker that batches deltas by store, collapses repeated changes to the same SKU, and respects each platform's rate limit and payload size cap

Store cut-off and slot calendar per store, weekday and channel, with holiday and ad-hoc closure overrides that reject or defer late orders instead of silently accepting them

Raw inbound order archive: every channel payload is persisted before parsing, so malformed or rejected orders are recoverable and replayable rather than lost

Store-to-warehouse routing that reserves stock from the resolved dark store's location only, preventing a cross-store reservation no rider can fulfil

Substitution workflow with an approval window — picker flags a shortage, the channel substitution or cancel call fires from an automated action, and the sale order line, picking and credit note stay in agreement

Courier handoff state machine on `stock.picking` (ready, assigned, picked_up, delivered, failed) with rider identifier, timestamps and channel status push on every transition

Channel fee reconciliation model that imports settlement files, matches payout lines to orders, and books commission, rider fee, promotion co-funding and penalties to nominated analytic accounts

Unmatched settlement queue with variance reporting — differences are surfaced for a human, never auto-plugged into a suspense account

Idempotent inbound handling keyed on the channel order reference, so a webhook retry or a poll overlap cannot create a duplicate `sale.order`

Retry and dead-letter handling for outbound calls, with exponential backoff, a failed-call log and an operator-triggered replay from the Odoo UI

Record rules scoping store managers to their own dark store, plus `ir.model.access.csv` groups for channel operator, store manager and integration admin

OWL operations board showing live per-store order flow, at-risk cut-offs, shortage queue and courier status on one screen

QWeb reports for the daily store pick sheet, the shortage and substitution log, and the settlement variance statement

Multi-channel architecture: each platform is a configuration record with its own credentials, endpoints, field mapping and fee schema, so a second channel is configuration plus an adapter, not a rewrite

Fait sur commande, clé en main

Aucune configuration à faire vous-même — une app fonctionnelle conçue, installée et prise en charge par ECOSIRE.

Vous commandez

Commencez par un prix de développement unique. Nous cadrons le projet avec vous au lancement.

Nous développons et installons

ECOSIRE la développe, la configure et l'installe sur votre Odoo.

Mise en ligne + assistance

Vous êtes en ligne en 2–4 semaines environ, avec une période d’assistance après le lancement.

À propos de ce produit

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 2-4 weeks 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.

Ce que vous obtenez

Installable Odoo module source built for your exact version (17.0, 18.0 or 19.0), Community or Enterprise

Installation and configuration on your environment — dark-store mapping, cut-off calendars, channel credentials, fee posting accounts

Technical documentation: data model, per-channel field mappings, cron schedule, API endpoints and extension points

End-user guide plus a live training session for your operations and finance teams

UAT on a staging copy of your database with real order shapes, a sign-off checklist and a documented rollback plan

Post-go-live support window for defect fixes on the delivered scope

Full git repository handover — you own the code

Channel API integration package: credential setup, sandbox validation and production cutover for each platform in scope

Pour qui c'est

Head of E-commerce, FMCG brand

Sells through two or three quick-commerce platforms and is tired of reconciling spreadsheets against portal dashboards. Needs one Odoo view of channel orders, real per-store availability, and confidence that what the platform shows as in stock is actually on a shelf.

Dark Store / Fulfilment Operations Manager

Runs the stores that pick these orders. Needs a pick sheet that respects the rider slot, a fast shortage and substitution path that does not require calling the platform's support line, and courier handoff evidence when a delivery is disputed.

Finance Controller

Owns the gross-to-net gap. Needs commission, rider fees, promotion co-funding and penalties booked to the order and analytic account that earned them, an auditable unmatched queue, and a settlement variance report they can defend.

IT Lead / Odoo Administrator

Will maintain this after go-live. Needs a conventional addon with readable models, proper access and record rules, no core patching, standard XML-RPC/JSON-RPC access, and a documented upgrade path across Odoo versions.

Comment Quick Commerce Connector se compare

Critère	ÉCOSIRE	Construction personnalisée	Concurrent	Natif Odoo
Per-store availability logic	Free-to-promise per dark-store location with per-SKU safety buffer, built to your rules	Achievable, but the compute and recompute strategy is where most in-house builds get it wrong	Usually company-wide or single-warehouse quantity pushed to the channel	`stock.quant` holds per-location stock; no channel-facing availability feed exists
Cut-off and slot handling	Per store, weekday and channel with holiday overrides and pre-cut-off suppression	Often deferred to phase two, then bolted on under operational pressure	Rarely modelled; orders are accepted and fail at the store	No slot or cut-off concept in core sale or stock
Substitution and shortage flow	Picker-triggered, channel call fired from an automated action, order and credit note kept in sync	Buildable, but the three-way sync between order, picking and channel is the hard part	Typically manual — an operator calls or uses the platform portal	Line edits and credit notes exist; nothing pushes the decision back to the channel
Courier handoff evidence	State machine on the picking with rider ID and timestamps, pushed to the channel	Depends entirely on how disciplined the internal build is about audit trail	A status field at best; rarely dispute-grade evidence	Picking states only; no rider or handoff concept
Channel fee reconciliation	Settlement import matched to orders, fees to nominated analytic accounts, unmatched queue	Frequently descoped to spreadsheets once the delivery deadline bites	Usually out of scope — the module stops at the order	Journal entries keyed in by hand from portal reports
Multi-channel expansion	Adapter plus configuration record per platform; a second channel is not a rewrite	The second channel often reveals the first was hard-coded	One module per marketplace, each with its own conventions	Not applicable
Odoo version and edition fit	Built for your exact 17.0/18.0/19.0 install, Community or Enterprise, no core patching	Version fit is yours to maintain across upgrades	Version support depends on whether the vendor has ported it yet	Whatever ships with your version
Ownership and maintenance	Full git repo handover, technical docs, training and a support window	You own it, including the parts nobody documented	Vendor-controlled source; changes go through their roadmap	Odoo maintains core; the gap stays a gap

Foire aux questions sur Quick Commerce Connector

How long does delivery take?

This is a build-to-order module, so there is no instant download. Typical delivery is 2-4 weeks from confirmed scope. The variables are how many channels are in the first release, how quickly platform API credentials and sandbox access arrive, and how much of your dark-store and fee structure already exists in Odoo. A single-channel build with clean warehouse mapping sits at the fast end; three platforms with three different settlement formats sits at the slow end. You get a fixed quotation and a written scope before any code is written.

Which quick-commerce platforms do you support?

Each platform is a configuration record with its own adapter, credentials, field mapping and fee schema. We build adapters for the platforms you actually sell through — that list is part of the scoping call. If a platform has a documented inventory, order and status API, we can integrate it. If it only offers a CSV/SFTP exchange or a portal, we tell you honestly what that limits (usually near-real-time stock sync) before you commit.

Does this work on Odoo Community, or do I need Enterprise?

The module runs on Community. All of it — the availability compute, cut-off calendar, order intake, substitution workflow, courier state machine and fee reconciliation — is built on core models available in both editions. If you are on Enterprise we integrate with what you already pay for rather than duplicating it: barcode-driven picking for the store pick flow, the accounting reconciliation widget for settlements, and any Studio fields you have added. We support 17.0, 18.0 and 19.0.

What happens after go-live — support and updates?

Delivery includes a post-go-live support window for defect fixes on the delivered scope. Beyond that we offer an ongoing support and maintenance arrangement covering platform API changes (quick-commerce APIs change often), Odoo version upgrades, and new channel adapters. You hold the git repository and the source, so you are never locked in — your own team or another partner can maintain it if you prefer.

Will this oversell my dark stores?

Preventing that is the core design goal. Availability is computed per product per store location from free-to-promise quantity — quants minus existing reservations minus open channel orders not yet reserved — with a configurable safety buffer per SKU or category. Order confirmation reserves from that store's location only, and inbound handling is idempotent on the channel order reference so a webhook retry cannot double-book. What no connector can eliminate is the physical gap between a shelf count and reality; the safety buffer and the shortage/substitution workflow exist to handle that case gracefully instead of pretending it does not happen.

Can it handle orders that arrive after a store's cut-off?

Yes. Cut-offs are modelled per store, per weekday, per channel, with holiday and ad-hoc closure overrides. An order arriving after cut-off is either rejected back to the channel with the correct reason code or deferred to the next slot, depending on the rule you configure for that store. Availability is also suppressed for a store approaching closure so the platform stops offering you before the rejection is needed.

How do channel fees get into my accounts?

Settlement files import into a reconciliation model that matches payout lines to the originating orders. Commission, rider fee, promotion co-funding and penalties post to the analytic accounts and journals you nominate during scoping, so the gross-to-net bridge is visible on the order that earned it. Anything that does not match lands in an unmatched queue with a variance report — we never auto-plug a difference into a suspense account to make a file balance.