A guarding company does not sell products, it sells covered hours at a post. The operations reality is that a client site has three posts, one of which is 24x7 on a two-shift pattern, another is nights only, and the third is armed and requires a specific licence class. A guard calls in sick at 22:40 and a reliever has to be found who is licence-valid, not already on duty, and not about to breach a weekly hours cap. At month end, finance has to invoice the client for exactly what was covered — including the double-time public holiday shift and minus the four hours nobody turned up for — and pay the guards from the same underlying attendance. Stock ERPNext has none of this shape. There is no DocType that means "a post that must be manned from 19:00 to 07:00 by a guard holding licence class B". Shift Type and Shift Assignment model an employee's working pattern, not a customer-facing coverage obligation; Attendance is a per-employee day record with no link to a client site or a billable contract line; and the Employee doctype has nowhere to hold licence numbers with expiry dates that must block rostering. Companies end up running the roster in a spreadsheet, the patrol log on WhatsApp, and the invoice by hand — and the three never reconcile.

What ECOSIRE builds is a proper Frappe app (its own repo, its own module, installed with bench get-app and bench --site ... install-app) that sits on top of ERPNext rather than forking it. The core DocTypes are Guard Site (the client location, linked to the ERPNext Customer), Guard Post (a child-table-driven set of coverage requirements per site: post name, days, start and end time, headcount, required licence class, armed/unarmed, billing rate reference), Guard Roster (a period-scoped plan that generates Roster Shift rows for every post-day in the range), Roster Shift (one guard, one post, one dated shift, with status draft/published/confirmed/covered/uncovered), Relief Request (an open shift plus the reason and the replacement decision), Patrol Checkpoint and Patrol Log, and Security Incident with a severity workflow and attachments. Guard licences live in a Guard Credential child table on Employee with an expiry_date, so validation is data, not tribal knowledge.

The logic lives where Frappe expects it. A validate hook on Roster Shift rejects an assignment when the guard has an overlapping shift, an expired or missing credential for the post's required class, or would exceed the configured weekly-hours or consecutive-nights limit — each check is an individual frappe.throw so the planner sees exactly which rule bit. hooks.py doc_events on Attendance and on the app's own Duty Confirmation keep the roster and the attendance record in agreement, and on_submit of the shift period writes the Attendance rows ERPNext payroll already reads, so Salary Slip generation via the standard Payroll Entry works with no parallel payroll engine. Billing is generated from the same verified rows: a server-side method rolls covered hours per site and per rate band into a draft Sales Invoice with one item line per post and per band, honouring the customer's contract rates held on a Guard Service Contract DocType, so a shortfall in coverage is visibly credited rather than silently invoiced. Field capture is over the Frappe REST API and whitelisted methods (@frappe.whitelist()), so a supervisor's phone or an existing NFC/QR patrol device can post a checkpoint scan with a timestamp and geolocation; a scheduler_events hourly job flags checkpoints that were due and never scanned, and a daily job raises credential-expiry warnings 30/14/7 days out. Client scripts add the roster grid's colour-coded coverage view and the one-click relief search. Role profiles separate Operations Manager (publish rosters, approve reliefs), Site Supervisor (patrol and incident entry for assigned sites only, enforced with a user-permission-backed get_permission_query_conditions hook), Payroll, and Accounts — a supervisor cannot see another client's sites, and cannot touch a rate.

Everything is built against Frappe/ERPNext v15 and v16, and we build for the version you actually run — we do not ship a v14 app with a compatibility note. Optional extensions we regularly scope alongside the core: geofenced clock-in, overtime and public-holiday rate rules, subcontracted-guard cost tracking, a client portal page where the customer can see their own coverage and incident reports, and export files for a specific national licensing regulator.

This is build-to-order, and we are explicit about what that means. There is no ZIP to download today. You book a scoping call, we walk your actual sites, shift patterns, rate cards and licensing rules, and we come back with a fixed scope and a fixed price. Typical delivery is two to four weeks from confirmed scope for a core build, longer if the scope includes a mobile field client or an integration with a third-party access-control or biometric system. We build on a staging bench, you run UAT there against your own data, and only then do we install on production with a documented rollback. You receive the git repository — the code is yours, and you are never locked to us to maintain it.