A guarding company does not sell products or project hours — it sells covered posts. A client contract says "two unarmed guards at Gate A, 24/7, plus one supervisor on the day shift", and every operational and financial question follows from whether those posts were actually manned. Odoo out of the box has no idea what a post is. You can approximate a roster in Planning (Enterprise only), record hours in Attendances, and raise an invoice in Sales, but nothing joins them: the control-room WhatsApp group decides reliefs, a spreadsheet tracks who covered which site, patrol sheets stay on paper at the guardhouse, and at month-end someone reconciles three sources by hand to answer "did we bill this client for hours we never covered, and did we pay a guard for a shift he did not work?". That reconciliation gap is where guarding companies lose margin and where contract disputes start.

This module adds the missing operational spine as proper Odoo models. A security.site record carries the client res.partner, geolocation, site instructions and contract reference; each site owns security.post lines that define required coverage — post name, shift pattern, headcount, required guard grade or licence class, and armed/unarmed flag. A roster generator expands post requirements into security.shift records across a date range, and assignment links each shift to an hr.employee guard, validating with a Python constraint that the guard holds a valid, unexpired licence for that post type and is not already booked on an overlapping shift. Relief and absence handling is a first-class flow, not a note: an unfilled or abandoned shift moves to a relief_required state, an automated action escalates it to the duty supervisor, and the replacement is recorded with a reason code so the reason a post went uncovered survives into reporting. Patrol and incident capture is a security.patrol.log model with checkpoint lines, timestamps and photo attachments, and a security.incident model with severity, category, narrative, and a QWeb PDF incident report you can hand a client the same day.

The financial half is what makes it pay for itself. Actual shift hours — worked, not planned — feed two directions. Toward payroll, a wizard aggregates approved shifts per employee per period into attendance or payslip input lines (hr.payslip.input on the Enterprise payroll stack, or a clean export for whatever payroll you run), with configurable rules for overtime, night differential and public-holiday premiums. Toward revenue, contract billing computes each period's invoiceable amount from the billing model you actually use: fixed monthly rate per post, hourly rate by guard grade, or a hybrid with deductions for uncovered hours. The billing wizard produces a draft account.move with one line per site and post, plus a QWeb backup schedule listing every shift billed — the annexure your client's procurement team asks for. Everything is standard Odoo underneath: ir.model.access.csv plus record rules so a site supervisor sees only their own sites while operations managers see the region, @api.depends computed fields for coverage percentage and unfilled-hours totals, and the XML-RPC/JSON-RPC API left open so an existing guard-tour device, biometric clock or client portal can post checkpoint scans straight into the log.

We build this to order for your Odoo 17.0, 18.0 or 19.0 database and your actual contracts. Nothing here is a pre-built download — the module ships after a scoping call in which we walk through your site types, shift patterns, licence classes, overtime rules and how each client contract prices coverage, because those five things differ enough between guarding companies that a generic module would be re-written anyway. Typical delivery is 2 to 4 weeks from confirmed scope. It runs on Odoo Community where possible; features that depend on Enterprise apps — notably the payroll payslip integration and Planning-style Gantt views — are flagged during scoping so you know exactly what your edition supports and what we deliver as a Community-safe alternative. You receive the full source, deployed and tested on a staging copy of your database before it touches production.