Multi Version Budget Pro
Multi-version budgets with purchase-order encumbrance, sign-aware variance, and an optional analytic dimension, computed straight from posted journal items.
Why this module
Multi Version Budget Pro
Budgets that stop a PO
An off/warn/block policy is enforced when a purchase order is confirmed, and the block path accumulates the required amount per budget line across every PO line before it checks availability. Several lines that each fit but together overrun are still caught. Commitments are idempotent per PO line, so re-confirming updates instead of duplicating.
Variance the right way round
Income, liability and equity accounts are sign-normalised before variance and availability are computed, so a revenue budget met to the dollar reads as zero variance, not a 200 percent overrun. A non-zero actual on a zero budget reads as a full 100 percent overrun rather than a silent 0 percent. The same maths runs in the ORM compute and the SQL report view, parity-tested.
Yours to keep
LGPL-3 source on disk. No activation key, no phone-home, no recurring licence. Multi company aware, posted-only actuals computed in one batch SQL per budget so it stays fast on hundreds of lines. Read it, extend it, fork it if you need to.
Day in the life
A controller approves a purchase order that would quietly blow the marketing budget.
Marketing has a confirmed budget with a block overrun policy. A buyer raises a purchase order with three lines that all map to the same advertising budget line. Each line on its own fits the remaining availability, so a naive check would wave it through. Here the block policy accumulates the required amount across all three lines first, sees that together they exceed what is left, and stops the confirmation. The buyer trims one line, re-confirms, and because commitments are keyed by PO line the system updates the existing commitments rather than stacking duplicates. A week later the vendor bills two of the three lines; the commitment releases proportionally, moving those dollars from committed to actual, while the third stays encumbered. The budget form and the SQL variance report show the same numbers, because they run the same sign-aware maths.
Edge cases
The cases most modules quietly ignore.
In the shipped code today, each one a place where a cheaper module silently does the wrong thing.
Two purchase-order lines that resolve to the same budget line keep separate commitments keyed by PO line, instead of one silently overwriting the other. Re-confirming a PO updates the existing commitments rather than creating duplicates.
The block policy accumulates the required amount per budget line across multiple PO lines before checking availability, so several lines that each individually fit but collectively overrun the budget are still caught at confirm time.
A non-zero actual against a zero budget returns 100 percent to flag a full overrun, instead of being reported as a misleading 0 percent.
Actuals on credit-natured accounts (income, liability, equity) are sign-flipped before variance and availability are computed, so a 10k revenue budget against 10k actual reads as zero variance, not a 200 percent overrun. The report view replicates the same normalisation.
A billed purchase order with a zero or negative untaxed total releases its commitment fully rather than dividing by zero when computing the proportional release.
Budgeted amount is blocked negative at the database CHECK level, so an ORM-bypass path cannot corrupt the variance maths.
The forecast seed records which algorithm it used (Holt-Winters, linear trend, or mean) in each line's notes, falling back explicitly by history length, so an auditor can see the basis of every projected figure.
What is inside
Built to do the job, end to end.
- Multi-version budgets. Copy a budget to a new version with a parent link and an auto-incrementing version label, so a v1 / v1.1 / v2 evolution stays auditable. Draft, confirmed and closed lifecycle, multi company aware, currency from the budget's company.
- Per-account lines with optional analytic. Lines pinned to a specific account and period window with a budgeted amount. An optional analytic dimension produces percentage-weighted actuals, computed identically in the ORM compute and the SQL report view and parity-tested.
- Purchase-order encumbrance. Per-budget off/warn/block overrun policy enforced at PO confirm, with per-line accumulation across a PO. Commitments are idempotent per PO line and release proportionally as the PO is billed.
- Sign-aware variance and availability. Variance, variance percentage and availability that correctly handle income, liability and equity accounts and zero-budget overruns, computed from posted journal items only.
- Batch actuals. One SQL pass per budget computes actuals for all plain lines at once with no N+1, plus one targeted pass per analytic account that is actually used. Results distributed in Python.
- Monthly split and forecast seed. A productivity action splits a line into one slice per overlapping calendar month, dividing the amount equally. A forecast seed projects from account history and records the algorithm used in each line's notes.
- Rolling roll-forward. A daily cron extends confirmed rolling budgets one calendar month forward as they near their end date, copying the latest month's lines, under a per-record savepoint so one bad budget never freezes the queue.
Honest about the edges
What this does not do, so nothing surprises you.
- Actuals are computed from posted journal items only. There is no option flag to include draft or unposted entries.
- The monthly split divides a line's budgeted amount equally across the calendar months it overlaps. It is not prorated by the number of days in each partial month.
- The rolling roll-forward extends only budgets that are marked rolling, in the confirmed state, and within roughly a month of their end date. Draft rolling budgets and budgets not near their end are not auto-extended.
- The only scheduled job shipped is the rolling roll-forward cron. Actuals are a non-stored computed value refreshed on read, so there is no separate actuals-refresh job to schedule.
- The forecast seed produces a starting projection for human review, not a committed budget. The figures are advisory until you confirm the budget.
odoo 19 community budget, multi version budget odoo, budget vs actual odoo, encumbrance accounting odoo, purchase order commitment budget, budget overrun block purchase order, analytic budget odoo community, budget variance analysis odoo, rolling budget odoo, fp&a budget odoo without enterprise
Languages
Available in 19 languages
The interface ships translated out of the box. Switch language in Odoo and the fields, menus, and messages follow.
Please log in to comment on this module