Pest control is a recurring-service business that regulators treat like a chemical handling business, and Odoo out of the box models neither well. A quarterly contract for a restaurant chain is not a sale order — it is a stream of visits that must be generated, routed, executed, documented and evidenced. project.task gives you a card on a kanban but no notion of a treatment interval, a re-treatment window, or a bait-station register. stock.move will decrement a litre of concentrate from a technician's van but knows nothing about active ingredient, dilution ratio, registration number, re-entry interval or the licence class a technician needed to apply it. When an auditor or a client's food-safety inspector asks what was applied at which site, on which date, at what concentration and by whom, the honest answer from a stock Odoo database is a spreadsheet somebody kept on the side.

We build a dedicated service layer on top of Odoo's existing spine rather than beside it. An ecosire.pest.contract record carries the site list, service frequency, covered pest scope and pricing, and a scheduled ir.cron materialises the next window of visits as ecosire.pest.visit records so a dispatcher is never generating work by hand. Visits inherit mail.thread and mail.activity.mixin, so every reschedule, client complaint and technician note lands on one chatter timeline. Technician assignment respects skill and licence: a technician record linked to res.partner holds licence class and expiry, and an @api.constrains on the visit refuses an assignment where the required application class is not held or has lapsed. Routing is a day-and-technician grouping on the visit model with sequence, drive-order and time-window fields exposed in list and map-style views, so a route is a saved, printable, re-orderable plan rather than a WhatsApp message.

The chemical layer is the part most off-the-shelf modules skip. We extend product.template with a pesticide profile — active ingredient, concentration, registration number, signal word, restricted-use flag, re-entry and pre-harvest intervals — and record each application as an ecosire.pest.application line against the visit: product, target pest, dilution, quantity applied, area or station count treated, application method and location on site. Quantities post back through stock.move against the technician's van location, so van inventory and site history stay in one ledger instead of two. Computed fields on the contract and site roll usage up per active ingredient over rolling periods with @api.depends, which is what a threshold check or an annual usage return actually needs. Every field that matters to an audit is stored on a record with a write date and an author, not in a note.

Documentation comes out as QWeb PDF reports: a per-visit service report and certificate listing site, findings, pest activity by station, products applied with concentration and registration number, technician licence and signature, plus recommendations and the next scheduled date. Reports are sent automatically through Odoo mail templates on visit completion, and the same records feed a portal view so a facilities manager can pull two years of certificates without emailing your office. Renewals run on an automated action that raises a renewal opportunity or draft quotation a configurable number of days before contract expiry, escalating by activity if nobody acts. Everything is reachable over XML-RPC and JSON-RPC, so a technician mobile app, an IoT bait-station feed or a client compliance portal can read and write the same records. Access is governed by ir.model.access.csv plus record rules — technicians see their own visits, supervisors see their branch, and restricted-use chemical data is limited to licensed roles.

This is a build-to-order product, not an existing download. We start with a short scoping call, agree the exact scope in writing, then build the module against your Odoo version (17.0, 18.0 or 19.0) and edition — the core targets Community, and Enterprise-only surfaces such as map and planning views are used only where you already hold Enterprise. Typical delivery is one working week from confirmed scope. You get the full source, installed and configured on a staging copy of your database first, a UAT round with a documented rollback plan, then production deployment, a training session and a post-go-live support window. The git repository is handed to you, so nothing here creates a lock-in you cannot walk away from.