Suppliers routinely demand a deposit before they start production or ship goods — a percentage advance on tooling, a prepayment on imports, a milestone up front on a long-lead contract. Odoo's native purchase flow assumes a linear Purchase Order → receipt → vendor bill sequence and offers no first-class concept of a purchase down payment. Teams end up recording advances as loose journal entries or standalone vendor bills that are never linked back to the originating purchase.order, so nobody can answer the basic questions at a glance: how much have we prepaid this supplier, which POs are covered, and what is still owed after the deposit is netted off. Odoo's sale side ships a down-payment mechanism out of the box; the purchase side does not, and that asymmetry is exactly where finance and procurement lose control of cash.

We build a purchase-side down-payment module that mirrors the ergonomics teams already know from the sales flow, adapted to procurement. On the purchase.order form we add a "Register Down Payment" action that lets a buyer raise a deposit as a fixed amount or a percentage of the order total. That action generates a proper advance account.move (vendor bill / prepayment) posted to a configurable down-payment account, tagged with an analytic_distribution where relevant, and linked back to the PO through a stored relational field so the deposit is always traceable to its order. Computed fields — implemented with models.Model, fields.Monetary, and @api.depends compute methods — surface amount_down_payment, amount_residual_after_dp, and a live prepaid-balance indicator on the order, statusbar, and list views. When the final vendor bill is created from the PO, the module inserts the previously invoiced down payment as a negative line (or reconciles it against the bill), so the amount actually due to the supplier is correct without manual arithmetic.

Technically the module ships as a clean, versioned addon: a declarative __manifest__.py depending on purchase and account, ORM models extending purchase.order and account.move, XML view inheritance (plus OWL where the interaction warrants it) to place the deposit widgets, a QWeb report addendum so the printed PO and the bill both show the deposit and net-payable, and optional automated actions / server actions to enforce your policy (for example, blocking receipt until a required deposit is registered). Access is governed properly through ir.model.access.csv and record rules so buyers, approvers, and accountants each see only what their role allows, and multi-company setups keep down-payment accounts and journals segregated per company. Every capability is reachable through the standard XML-RPC / JSON-RPC API, so an external portal, supplier system, or RPA bot can register or query deposits programmatically. It targets Odoo 17.0, 18.0, and 19.0 and works on both Community and Enterprise (the accounting depth available follows whichever edition you run).

Because this is a made-to-order build, nothing ships as an instant download. After a short scoping call we confirm the exact deposit rules, accounting treatment, approval chain, and report layout you need, then design, build, and test the module on a staging copy of your database before install. Typical delivery is one working week from confirmed scope, and you receive the full source, a git repository handover, and a post-go-live support window. Pricing starts from $999 (indicative, single-company base scope); multi-company ledgers, deeper localization or tax-authority requirements on the advance invoice, prepayment-to-bill reconciliation complexity, and any integration or data migration increase the quoted scope. You get a fixed quote after the scoping call — never a surprise.