# Field service management software built around the van, not the office Canonical: https://erpfly.com/modules/field-service/ Last updated: August 27, 2026 Category: Service Your technicians are on the road with a phone, a job sheet and a van full of parts that the stock report thinks are still in the warehouse. Field service management software only earns its keep when that job sheet turns into stock movements and an invoice without someone retyping it. erpfly builds that into ERPNext or Odoo from a plain description of how your jobs run. ### Features - **Dispatch by zone and skill.** Jobs land on a board filtered by the technicians who hold the right certification and cover that postcode. Dispatch drags, the tech gets notified. - **A job screen made for a phone.** Big buttons for arrived, left and done. The fields the tech doesn't need are hidden, so the form fits on one screen without zooming. - **Van stock that matches the van.** Each van is a warehouse or stock location. Parts used on a job move out of that van, not out of the main store. - **Signature before sign-off.** A job can't be marked done without a customer signature and a short work note. Disputes about whether someone turned up get shorter. - **Billing rules written down once.** Rounding, minimum call-outs, after-hours rates and contract exclusions live in code with tests, not in the head of whoever does invoicing. ### What gets generated **ERPNext / Frappe app:** - Field Job DocType linked to Maintenance Visit and Serial No - Technician Zone and Technician Skill DocTypes - Stock Entry posting from each van warehouse - Sales Invoice creation on job completion (doc_events) - Mobile-friendly web form for technicians **Odoo addon:** - project.task inheritance with site, arrival, departure and signature - Parts used lines posting stock.picking from the van location - Billable time rules on sale.order.line - Dispatch calendar and list views (list, not tree, on Odoo 18+) - Technician form view with invisible="..." field rules - ir.model.access.csv rules for technicians and dispatch ### What field service management software has to get right Every field service business thinks its jobs are unusual. Most of the time the shape is the same. A customer calls, someone books a slot, a technician drives out, does the work, uses some parts, and somebody eventually sends an invoice. The expensive failures happen at the joins. The booking didn't say the unit is on a roof. The part came out of the van but the stock report still shows it in the warehouse. The invoice went out three weeks late, with the wrong labour hours, because the job sheet was a photo of a paper form. Good field service management software is mostly about those joins. The scheduling screen matters less than people expect. ### What you're building on ERPNext has no dedicated field service app. What it does have is useful: **Maintenance Schedule**, **Maintenance Visit**, **Warranty Claim** and **Serial No**, all tied to Customer and Item. We normally add a job DocType on top that links to those, plus van warehouses and a stripped-down form for technicians. On Odoo, the **Field Service** app is Enterprise and sits on top of Project, so a job is a `project.task` with extra behaviour. On Community there's no field service app at all, so we inherit `project.task` directly. That's what the snippet on this page does. The same approach works on Enterprise if you want your own close-out rules layered over the stock ones. Van stock deserves a mention on both platforms. Each van becomes its own warehouse in ERPNext or its own internal location in Odoo, with a weekly replenishment transfer from the main store. It's a small change with an outsized effect, because it's usually the first time anyone can see what's actually rattling around in the back of each vehicle. ### Following one job from phone call to invoice Here's a heating and cooling contractor with 9 technicians split across a north and a south zone. A café calls at 9:15 about a split unit that's blowing warm air. Dispatch books it for the south zone. Only 4 of the south techs are certified for refrigerant work, so the board shows only those 4. Dan gets it. He marks arrival at 11:05 and departure at 12:40. That's 1 hour 35 minutes on site. Labour bills in 15 minute blocks, rounded up, so it becomes 1.75 hours at $95, or $166.25. The $120 minimum call-out doesn't apply, because the labour is already higher. He swaps a filter ($38) and a run capacitor ($24) from van stock. Those two lines move out of the south van's stock location, not the main warehouse. The café manager signs on his phone. Dan hits done. The invoice is drafted straight away at $228.25 before tax. The office checks it and sends it before lunch, not at month end. Nothing in that flow is clever. It just happens without anybody copying numbers from one screen to another. ### Offline, GPS and the other caveats Two questions come up on nearly every call, and we'd rather answer them straight. **Offline.** ERPNext and Odoo run in the browser. With no signal, the form won't save. Most technicians update at the van and that's fine. If yours spend whole days in tunnels or rural sites, budget for a proper offline app later. Don't pretend the web form will cover it. **GPS.** We'll pull data from your tracker's API: arrival confirmations, mileage, maybe last known position. Rebuilding a live fleet map inside the ERP is a poor use of money when the tracker already does it well. The [fleet management module](https://erpfly.com/modules/fleet-management/) covers the vehicle side. ### Things we'd leave out of version one Automatic route optimisation, for one. Dispatchers who know the city beat most solvers for a team of nine, and the solver will cost more than the vans. Customer self-booking into technician calendars is another. It sounds great until three people book the same slot on a Monday morning. Start with a request form and let dispatch confirm. And resist 40-question inspection checklists on the phone. Techs will tap through them without reading. Pick the eight that matter for liability. ### Where the job data ends up A field job pulls from, and writes to, a lot of the ERP. Parts come out of [inventory](https://erpfly.com/modules/inventory-management/). Faults often start as tickets in a [helpdesk](https://erpfly.com/modules/helpdesk/). The finished job becomes an entry in [invoice management](https://erpfly.com/modules/invoice-management/). If you're on Odoo and need changes to an existing Project or Field Service setup, [Odoo customization](https://erpfly.com/odoo-customization/) explains how we approach it. ### FAQ ### Do technicians need signal to use it? For the standard ERPNext or Odoo web interface, yes. Most teams cope because they update at the van, not in the basement plant room. If you work somewhere with no coverage for hours, tell us early, because an offline-capable app with a sync queue is a bigger and separate piece of work. ### Can it show where technicians are on a map? We can pull positions from your vehicle tracker's API and store the last known location against each technician. We'd usually leave the live moving map in the tracker's own app and bring only arrival times and mileage into the ERP. ### Odoo already has Field Service. Why build? Odoo Field Service is an Enterprise app, so it isn't an option on Community. On Enterprise it's a good base and we'd extend it rather than replace it. Most of what we add is billing rules, van stock and checklists specific to your trade. ### We use a separate job app today. Can we migrate? Usually, yes. Customers, sites, equipment and open jobs come across through an import script. Completed job history can come too, though many teams import only the last year or two and archive the rest as PDFs. ### Who owns the code if we stop paying? You do. It's a Frappe app or Odoo addon in your own repository. The technicians won't notice if you cancel erpfly, which is how it should be.