Lean shops that run pull-based line replenishment quickly hit the edge of what Odoo does natively. Odoo's stock.warehouse.orderpoint min/max reordering is quantity-based and warehouse-centric — it fires on a global on-hand threshold, not on a physical empty-bin event at a specific line-side location. There is no first-class concept of a Kanban card, a two-bin loop, or a sized supermarket buffer. Teams end up bolting pull discipline onto spreadsheets and laminated cards, while MRP keeps generating procurement suggestions that ignore the shop-floor signal. The result is either stockouts at the line or piles of WIP nobody asked for.

ECOSIRE builds a dedicated Kanban and two-bin replenishment layer as a proper Odoo module. We add new models — a Kanban loop (ecosire.kanban.loop) that binds a product.product, a consuming line-side stock.location, a source supermarket/store location, a container/bin quantity, and a card count — plus a card/bin state model that tracks each physical bin as full, in_use, or empty. @api.depends computed fields derive loop-level metrics (cards in circulation, quantity exposed, coverage in hours) so planners see the loop health, not just raw stock. When a bin empties, the pull signal creates the appropriate stock.move / internal stock.picking from the supermarket to the line (or a purchase/manufacturing signal at the loop's upstream boundary), so replenishment is driven by consumption, not by an orderpoint sweep.

The empty-bin trigger is where the two-bin discipline becomes real. Operators scan a bin's barcode (or a QWeb-printed Kanban card) from an Odoo barcode-friendly view or a lightweight OWL screen; the scan flips that bin to empty and releases the pull. We wire base.automation automated actions and server actions so that reaching the reorder point in a loop kicks off the transfer automatically, and Community-vs-Enterprise differences are handled cleanly — the module works on Community, and where Enterprise-only apps (like the native Barcode app or Studio) are present we integrate with them rather than duplicate them. Security is enforced with ir.model.access.csv plus record rules so line supervisors, material handlers, and planners each see the loops relevant to their work center, and everything is reachable over the standard XML-RPC / JSON-RPC API for integration with MES, andon, or external scanners.

Because loops need to be sized, not guessed, we include Kanban loop sizing recommendations: a compute that reads recent consumption (average daily usage and variability from stock.move history) against replenishment lead time and container size, and suggests the number of cards to keep the loop stable without over-buffering. Planners get a concrete "you are running N cards, the model suggests M" view, plus a QWeb report and printable cards for the physical board.

This is a build-to-order engagement, not an instant download. After you request a quotation we run a short scoping call to confirm your loops, line-side locations, supermarket layout, and Odoo edition, then build the module against your version. Typical delivery is 2 to 4 weeks from confirmed scope. You receive the installable source for your Odoo version (17.0, 18.0, or 19.0), UAT on a staging database with a rollback plan, installation and configuration on your environment, documentation, a training session, and a post-go-live support window.