Delphi job planning: fleet API and offline sync for field work

Planning state and map teams drifted apart

Dispatch had run reliably in Delphi on office PCs for years. Field teams used smartphone maps with positions from an external fleet portal.

Without a proper interface this meant duplicate entry, estimated arrivals, and stale status in the planning screen.

Dispatch needs mileage and ETA from one source—not phone and map app.

Connectivity gaps and long days outdoors

Outside stable mobile coverage, sync must not block or lose data. Evening catch-up had to merge without corrupting orders.

Seasonal peaks with many parallel jobs stress queue and fleet API simultaneously.

Drivers run evening catch-up syncs—conflict rules must resolve office and field updates cleanly.

Target state: fleet actuals inside the Delphi shell

Office and field should share job status, mileage and arrival times—with an offline-capable queue and without replacing the trusted planning UI.

Dispatch should plan routes on actual data, not estimated phone calls.

Pilot region validates queue under real harvest and transport peaks.

Drivers confirmed in workshops that status text is understandable without UI change.

Dispatch needs warnings when queue is full before next-day route planning.

OpenAPI eases adjustments when fleet API updates without Delphi core changes.

REST adapter with a local queue

We wrapped the fleet API in a module with retries, timeouts, and structured errors. Each planning workstation keeps a local queue: updates enqueue and upload idempotently when online.

Delphi remains the source for jobs and priorities; map data is read-only and surfaced as clear status text.

Extension under our Delphi development service; integration patterns in the legacy modernisation blog category.

Phase 1: pilot region and queue validation

A pilot region tested sync under real connectivity gaps; SQLite queue and conflict rules were hardened against evening catch-up.

OpenAPI documentation eases adjustments when the fleet API changes.

Load tests simulated harvest peaks with parallel sync jobs per planning workstation.

Dispatch receives warnings when queue is full before next-day route planning.

Conflict rules and monitoring

Explicit rules decide whether office or last field update wins. Lightweight monitoring shows pending jobs and failed calls—support can intervene precisely.

Fleet API error codes appear as plain-language status in the planning screen.

Manual retry is possible without core database intervention.

When the queue is full, dispatch must see it—not only the next morning.

Fewer calls, more reliable ETAs

Dispatch and field share mileage and arrival times without replacing the core system. Regional rollout validated queue behaviour.

Capacity and routes can be aligned on shared data; training stayed lean because the UI did not change.

ETA callbacks dropped measurably in the pilot region.

Support hotline sees queue status per planning workstation without remote intervention.

KPIs after pilot and rollout

ETA callbacks dropped measurably in the pilot region; pending sync jobs are monitored instead of chased by phone.

Dispatch uses mileage and ETAs from fleet API without duplicate entry in map apps.

Queue logic survived harvest peaks and evening catch-up in the pilot region.

OpenAPI eases adjustments when fleet API updates without Delphi core changes.

Short guides for new status fields reduced training effort because the planning UI stayed unchanged.

Load tests simulated harvest peaks with parallel sync jobs per workstation before broad rollout.

Delivery and support by Groenewold IT Solutions in Leer (East Frisia)—Delphi extension Made in Germany for agricultural contracting.