A funeral home runs on a single object that Odoo does not have: the case. From the first-call notification through transfer, arrangement conference, service, disposition and final statement, everything a firm does hangs off one decedent record — and every one of those steps has a deadline, a signature, a permit and a family waiting. In stock Odoo the pieces exist but they do not connect. sale.order can sell a casket but has no concept of a decedent, a place of death, or an authorising next of kin. calendar.event can hold a chapel booking but will happily double-book the preparation room. account.move can invoice, but it cannot separate what the firm supplies from cash advances paid to a third party on the family's behalf — the distinction every regulator and every honest statement depends on. Firms end up bridging the gap with a whiteboard, a shared spreadsheet of permit numbers, and a director who carries the schedule in their head.

We build ecosire_funeral_services as a proper Odoo application on top of that gap. A new funeral.case model carries the decedent, informant and authorising party (all res.partner records, so the family relationship survives into CRM and accounting), place and time of death, the responsible director, and a stage-driven lifecycle rendered as a statusbar over a configurable funeral.case.stage model — first call, transfer complete, arrangement conference, documents filed, service scheduled, disposition complete, account settled. Arrangement lines live on funeral.case.line, which selects product.product records tagged by a funeral_item_type selection so caskets, urns, memorial print, professional service fees and cash advances behave differently on the same conference screen. Computed fields declared with @api.depends roll the general price list, selected merchandise and cash advances into separate running subtotals in real time, so the director quoting at the table sees the family's number change as options are added — and the same computation later produces the statement, rather than a second number typed somewhere else.

Scheduling is modelled rather than freeform. Facilities and vehicles become funeral.resource records with a resource type and an optional Odoo resource.resource link, and each booking is a funeral.booking window validated by an SQL constraint plus a Python @api.constrains overlap check, so a chapel or a preparation room cannot be committed twice — the failure mode most likely to reach a family. Staff assignment uses hr.employee where the HR app is present and falls back to res.users where it is not. Regulatory documentation is handled as configurable funeral.document.type records with a required flag, an issuing authority, and a due-date offset from a chosen anchor (date of death, date of transfer, date of service), plus a case-level checklist that computes an outstanding-documents field — the field a manager filters a list view on at eight in the morning. Permits, certified copies and cremation authorisations attach as ir.attachment records against their document line, and QWeb reports generate the arrangement summary, the itemised price disclosure and the family statement as PDFs your firm's letterhead controls.

Access is designed for a small building where roles overlap. Three groups — Funeral Staff, Funeral Director, Funeral Manager — are defined in security/funeral_security.xml with matching rows in ir.model.access.csv, and record rules keep multi-branch firms separated by company_id while allowing a manager visibility across branches. Because the same record holds clinical detail and family financials, the pricing and statement fields carry group-level groups= restrictions on the view, not just on the menu. Automated actions built on base.automation server actions (rather than the Enterprise studio automation UI, which Community lacks) drive the reminders: a document falling due, a service within twenty-four hours without a full staff assignment, an aftercare follow-up at a configurable interval after disposition. Everything is reachable through the standard XML-RPC and JSON-RPC endpoints, so a website first-call form, an answering service, or a crematory's system can create and read cases without bespoke middleware.

This is build-to-order, and we say so plainly: it is not an existing download on apps.odoo.com. We start with a scoping call, walk your actual arrangement conference and your jurisdiction's document set, and write a specification you approve before anyone writes code. Typical delivery is two to four weeks from confirmed scope for the standard configuration — longer where a specific registry integration or an unusual disposition workflow is in play, and we tell you which before you commit. You receive the installable source for your exact Odoo series (17.0, 18.0 or 19.0), a staging installation for UAT with a written rollback plan, and the git repository, so the module is yours to keep whether or not you keep working with us.