A build-to-order Odoo module that lets authorized users post inventory adjustments and stock moves on a past effective date, each stamped with a mandatory remark for audit-clean historical records. ECOSIRE builds, installs, and supports it on your Odoo 17, 18, or 19 environment. Built to order by ECOSIRE for Odoo 17, 18, 19 — indicative price from $249.00 USD; request a quote for a scoped proposal.
App manifest
Built around your workflow
A build-to-order Odoo module that lets authorized users post inventory adjustments and stock moves on a past effective date, each stamped with a mandatory remark for audit-clean historical records. ECOSIRE builds, installs, and supports it on your Odoo 17, 18, or 19 environment.
No DIY setup — a working app, built, installed and supported by ECOSIRE.
Start with a one-time build price. We scope it with you at kickoff.
ECOSIRE builds, configures and installs it on your Odoo.
You go live in about 2–4 weeks, with a post-launch support window.
Odoo stamps every stock move and inventory adjustment with the server date at the moment you validate it. That is correct for live operations, but it breaks the moment you are entering history: an opening stock count captured a week late, a physical count reconciled at month-end, a goods receipt that arrived before your go-live, or a correction that auditors expect to sit on the date the event actually happened. Out of the box the stock.move and stock.move.line date fields are written programmatically at validation, the inventory-adjustment flow on stock.quant records now(), and the valuation layers in stock.valuation.layer inherit that same timestamp — so your stock ledger, your valuation, and your accounting periods all disagree with the real-world event date. Finance then sees inventory movement land in the wrong period, and there is no native, permission-gated way to say "this happened on the 3rd, not today."
ECOSIRE builds a dedicated Inventory Adjustment Backdate module that adds a validated, audit-controlled effective-date override to Odoo's stock engine. We introduce an effective_date (Datetime) field and a required backdate_reason (Text) field on the adjustment and move flow, wired through a targeted extension of stock.quant, stock.move, and stock.move.line. When an authorized user posts a backdated adjustment, an override on _apply_inventory() / the move validation path propagates the chosen date down to the resulting moves, move lines, and the generated stock.valuation.layer rows, so the on-hand history, the SVL journal, and the account move (when Anglo-Saxon/perpetual valuation is on) all carry the same effective date. Every backdate writes an immutable trail — who set it, the original system date, the new date, and the remark — via the standard mail.thread chatter and a dedicated log model, so nothing is silently rewritten.
The control layer is where a made-to-order build earns its price. We gate the ability to backdate behind a new security group in ir.model.access.csv plus record rules, so only a controller or inventory manager can override a date; everyone else follows the normal now() behaviour. We add a configurable guard rail — a maximum look-back window and an optional hard lock against posting into a closed accounting period — enforced with an @api.constrains validation and a clear ValidationError rather than a silent correction. The reason field is mandatory by constraint, the backdated documents surface a visible badge in the form and list views (XML in 17.0/18.0, OWL-aware where you are on 19.0), and we ship an audit report (QWeb PDF or list export) of every backdated movement over a date range for your finance and audit teams. Optional add-ons we scope on request: an automated action to flag out-of-window attempts, and an XML-RPC/JSON-RPC endpoint so a data-migration script can post opening balances at their true dates.
Because this is build-to-order, delivery works as a short engagement rather than a download. We start with a scoping call to confirm your Odoo version (17.0 / 18.0 / 19.0), Community vs Enterprise, your valuation method, and who is allowed to backdate. We then build against a copy of your environment, hand you the module on a staging database for UAT, and only deploy to production once you have signed off — with a rollback path ready. Typical delivery is 2–4 weeks from confirmed scope. Pricing starts from $249 (indicative, single-company base scope); multi-company propagation, closed-period accounting locks, deep localization of the audit report, and bulk data-migration backdating via the API increase the quoted scope.
Needs inventory movement to land in the correct accounting period so valuation and the GL reconcile. Wants backdating locked to authorized users, blocked in closed periods, and fully audit-logged with a reason on every entry.
Runs physical counts and reconciliations that are often finalized days after the count date. Needs to post the adjustment on the real count date without breaking on-hand history or lot/serial traceability.
Loading opening balances and historical stock during a go-live or data migration. Needs to backdate opening moves to their true dates in bulk, ideally driven via the XML-RPC/JSON-RPC API, so historical reporting is accurate from day one.
Answers to external auditors and regulators. Needs an immutable trail of who changed a date, from what to what, and why, plus a report of every backdated movement over any period.
| Criterion | ECOSIRE | Custom Build | Competitor | Odoo Native |
|---|---|---|---|---|
| Backdated effective date | Permission-gated override propagated to moves, lines, and valuation layers | Possible, but you design and test the propagation yourself | Often sets the move date only, valuation may lag | |
| Mandatory reason / remark | Enforced by `@api.constrains`; no backdate without a remark | Only if you build and test the constraint | Varies; frequently optional or absent | |
| Access control | Dedicated security group + record rules; others keep native behaviour | You define the groups and rules from scratch | Generic or all-or-nothing access | |
| Accounting-period safety | Optional hard lock against posting into closed periods | Must be researched and coded per your valuation setup | Rarely checks period state | |
| Audit trail | Immutable log of user, original date, new date, reason + chatter | Only what you choose to build | Basic or no dedicated log | |
| Version + edition fit | Built and tested for your exact 17.0/18.0/19.0, Community or Enterprise | You own version compatibility | Generic build; may not match your edition | |
| Delivery model | Build-to-order: scoping, staging UAT, sign-off, rollback plan | In-house or contractor time and risk on you | Instant install, but generic and unsupported for your case | |
| Ownership + support | Full git repo handover + post-go-live support window | You maintain it entirely | Vendor-dependent, limited to their roadmap |
This is a build-to-order module, not an instant download. Typical delivery is 2–4 weeks from confirmed scope. After a short scoping call we build against a copy of your environment, hand it over on staging for UAT, and deploy to production only once you have signed off. Complex scope — multi-company, closed-period locks, or bulk migration — can extend the timeline, which we confirm before you commit.
No. Backdating is gated behind a dedicated security group and record rules, so only the controllers or managers you designate can override a date. A remark is mandatory, and every backdate is written to an immutable audit trail — user, original system date, new date, and reason — via chatter and a dedicated log model. It records history transparently; it does not silently rewrite it.
It propagates. The effective date is pushed to the `stock.move`, the `stock.move.line`, and the generated `stock.valuation.layer` rows, and under perpetual/Anglo-Saxon valuation the resulting account move carries the same date so inventory lands in the intended accounting period. We confirm your exact valuation method during scoping so the behaviour matches your setup.
We build for Odoo 17.0, 18.0, and 19.0, on both Community and Enterprise. Views are delivered as classic XML on 17.0/18.0 and OWL-aware where you are on 19.0. We confirm the exact version and edition on the scoping call because the stock and valuation internals differ slightly across releases.
Pricing starts from $249 (indicative, single-company base scope). The final number is a fixed quote issued after the scoping call, once we know your version, edition, valuation method, and whether you need multi-company propagation, closed-period locks, localization, or bulk API-driven backdating. You approve the fixed quote before any build work begins.
Every engagement includes a post-go-live support window for defect fixes and questions. Because the module extends stock and valuation rather than patching core, it ports cleanly; when you upgrade to a newer Odoo version we can quote a compatibility pass. You also receive the full git repository, so your own team can maintain it if you prefer.
Yes, this is a common scope add-on. We can expose a method callable over the XML-RPC/JSON-RPC API so your migration script posts each opening balance at its true historical date, with the reason and audit trail applied automatically. Bulk migration volume is one of the drivers that increases the quoted scope, so we size it during scoping.
A build-to-order Odoo module that lets authorized users post inventory adjustments and stock moves on a past effective date, each stamped with a mandatory remark for audit-clean historical records. ECOSIRE builds, installs, and supports it on your Odoo 17, 18, or 19 environment.