Optical retail is a manufacturing business hiding inside a shop. Every sale starts with a clinical prescription, turns into a made-to-order lens ground to a specific sphere, cylinder and axis, gets edged and fitted into a chosen frame, and often has to be split between a customer co-pay and an insurance claim. Odoo core has the raw ingredients — product.template with variant attributes, pos.order, stock.picking, mrp.production, account.move — but nothing that understands an Rx, a lab job, or a coating add-on. Opticians end up tracking prescriptions in spreadsheets, keying lens parameters into order notes, and reconciling insurance by hand. That is where Odoo native runs out of road.

ECOSIRE builds a dedicated optical layer on top of your Odoo. We add a patient prescription model (an optical.prescription record linked to res.partner) that captures OD/OS values — sphere, cylinder, axis, add, prism, PD — with @api.constrains validation so an impossible axis or out-of-range power is caught at entry, and computed @api.depends fields that derive the reading vs distance breakdown. Frames and lenses live in a properly attributed catalog: frame material, shape, color and size as product.attribute variants, and lens options (index, coatings like anti-reflective or blue-light, tint, photochromic) modeled as configurable line options so a single lens SKU generates the right variant and price at point of sale.

The POS is where it comes together. We extend the Odoo POS (OWL frontend + pos.order backend) so a cashier picks the patient, pulls the active Rx onto the order line, configures the lens, and the system prices frame + lens + coatings together. When the order confirms, an optical.lab.order job is created automatically via an automated action, moving through a status pipeline — queued, surfacing/edging, fitting/mounting, QC, ready for collection — with the lab technician assigned and the target date computed. Insurance is handled as a split on the order: an insurer/scheme portion routed to a claim journal and the patient co-pay taken at the till, with a QWeb spectacle-order/collection ticket and the clinical Rx printed for the lab bench. All of it is guarded by ir.model.access.csv plus record rules so front-desk, optometrist and lab roles see only what they should, and the same data is reachable over the XML-RPC/JSON-RPC API if you want to feed a website booking form or an external edger.

Because this is build-to-order, nothing ships blind. We start with a scoping call to map your exact Rx fields, lens catalog, lab stages and insurance schemes, then build against your Odoo edition and version (17.0, 18.0 or 19.0; we flag anything that needs Enterprise such as full MRP or advanced accounting versus what runs on Community). You get the work on a staging instance for UAT first, a documented __manifest__.py-defined module with migration-safe data, and a defined go-live with rollback. Typical delivery is one working week from confirmed scope, and the module is yours — handed over as a git repository you own.