Most teams running Odoo hit the same wall the moment a warehouse operator, technician, or site supervisor needs material: there is no first-class place for an employee to say "I need 40 units of this to keep working." Odoo core gives you Purchase Requisitions (purchase.requisition) as a Manager-facing tendering tool and Purchase Agreements — but those are procurement instruments, not shop-floor demand capture. The gap gets filled with spreadsheets, WhatsApp messages, and internal transfer requests raised by whoever has stock access, which means no audit trail on who asked for what, no budget check before someone commits spend, and no clean handoff from "employee raised a need" to "buyer raised an RFQ" or "stock team issued an internal transfer." When procurement, inventory, and the requesting department each keep their own version of the truth, over-ordering, stock-outs, and unapproved purchases follow.

We build a made-to-order Odoo module that gives every employee a governed way to request material and gives Purchase and Inventory a single approval spine to run it through. At its core is a material.requisition model (header + material.requisition.line) with state transitions (draft → submitted → approved → sourced → done / rejected / cancelled), compute fields via @api.depends for on-hand vs forecasted availability pulled from stock.quant and product.product, and a configurable approval matrix driven by mrp-style routing or an amount/department threshold. Each approved line is dispatched intelligently: if the item is available in a source warehouse it raises a stock.picking internal transfer; if it must be bought it seeds a draft purchase.order line (or a purchase.requisition tender when you want multi-vendor bidding), carrying the requester, analytic account, and budget line through so nothing loses its origin. Access is locked down with ir.model.access.csv plus record rules so employees see only their own requests while approvers and buyers see their queues; multi-level approvals use Odoo's activity/automated-action framework so escalations and reminders are native, not bolted on. Everything is exposed through standard views (list, form, kanban by state, a pivot for demand analysis), a QWeb PDF requisition slip for signature, and the XML-RPC/JSON-RPC API so an external portal, mobile app, or MES can post requisitions programmatically. We ship a proper __manifest__.py with pinned dependencies and target your exact Odoo series — 17.0, 18.0, or 19.0 — accounting for Community vs Enterprise differences (for example, approval-tier and advanced routing behavior) so the module fits your edition rather than assuming features you may not have.

Because this is build-to-order, delivery starts with a scoping call, not a download. After we confirm the exact states, approval hierarchy, sourcing rules, and any integration points, typical delivery is 2–4 weeks from confirmed scope: we develop against your version on an isolated staging environment, run UAT with your team, then install to production with a documented rollback path and a git repository handover. Pricing starts from $249 (indicative, single-company base scope); multi-company routing, deeper procurement/budget integrations, localization requirements, or migrating a large backlog of historical requisition data increase the quoted scope. You get a fixed quote after the scoping call — never a surprise invoice.