Dental clinics run on tooth-level detail that generic clinic and appointment software simply does not model. Odoo's stock calendar and appointment apps can book a slot and sale/account can raise an invoice, but there is no concept of a tooth, a surface, a periodontal reading, or a phased treatment plan that a hygienist starts today and a prosthodontist finishes across three visits. Front desks end up tracking recalls in spreadsheets, dentists re-explain the same case every visit, and insurance pre-authorizations get lost between the operatory and the billing desk. This is where native Odoo runs out of road for a real dental practice.

ECOSIRE builds a dedicated dental layer as a proper Odoo module with its own __manifest__.py, models, security and views. At its core is an interactive dental chart implemented as an OWL component backed by dental.tooth and dental.tooth.condition models, using the FDI/Universal numbering system so every finding is stored per tooth — and per surface where clinically relevant — rather than as free text. Treatment is modeled as dental.treatment.plan with sequenced dental.treatment.plan.line procedures, each carrying a phase, an estimated cost computed via @api.depends from your procedure price list, and a status that moves from proposed to accepted to completed. Because procedures are real Odoo records, an accepted plan line can generate a chair booking and, on completion, flow straight into account.move for procedure-based billing.

Scheduling is chair-aware: we extend the resource model so operatories are bookable resources, letting the front desk allocate an appointment to a specific chair and dentist without double-booking. Recall and follow-up reminders run on Odoo's scheduler (ir.cron) plus automated actions (base.automation), generating activities or SMS/email at the intervals your practice defines — six-month hygiene recalls, post-op check-ins, or overdue-treatment nudges. Insurance pre-authorization is modeled as its own state machine on the treatment plan so a procedure cannot be billed as covered until its pre-auth is approved, and every clinical note, chart change and status transition is written to the standard mail.thread chatter for a full audit trail. QWeb reports produce the printed treatment estimate, the signed consent form and the per-tooth clinical summary; the whole model is reachable over Odoo's XML-RPC/JSON-RPC API if you need to feed a patient portal or imaging bridge.

Access is locked down with ir.model.access.csv and record rules so a receptionist, hygienist and dentist each see the right slice of the chart, and multi-clinic groups get per-branch record rules out of the box. Everything is built and tested against Odoo 17.0, 18.0 and 19.0, and we are explicit about Community vs Enterprise: the module targets Community and layers cleanly on top of Enterprise where you already run it, so we scope to whichever edition you license rather than assuming Enterprise-only apps.

This is build-to-order, not an instant download. After a short scoping call we confirm your tooth-numbering standard, procedure catalog, insurance rules and recall cadence, then build, install and hand over the module — typically 2 to 4 weeks from confirmed scope. You receive the installable source for your Odoo version, UAT on a staging database with a rollback plan, documentation and a training session, plus a post-go-live support window. No fabricated download claims, no generic clinic app pretending to be dental software — a module built for how your practice actually charts teeth.