Quick Commerce Connector

Key Features

Per-dark-store publishable quantity engine: `actual_qty` less reservations, less allocated pick-list lines, less a per-item safety buffer, computed per Warehouse rather than company-wide

`Quick Commerce Store` DocType mapping each dark store to an ERPNext Warehouse with channel store id, timezone, service radius and an operating/cut-off calendar

Scheduler-driven stock sync via `hooks.py` `scheduler_events` — high-frequency delta pushes plus a slower full-catalogue reconciliation sweep that detects and repairs drift

Cut-off and slot aware order intake: orders evaluated against the store calendar at acceptance, with out-of-window orders routed to an exception queue instead of into fulfilment

Signed inbound webhook endpoint using `@frappe.whitelist(allow_guest=True)` with HMAC verification, replay protection and idempotency keyed on the channel order id

Staging `Quick Commerce Order` DocType so a malformed or duplicate channel payload never creates a bad Sales Order — retry and re-parse without data loss

Automatic Sales Order creation against the correct dark-store warehouse, customer group, price list and tax template, with the channel order reference carried through to Delivery Note and Sales Invoice

Courier handoff state machine (picking, packed, rider assigned, picked up, delivered, failed) with timestamped transitions and status write-back to the channel

Retry-safe outbound queue with exponential backoff and dead-letter visibility, so a platform 5xx or rate limit never leaves ERPNext and the channel out of sync

Substitution and shortage workflow driven by doc events on `Pick List` and `Delivery Note`: configurable equivalent-SKU substitution, partial fulfilment or line cancellation, with consistent Sales Order and refund handling

`Quick Commerce Settlement` DocType ingesting payout and fee files, matching lines to Sales Invoices and posting commission, picking, advertising and penalty components to nominated accounts

Explicit unmatched-settlement bucket and variance report — reconciliation differences are surfaced for review, never silently absorbed

Role profiles and permission rules separating store operator, channel manager and finance, plus a full API call log (request, response, retry count) for dispute evidence

Whitelisted REST methods and Frappe API exposure for BI tools, plus a store-supervisor client script showing live cut-offs and open exceptions inside the Sales Order form

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 ERPNext.

Go live + support

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

About this Product

Quick commerce breaks the assumptions ERPNext ships with. A standard ERPNext catalogue publishes one company-wide availability number, but a 10-minute delivery platform buys from a specific dark store: if the Gulberg micro-fulfilment centre holds 12 units and the central warehouse holds 900, exposing 912 guarantees cancellations, penalty fees and a suppressed listing. Orders also arrive against a slot and a cut-off — accept one two minutes after the rider wave closes and it is already late. ERPNext core has Warehouse, Bin, Item and Sales Order, but no notion of a per-store publishable quantity net of safety buffer and in-flight picks, no cut-off calendar, no rider handoff state machine, and no way to reconcile a platform settlement where commission, picking fees, ad spend and shortage penalties are netted off before payout.

ECOSIRE builds Quick Commerce Connector as a proper Frappe app — its own module inside a versioned repository, not scripts pasted into a production site. Dark stores are modelled as ERPNext Warehouses linked to a Quick Commerce Store DocType that carries the channel identifier, timezone, service radius and cut-off calendar. A scheduled job (registered in hooks.py under scheduler_events) recomputes a publishable quantity per store-item — actual_qty less reserved, less allocated picks, less a per-item safety buffer — and pushes deltas to the platform, with a full-catalogue reconciliation sweep on a slower cadence so drift never accumulates silently. Inbound orders land on a whitelisted endpoint (@frappe.whitelist(allow_guest=True) with HMAC signature verification and idempotency on the channel order id), are staged in a Quick Commerce Order DocType, then converted to a Sales Order against the correct dark-store warehouse and customer group. The cut-off engine evaluates the store calendar before acceptance and routes late or out-of-window orders to an exception queue instead of dropping them into fulfilment.

On the fulfilment side, a courier handoff state machine tracks picking, packing, rider assigned, picked up, delivered and failed-delivery — each transition timestamped and written back to the channel through a retry-safe outbound queue so a transient platform 5xx never leaves ERPNext and the app disagreeing. Doc events on Pick List and Delivery Note drive substitution and shortage handling: when a picker cannot fulfil a line, the app records the shortage reason, applies your configured substitution policy (equivalent SKU, partial fulfilment or line cancellation), adjusts the Sales Order and Delivery Note consistently, and emits the corresponding channel message so the customer refund and the ERPNext accounting entry agree. Client scripts give store supervisors an in-form view of live cut-offs and open exceptions without leaving the Sales Order.

Settlement is where margin usually leaks. The app ingests platform payout and fee files into a Quick Commerce Settlement DocType, matches lines back to Sales Invoices, and posts commission, picking, advertising and penalty components to the accounts you nominate — leaving an explicit unmatched bucket rather than silently absorbing variance. Role profiles separate a store operator (who resolves shortages) from a channel manager (who edits cut-offs and fee mappings) from finance (who posts settlements), and every outbound call is logged with request, response and retry count so a disputed order has an audit trail. Everything is exposed through the Frappe REST API and whitelisted methods, so your BI layer or a second channel connector can read the same data.

This is a build-to-order product, not an instant download. After a short scoping call we confirm your platforms, dark-store topology, cut-off rules, substitution policy and fee structure, then quote a fixed scope. Typical delivery is 2 to 4 weeks from confirmed scope, depending on how many channels and how unusual the settlement format is. We develop against your Frappe/ERPNext version (v15 or v16), deploy to a staging site for UAT with your own SKUs and a real sandbox channel where the platform offers one, and only then go live with a documented rollback. You receive the full source repository — the app is yours to keep, fork and extend.

What you get

Complete installable Frappe app source built for your Frappe/ERPNext version (v15 or v16), installed on your bench

Installation and configuration on your staging and production sites, including channel credentials, dark-store mapping, cut-off calendars and fee-to-account mapping

Technical documentation: DocType reference, `hooks.py` events, scheduler jobs, whitelisted API methods, webhook contract and error-handling model

End-user guide for store operators, channel managers and finance, covering shortage handling and settlement review

Live training session for your team with recording, run against your own data

UAT on a staging site with your SKUs and a channel sandbox where available, plus a written go-live and rollback plan

Post-go-live support window for defect fixes and configuration adjustments (duration agreed in the quotation)

Private Git repository handover with full commit history — the code is yours to keep, fork and extend

Who this is for

FMCG brand e-commerce lead

Sells through two or three quick-commerce platforms alongside their own D2C store and needs one ERPNext instance to be the truth for stock, orders and margin. Wants to stop maintaining channel inventory in spreadsheets and stop discovering fee leakage a quarter late.

Dark-store and micro-fulfilment operations manager

Runs several micro-fulfilment centres with different opening hours and rider waves. Needs stock exposed per store rather than company-wide, cut-offs enforced automatically, and a shortage workflow pickers can actually follow under a ten-minute clock.

Grocery retail finance controller

Receives netted platform payouts where commission, picking fees, ad spend and penalties are already deducted. Needs each settlement line matched to a Sales Invoice and posted to the right account, with an explicit unmatched bucket instead of a plug entry.

ERPNext implementation partner or in-house Frappe developer

Owns the client's bench and does not want undocumented server scripts in production. Wants a proper app in a Git repository, documented hooks and whitelisted methods, and code they can maintain after handover.

How Quick Commerce Connector Compares

Criterion	ECOSIRE	Custom Build	Competitor	ERPNext Native
Dark-store stock exposure	Per-warehouse publishable quantity net of reservations, open picks and a per-item safety buffer	Achievable, but the buffer and pick-allocation logic is usually discovered after the first oversell incident	Typically syncs one company-wide or single-warehouse number per item	Bin holds per-warehouse quantity, but nothing publishes a net figure to a channel
Cut-off and slot handling	Per-store operating calendar evaluated at acceptance; late orders go to an exception queue	Often hard-coded hours that break on holidays and timezone edges	Rarely modelled — orders are accepted whenever the platform sends them	No cut-off or slot concept in ERPNext core
Courier handoff and status sync	Explicit state machine with timestamped transitions and retry-safe write-back to the channel	Usually a status field plus ad-hoc API calls that fail silently on a platform 5xx	Status push exists but is commonly fire-and-forget with no dead-letter view	Delivery Note records dispatch; no rider states, no channel write-back
Substitution and shortage flow	Doc-event driven policy (substitute, partial, cancel) keeping SO, DN, invoice and channel refund consistent	Frequently deferred to phase two and handled manually in the interim	Generally reports the shortage without reconciling the downstream documents	Manual quantity edits with no channel-side refund linkage
Channel fee reconciliation	Settlement DocType matching payout lines to invoices, posting fee components with an explicit unmatched bucket	Commonly built last and simplified to a single lump-sum fee posting	Rarely covered; fees end up reconciled in spreadsheets	Payment Entry accepts the net amount; the fee breakdown is not modelled
Code ownership and maintainability	Proper Frappe app with its own module, documented hooks and a Git repo handed to you	Quality depends on the developer; server scripts left in production are a common outcome	Closed-source app on a vendor licence you cannot modify	Not applicable — customisation lives in your own app either way
Auditability of channel traffic	Every inbound and outbound call logged with payload, response and retry count for dispute evidence	Logging is usually added after the first unwinnable platform dispute	Varies; often an error log only, with successful calls unrecorded	No channel traffic exists to log
Time and risk to production	2-4 weeks from confirmed scope, with staging UAT and a written rollback plan	Multi-month discovery and build; requirements emerge during development	Fast to install, then blocked wherever your stores or fees differ from the vendor's model	Available immediately, but the quick-commerce workflow still has to be built

Frequently Asked Questions about Quick Commerce Connector

How long does delivery take, and can I download this today?

No — this is build-to-order, not a marketplace download. After a scoping call we confirm your channels, dark-store topology, cut-off rules, substitution policy and fee structure and quote a fixed scope. Typical delivery is 2 to 4 weeks from confirmed scope, longer if you need several channels or an unusual settlement format. Nothing is sold as a self-service download.

What support and updates do I get after go-live?

Every build includes a post-go-live support window (duration set in your quotation) covering defect fixes and configuration adjustments on the delivered scope. Because you receive the full Git repository, your own team can also maintain it. Beyond the window we offer an optional support and maintenance agreement covering channel API changes and Frappe/ERPNext version upgrades; new capability outside the original scope is quoted as a change.

Which quick-commerce platforms do you support?

We build against whatever platform your business actually sells on, provided it exposes a partner or seller API (or a documented file-based feed) that we can obtain credentials for. The stock, order, status and settlement layers are structured so a second channel is an adapter rather than a rewrite. Bring your platform list to the scoping call and we will confirm feasibility before quoting.

Which Frappe and ERPNext versions does it run on?

We build for Frappe/ERPNext v15 and v16, targeting the exact version on your bench. It is a standard Frappe app with its own module, DocTypes and `hooks.py`, so it installs with `bench get-app` and `bench install-app` and upgrades with your normal bench workflow. We do not patch ERPNext core.

How does it avoid overselling from a dark store?

Availability is computed per store-warehouse, not company-wide: `actual_qty` in that Warehouse's Bin, less reserved quantity, less lines already allocated to open pick lists, less a per-item safety buffer you configure. A scheduled job pushes deltas continuously and a slower full-catalogue sweep reconciles the whole store so drift cannot accumulate unnoticed. You can also set per-store item exclusions so slow movers are never listed at a location that cannot serve them.

What happens when a picker cannot find an item?

The shortage is recorded against the pick with a reason code, and your configured policy applies: substitute an equivalent SKU, fulfil partially, or cancel the line. Doc events keep the Sales Order, Delivery Note and Sales Invoice consistent with what actually shipped, and the corresponding channel message is sent so the customer-side refund matches the ERPNext accounting entry rather than diverging from it.

Will it work with our existing ERPNext customisations?

That is exactly what the scoping call establishes. We review your current app list, custom fields, naming series and any existing channel integrations before quoting, and we build alongside them rather than replacing them. If a conflict exists — a competing stock-sync job, for example — we identify it during scoping and agree the resolution in writing before development starts.