All posts
Integrator10 min read

Odoo Field Service: work orders, planning, mobile app, and customer invoicing

Odoo Field Service manages technician dispatch, on-site work orders, parts consumption, and customer sign-off. This guide covers the configuration, scheduling workflow, mobile app capabilities, parts management, and the invoicing integration that closes the service-to-cash loop.

Odoo Field Service bridges the gap between customer support and on-site work execution. A ticket comes in, a technician is dispatched, they perform work and consume parts on site, and the customer signs off - all feeding back into accounting and inventory without manual re-entry. When it's configured correctly, it eliminates the paper-based work order process that plagues most service companies.

Core data model#

The primary record is project.task - Field Service reuses the project management task model with additional fields. Every field service work order is a task in a dedicated field service project.

Key fields added by the Field Service module:

FieldPurpose
fsm_location_idSite where the work will be performed
planned_date_beginScheduled start date/time
planned_date_endScheduled end date/time
user_idsAssigned technicians (multiple allowed)
timesheet_idsTime logged on the work order
material_line_idsParts consumed during the job
customer_signatureBinary field for captured signature
worksheet_template_idOptional custom form for structured field data

Locations#

Field service locations (fsm.location) represent physical sites where work is performed. Locations can be hierarchical (a building with multiple floors, each with rooms). This matters for routing - the planning Gantt can filter and group by location.

Each location has a contact (res.partner) and optionally a parent location. Locations are reusable - a recurring customer site is configured once and referenced on every work order for that site.

Planning and scheduling#

The planning view in Field Service is a Gantt chart showing technicians on the Y axis and time on the X axis. Work orders appear as bars at their scheduled time. Drag to reschedule; resize to adjust duration; drag to a different row to reassign.

Work time and capacity#

Technicians appear in the Gantt only if they have a work schedule configured (resource.calendar on res.users). Without a work schedule, the technician has no availability shown and cannot be used for capacity planning.

The Scheduling view in Field Service → Planning shows a map alongside the Gantt when addresses are geocoded. For route optimization (visiting multiple sites in one day in the most efficient order), Odoo provides basic distance-based sorting but not full routing optimization. Third-party integrations (Google Maps API, HERE) are needed for turn-by-turn dispatch routing.

Work order lifecycle#

New → In Progress → Completed → Validated → Invoiced

New - created by customer portal, helpdesk ticket conversion, or manual creation.

In Progress - technician has started work. The mobile app triggers this state change.

Completed - technician marks the job done from the mobile app. Customer signs off (optional, depending on configuration). Parts consumption is finalized.

Validated - office staff reviews and validates the completed work order. This step triggers the timesheet and parts transfers to be invoiced.

Invoiced - the sale order or invoice has been generated from the work order.

Mobile app#

The Odoo Field Service mobile app (available on iOS and Android) gives technicians access to their work orders without a laptop. Key capabilities:

  • View today's scheduled work orders and navigate to the site
  • Start and stop timers for time tracking
  • Scan barcodes to consume parts from inventory
  • Capture customer signature
  • Mark work orders complete
  • Take photos and attach to the work order

The app works offline - timers keep running and data is queued when connectivity is lost, syncing when the network is restored. This is critical for technicians in basements, manufacturing plants, or remote sites.

Configuration requirement: technicians must have a portal or internal user account. The app logs in with their Odoo credentials.

Parts management#

Parts used on a job are tracked in material.line records on the task. When the technician marks parts consumed, Odoo can:

  1. Record consumption without inventory move - simplest setup; just records what was used for invoicing. No warehouse management.
  2. Create inventory move from a warehouse to the site - tracks actual stock movement. Reduces inventory in the source warehouse.
  3. Use a van/technician stock location - each technician has a virtual warehouse. Parts are pre-loaded into their van location; the job consumes from the van.

The van stock model is the most accurate for companies with technician-owned inventory. Configure it via Inventory → Configuration → Warehouses → create a warehouse per technician (type: field service).

Returning parts#

Parts that were taken to the site but not used can be returned. Field Service supports return moves in the same framework - the technician marks un-consumed parts and Odoo creates a reverse inventory move back to the source warehouse.

Worksheets#

Custom worksheets (worksheet.template) let you add structured data capture to a work order - reading values from equipment, checklists, measurements. The worksheet is configured in Field Service → Configuration → Worksheet Templates.

Each worksheet template defines sections and fields (text, numeric, checkbox, date). When a technician opens the work order in the mobile app, the worksheet appears as a form they fill out on-site. Completed worksheets are stored on the task and can be printed as a service report.

This replaces paper-based service forms for industries like HVAC, electrical maintenance, and medical equipment calibration.

Customer portal and sign-off#

Customers can track their work orders through the customer portal at /my/tasks (if task portal is enabled). They see the status, assigned technician, and scheduled time.

Customer signature is captured either through the mobile app (technician shows their phone) or through a portal link sent to the customer after completion. The signature is stored as a binary image on the task and printed on the service report PDF.

Requiring a signature before marking a work order complete is a configuration option per project (Field Service → Configuration → Projects → Require Signature).

Invoicing#

Field Service work is invoiced through the Sales module. The connection point is the sale_line_id on each task and material line.

Three invoicing models:

Fixed price - a sale order line with a fixed amount is created when the work order is assigned. Time and parts are tracked for cost analysis but do not affect the invoice amount.

Time and materials - timesheets logged on the work order generate invoiceable sale order lines at the employee's billing rate. Parts consumed also generate lines at the product's sale price. The invoice total varies by actual work done.

Milestones - invoice a predetermined amount when specific stages are reached (e.g., "deposit on creation, balance on completion").

The invoicing model is set per project. For a service company with both quoted jobs and time-and-materials work, use separate Field Service projects with different billing configurations.

Common mistakes#

No work schedule on technicians. The planning Gantt shows no availability, capacity planning is impossible, and timesheet analysis is inaccurate. Every technician needs a resource.calendar.

Forgetting to validate work orders before invoicing. A completed but unvalidated work order does not transfer its timesheet lines to the sale order. Accountants run the invoice batch and the time is missing. Add a validation step to your end-of-month process.

Parts on work orders not linked to sale order lines. If the material lines are not configured to create sale order lines (project billing type mismatch), parts are recorded but never invoiced. Verify the project's billing type matches the intended invoicing behavior.

Site location address not geocoded. The map view and routing features work only with geocoded addresses. Odoo geocodes addresses through a configured provider (Google Maps, OpenStreetMap). If the provider key is not set or the address is incomplete, the pin doesn't appear on the map.


For the helpdesk integration that generates field service work orders from support tickets, see the helpdesk guide. For timesheet and project billing that field service relies on, see the project management guide.

Try ERPeek on your own Odoo module - ask questions, scaffold tests, and explore your codebase in plain language.

Get started free