# How it works: the model

Understanding four concepts is enough to use the plugin correctly.

### 2.1 A route contains several tickets

A **route** is a day's itinerary: one technician, several stops. Each **stop** corresponds to one GLPI ticket that has a location assigned. The plugin decides the best order in which to visit them.

A route is not tied to a single ticket — it groups all the tickets the technician plans to visit in that journey.

### 2.2 Two different timers

The plugin measures two things that must not be confused:

- **Waypoint (travel):** the trip from where the technician is to the ticket's location. Starts when the technician taps *Start* before setting off, and stops on arrival.
- **ActualTime (work):** the time spent actually resolving the ticket on site. It starts **automatically** the moment the technician stops the travel timer, and is recorded against the ticket through the ActualTime plugin.

<div id="bkmrk-notethe-two-never-ru" style="display:flex;gap:12px;margin:18px 0 20px;padding:13px 16px;border:1px solid #DCD5C3;border-left:4px solid #14504A;background:#E3EEE9;border-radius:4px;max-width:66ch;"><div style="flex:none;font-size:11px;font-weight:700;text-transform:uppercase;letter-spacing:0.08em;color:#14504A;padding-top:2px;">Note</div><div>The two never run at the same time: stopping the travel timer is what starts the work timer.</div></div>### 2.3 Route versions

A route can be modified while it is in progress — adding a stop, removing one, or reordering. Each modification creates a **new version** of the route instead of overwriting it. The web interface keeps the complete version history, so it is always possible to see what was originally planned and what actually happened.

### 2.4 Four distance and time metrics

Each stop stores several measurements. They answer different questions and are **not interchangeable** — this is the part most worth understanding before reading any report.

<table border="1" id="bkmrk-metric-what-it-measu" style="border-collapse: collapse; width: 100%;"><thead><tr style="background-color: #f5f5f5;"><th style="padding: 8px; text-align: left;">Metric</th><th style="padding: 8px; text-align: left;">What it measures</th><th style="padding: 8px; text-align: left;">Where it comes from</th></tr></thead><tbody><tr><td style="padding: 8px;">**Actual**</td><td style="padding: 8px;">What the technician really travelled on that leg.</td><td style="padding: 8px;">Measured between the GPS position where the trip started and where it ended.</td></tr><tr><td style="padding: 8px;">**Leg planned**</td><td style="padding: 8px;">What Google predicted for *that single leg*, when the trip started.</td><td style="padding: 8px;">Google, calculated at the moment the technician sets off.</td></tr><tr><td style="padding: 8px;">**Route planned**</td><td style="padding: 8px;">What Google predicted for the *whole optimised route*. Identical for every stop of the same route.</td><td style="padding: 8px;">Google, calculated once when the route is created.</td></tr><tr><td style="padding: 8px;">**Billing**</td><td style="padding: 8px;">What is charged to the customer for the trip. **Not a measurement of the journey.**</td><td style="padding: 8px;">Distance from the base to the ticket (doubled if return-trip billing is enabled).</td></tr></tbody></table>

**Why *Actual* and *Leg planned* can differ a lot:** the estimate assumes a vehicle following the road network from the previous point, while the real measurement reflects what actually happened — a short walk between two nearby sites, a detour, or traffic. A large gap is information, not necessarily an error.

**Why *Billing* is separate:** it always measures base → ticket, regardless of the order in which stops were visited. This keeps invoicing predictable and independent of the route the technician happened to follow that day.