Live operational snapshot — orders, fleet, and the most recent planning run.
Connect Dispatch Planner to your order management system via HTTP APIs. Configure authentication, map response fields, and test before activating.
Generate API keys to allow 3rd-party systems to push orders directly into Dispatch Planner.
| Name | Key (masked) | Created | Last Used | |
|---|---|---|---|---|
| Loading… | ||||
Include your API key in every request header:
X-API-Key: dp_your_key_here
{
"orders": [
{
"order_no": "SO-1001",
"customer_code": "CUST-01",
"customer_name": "ABC Store",
"lat": 25.2048,
"lng": 55.2708,
"delivery_slot": "Morning",
"slot_start": "08:00",
"slot_end": "12:00",
"service_time": 20,
"weight_kg": 150.5,
"notes": "Call before delivery",
"lines": [
{
"item_code": "ITEM-001",
"description": "Mineral Water 500ml",
"qty": 100,
"uom": "EA",
"weight_kg": 50.0,
"pallets": 0.5
}
]
}
]
}
curl -H "X-API-Key: dp_..." http://HOST/api/v1/orders
curl -X DELETE -H "X-API-Key: dp_..." http://HOST/api/v1/orders
Quickly populate master data and orders with plausible random values for testing — pick just the fields you need.
Random test orders from active customers/items — 1–5 line items each. Shows up on the Orders page.
Zone/Area, Slot, Gatepass, Service Duration, Priority Delivery, Permit Area.
Vehicle Type, Permit Area, Priority Delivery, Work Start/End Time, Max Route Distance, Avg Speed, Weight & CBM Capacity (CBM derived from weight).
UOM, Weight, Units per Carton, Carton Dimensions.
Dimensions (CBM computed automatically), Weight, Units per Carton.
Random past-delivery records (date range + service duration) so the planner has real history to learn each customer's average service time from.
Deletes all dispatched routes/orders and reverts their source orders back to pending so they can be re-planned.
Deletes every order from the queue on the Orders page. This cannot be undone.
Pull master data from an external SQL Server for testing — write a query, map its columns to Dispatch Planner fields, and sync. Matching records update; new records insert.
Run a plan from the Planner page to see results here.
Upload real past-delivery records (Order Number, Customer Code, Vehicle, Actual Delivery Time, Service Duration, Actual Delivery Geo Code). Whenever planning runs, a customer with at least one record here gets its real average service time used instead of the default estimate — customers with no history are unaffected.
Compares dispatched (planned) orders against uploaded real-world delivery outcomes, matched by order number. Orders with no actual-delivery record yet aren't shown — that's expected until Delivery History is updated for them.
| Plan Date | Order No | Customer | Plate | Planned Time | Slot | Actual Time | Planned Svc (min) | Actual Svc (min) | Delay (min) | Svc Variance (min) | Status |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Loading… | |||||||||||
Coming in the next sprint.
Coming in the next sprint.
Configure integrations used by the planning engine.
Lets a dispatcher give the planner a free-text instruction (via a local Gemma/Ollama model) to influence a run — e.g. excluding a vehicle or area. When turned off, the prompt box is hidden from the Run Planning dialog and no AI call is made, even if one was typed before.
Choose which service calculates real road distances/times for the planning engine. All three configs stay saved even when not the active provider, so you can switch anytime. Planning always uses real road distance — orders that can't get one (missing key/URL, API failure, group too large) are left unplanned rather than approximated with a straight line.
Paste the runtime key produced by DevExpress's devextreme-license CLI tool
(not your raw account key — that won't work and shouldn't be shared). Saving rewrites the
license file on the server; reload the page afterward for it to take effect.
Manage your own login credentials.
Create and manage user accounts. Only admins can sign users in — there is no public sign-up.
| Username | Full Name | Admin | Modules | Status | Last Login | |
|---|---|---|---|---|---|---|
| Loading… | ||||||
Login, logout, auto-login, and user-management activity. Newest first.
| Time | Event | User | IP Address | Details |
|---|---|---|---|---|
| Loading… | ||||
Order-processing counter for license reporting — one Save-as-Dispatched action counts every order in it.
| Time | Plan | Routes | Orders | Dispatched By |
|---|---|---|---|---|
| Loading… | ||||
Journey Plan at a glance — routes, shifts, customer coverage and visit patterns.
Split the year into sales weeks. Each week gets a sequence number in a rolling 4 or 5 week cycle, which visit patterns reference to decide when a customer is visited.
A route is a salesman's beat, and can run several shifts a day. Routes share the vehicle master with Dispatch: one scoped Journey Plan is yours alone, one scoped Both is the same record the Dispatch fleet uses.
Journey Plan's own customer list. These are separate from Dispatch's customers: one added here is visible only in Journey Plan, and Dispatch's are never listed here. Deleting one removes it along with its route mappings and visit patterns.
Map customers onto a journey route and set the order they are called on. Mandatory for journey planning — a customer not on a route is never visited.
How often each customer is visited on each route — visits per week, which days, and which weeks of the sales-calendar cycle.
Expand each customer's visit pattern across a date range, then sequence every route-day geographically by road. Preview first — it costs no routing-provider quota and shows how many calls the period implies.
Every journey plan generated so far, with its totals. Open one — it loads in its own tab as a read-only snapshot showing each route-day, its call sequence and timings, the map, and anything that could not be scheduled.
Generate mock Journey Plan data for testing — routes with their own geo fencing area, customers geocoded inside an area you choose, shift windows and week plans. Everything generated carries a code prefix, so it can all be cleared again without touching real master data.
Run these in order on a fresh install: routes first (so fencing areas exist), then customers, then route customers if they were not mapped as they were created, then week plans.
Mock routes scattered across an area, each with its own fencing circle, driver, working hours and optional shifts.
Customers geocoded inside a named area, a route's fencing area or a circle you draw — optionally mapped onto routes with week plans in one pass.
Map customers that already exist onto journey routes — by nearest fence, an even spread, or at random. Use this when customers were generated without mapping, added by hand, or need reassigning.
Move simulated customers onto the nearest real road. Scattered points often land in fields, which the Directions API refuses to draw a path from — snapping is what makes road routes drawable.
Give routes their daily shift windows — one full day, AM/PM, or three shifts. Routes that already have shifts are left alone.
Visit patterns for existing route–customer links: visits per week, which days, and which weeks of the sales-calendar cycle.
Deletes the routes and customers carrying the simulated prefixes, with their shifts, mappings and week plans. Real records are untouched.