A controlled engineering document and drawing repository that links drawings, specs, and work instructions to products, BOMs, and ECOs inside Odoo — with revision approval, effectivity, and obsolete-revision lockout. ECOSIRE builds it to your process, installs it, and supports it. Built to order by ECOSIRE for Odoo 17, 18, 19 — indicative price from $249.00 USD; request a quote for a scoped proposal.

A controlled engineering document and drawing repository that links drawings, specs, and work instructions to products, BOMs, and ECOs inside Odoo — with revision approval, effectivity, and obsolete-revision lockout. ECOSIRE builds it to your process, installs it, and supports it.
अभी कोई भुगतान नहीं। यह हमारी टीम को एक कोटेशन अनुरोध भेजता है — हम कीमत और अगले चरणों के साथ ईमेल द्वारा संपर्क करेंगे।
Manufacturing teams that run on Odoo quickly hit a documentation wall. Drawings, control plans, work instructions, and specs live in shared drives, email threads, and PLM tools that never talk to the BOM your shop floor actually builds from. Operators pull the wrong revision, obsolete PDFs stay in circulation, and there is no defensible audit trail when a customer or auditor asks "who approved rev C, and when did it become effective?" Odoo core has documents (Enterprise) and file attachments (Community), but neither enforces a revision lifecycle, approval gate, effectivity date, or a hard link between a controlled drawing and the mrp.bom / product.template it governs. That gap is exactly where quality escapes and non-conformances originate.
New `ecosire.controlled.document` model with `document_number`, `revision`, and a `draft → in_review → approved → effective → obsolete` state machine enforced by compute/`@api.depends` logic
Hard `Many2one`/`Many2many` links from every controlled drawing to `product.template`, `mrp.bom`, and `mrp.eco` so documents follow the parts and BOMs they govern
Immutable revision history in a dedicated `ecosire.document.revision` model — approved revisions are frozen and never overwritten
Approval routing with a configurable sign-off matrix; a document cannot reach `effective` state until required approvers sign
Effectivity dating via `effective_date` so a new revision governs production only from its release date
Automatic obsolete lockout — superseding a revision flips the prior one to `obsolete` and blocks its download at the ORM layer
We build a dedicated document-control layer as a proper Odoo module. At its core is a new model — ecosire.controlled.document (models.Model) — carrying document_number, a revision sequence, a state selection (draft → in_review → approved → effective → obsolete), effective_date, and Many2one/Many2many links to product.template, mrp.bom, and mrp.eco. A related ecosire.document.revision model stores the immutable version history: each approved revision is frozen, watermarked, and never overwritten. Approval routing is enforced with a compute/@api.depends state machine plus server actions, so a document cannot reach effective without the required sign-offs, and superseding a revision automatically flips the prior one to obsolete and locks it from download. Access is governed by ir.model.access.csv for CRUD by role and ir.rule record rules for department/plant scoping, while every state transition, download, and approval writes to the audit trail (leveraging Odoo's mail.thread chatter and dedicated log records).
The build-to-order engagement includes the full technical surface: __manifest__.py with correct dependencies (mrp, product, mail, and documents where Enterprise is in play), OWL/XML backend views (form, list, kanban of controlled docs by state), a QWeb PDF report that stamps the drawing register and revision block, and automated actions that propagate document updates when a linked mrp.eco is closed — so releasing an engineering change can flag every affected drawing for re-approval. Obsolete-revision lockout is enforced at the ORM layer (download methods raise on obsolete/superseded states) and reinforced visually with server-side watermarking. Where you integrate with an external PLM or MES, we expose the models over Odoo's XML-RPC/JSON-RPC API so revisions and effectivity can be pushed or pulled programmatically.
Because this is a controlled-documentation system, we scope it to your actual process before writing code: your revision scheme, approval matrix, effectivity rules, and which of Odoo 17.0 / 18.0 / 19.0 (Community or Enterprise) you run. We then deliver installable source built for your exact version, install and configure it on your staging environment, run UAT with your quality and engineering leads, and cut over with a rollback plan. Typical delivery is 2–4 weeks from confirmed scope. This is not an instant apps.odoo.com download — it is a module ECOSIRE builds, installs, and stands behind.
Owns the revision lifecycle and needs a defensible, single-source register where drawings link to parts and BOMs, approvals are enforced, and obsolete revisions can never be pulled by the floor.
Answers to auditors (ISO 9001, IATF 16949, AS9100) and needs a complete audit trail of who approved which revision, its effectivity date, and proof that superseded documents are locked out.
Releases engineering changes through `mrp.eco` and wants document updates to propagate automatically to every affected drawing and work instruction instead of hunting them down by hand.
Runs the Odoo instance and needs a maintainable, version-correct module with clean access control and API hooks to an existing PLM/MES, not a fragile shared-drive workaround.
Buy the license on ecosire.com and download the Manufacturing Document & Drawing Control module ZIP from your account dashboard.
Extract the ZIP into your Odoo custom addons folder on the server (or upload via Apps > Install from file on Odoo.sh / runbot).
Activate Developer Mode, open Apps, click Update Apps List, search for Manufacturing Document & Drawing Control, and press Install.
Open the new menu, paste your ECOSIRE license key, connect any external credentials (Shopify, Amazon, Stripe, etc.), and save.
Run the built-in connection test, sync your first 10 records, and schedule the recurring cron. Contact support if anything fails.
| Criterion | ECOSIRE | Custom Build | Competitor | Odoo Native |
|---|---|---|---|---|
| Revision lifecycle & approval | Enforced draft→effective state machine with sign-off matrix | Possible but you design and maintain the whole state machine | Often a simple version field, no gated approval | |
| Link to products, BOMs & ECOs | Hard `product.template`/`mrp.bom`/`mrp.eco` relations | Depends entirely on your developer's scope | Rarely BOM-aware; usually standalone document store | |
| Obsolete-revision lockout | ORM-level download block + watermarking | Must be built and tested from scratch | Seldom enforced; obsolete files stay reachable | |
| ECO-driven propagation | Automated action flags affected docs on ECO close | Bespoke automation you specify and pay to build | Typically manual re-linking | |
| Audit trail | Full chatter + dedicated logs on every transition/download | Whatever you remember to instrument | Partial logging, varies by vendor | |
| Version & edition fit | Built and tested for your exact 17/18/19, CE or EE | One-off, tied to whoever wrote it | May lag Odoo releases; upgrade risk | |
| Delivery & ownership | 2–4 weeks, source + git handover, we support it | Unpredictable timeline; you own maintenance | Instant download but generic, limited support | |
| Access control scoping | `ir.model.access.csv` + record rules by dept/plant/line | Hand-rolled rules, easy to get wrong | Coarse group-based access typically |
No. This is a build-to-order module. ECOSIRE builds it to your revision scheme, approval matrix, and effectivity rules, then installs and supports it. There is no instant apps.odoo.com download — you get source code built for your exact Odoo version.
Typical delivery is 2–4 weeks from confirmed scope. The timeline starts once we have agreed on your revision lifecycle, approval routing, effectivity rules, and target Odoo version (17.0 / 18.0 / 19.0, Community or Enterprise). Complex PLM/MES integrations may extend this and are estimated during scoping.
We build and test for Odoo 17.0, 18.0, and 19.0, on both Community and Enterprise. On Enterprise we can integrate with the `documents` app; on Community we deliver a self-contained repository model. We confirm your exact version during the scoping call so the module ships correct on day one.
When a new revision reaches `effective`, the prior revision is automatically flipped to `obsolete` and locked — download methods raise at the ORM layer, so it cannot be pulled. Obsolete and draft revisions are also server-side watermarked so any printed or exported copy is visually unmistakable.
Yes. Each controlled document carries `Many2one`/`Many2many` links to `product.template`, `mrp.bom`, and `mrp.eco`. When you close an engineering change order, an automated action flags every linked document for re-approval, so drawings and work instructions follow the parts they govern.
Every engagement includes a post-go-live support window for bug fixes and configuration adjustments, plus full git repository handover so your team owns the source. Beyond the included window, we offer ongoing support and version-upgrade services (for example when you move from Odoo 18.0 to 19.0) under a separate agreement.
Yes. The controlled-document and revision models are exposed over Odoo's XML-RPC and JSON-RPC API, so an external PLM or MES can push and pull revisions and effectivity dates. Specific integration mappings are scoped and estimated as part of the build.
A controlled engineering document and drawing repository that links drawings, specs, and work instructions to products, BOMs, and ECOs inside Odoo — with revision approval, effectivity, and obsolete-revision lockout. ECOSIRE builds it to your process, installs it, and supports it.