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.

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 one working week from confirmed scope. This is not an instant apps.odoo.com download — it is a module ECOSIRE builds, installs, and stands behind.