Rides & planning

A ride is a vehicle/operator’s planned route for a period — the planning-level object that groups a driver’s tasks together, separate from the orders themselves.

When to use

Situation	Command
Retrieve planned rides with their tasks	RequestRides
Retrieve rides with a lighter task shape (legacy)	RequestRidesCompact — legacy, prefer RequestRides
Create or update a ride’s planning	StoreRides
Change only a ride’s start/end window	StoreRideTimeWindows — WorldLink Connector-only, see below
Add a non-order task to a ride (break, rest, linking)	StoreRideNonOrderTask
Get a ride’s last-known GPS position	RequestLastRidePositions (requires the Live Positions module)

Retrieve

Retrieving rides

<?xml version="1.0" encoding="windows-1252"?>
<EoCustomLinkRequestRides Type="TEoCustomLinkRequestRides">
  <Nested>False</Nested>
  <Filter Type="TEoFilterPlannerMaster">
    <PeriodBegin>2026-07-22T00:00:00</PeriodBegin>
    <PeriodEnd>2026-07-23T00:00:00</PeriodEnd>
  </Filter>
</EoCustomLinkRequestRides>

Filter field	Type	Description
PeriodBegin	dateTime	Inclusive begin of the period. Optional.
PeriodEnd	dateTime	Inclusive end of the period. Optional.
JobIdsAsCsv	string (CSV)	Only rides created for these order-import jobs.
RideName	string	Only rides with this (manual) name.
KeysExplicitAsCsv	string (CSV)	Explicit ride database Ids.

PeriodBegin/PeriodEnd: no period filter, not today, if omitted

Unlike orders, leaving PeriodBegin/PeriodEnd unset (or at the zero-sentinel value 1899-12-30T00:00:00) does not default to today’s rides — it removes the period restriction entirely, so the request can return rides across the whole database. Always set both fields explicitly when you want to limit the result to a specific window.

RequestRidesCompact is legacy

RequestRidesCompact still returns ride identity, timing, addresses, and operator/vehicle/material assignment (OperatorId, OperatorIdSub, VehicleId, MaterialId/MaterialId2/MaterialId3) — it is not limited to just ride Ids. What it omits is VehicleNo, actual distance/duration (DistanceActualInKms/DurationActualInHours), Reference, the RideOptimized/RideCalculated flags, and it uses a lighter task shape (fewer fields per task, no task-type name). It’s kept for backward compatibility — use RequestRides for new integrations.

Response fields (TEoCustomLinkRide)

Field	Type	Description
Id	int	Database Id of the ride.
NameManual	string	The (manual) name for this ride.
MomentStart / MomentEnd	dateTime	Start and end of the ride.
OperatorId	int	Id of the operator assigned to the ride.
VehicleId	int	Id of the vehicle assigned to the ride.
MaterialId / MaterialId2 / MaterialId3	int	Ids of up to three materials/trailers on the ride.
AddressStart / AddressEnd	address	Starting and ending address of the ride.
Tasks	list	The tasks in this ride. Ignored when storing.
RideTypeId	int	Ride type. 0 = empty or tenant default.
RideOptimized / RideCalculated	boolean	Whether the route has been optimized/calculated.
DistanceInKms / DurationInHours	decimal	Planned distance/duration.
DistanceActualInKms / DurationActualInHours	decimal	Actual distance/duration driven.
JobId	int	Id of the order-import job this ride belongs to, if any. Do not use unless instructed otherwise by MendriX — leave 0 as the safe default.
Reference	string	External reference for this ride.

Scenarios

Scenario: retrieve today’s rides. Set PeriodBegin/PeriodEnd to today’s date range and omit JobIdsAsCsv/RideName/KeysExplicitAsCsv to get every ride active in that window.

Scenario: retrieve a specific named ride. Set RideName to the manual ride name (e.g. Henk) instead of a period, if you know the name and don’t need to filter by date.

Store

Creating or updating a ride

<?xml version="1.0" encoding="windows-1252"?>
<EoCustomLinkStoreRides Type="TEoCustomLinkStoreRides">
  <Data Type="TEoCustomLinkRideList">
    <_TEoListBase_Items>
      <EoCustomLinkRide Type="TEoCustomLinkRide">
        <Id>-1</Id>
        <JobId>0</JobId>
        <NameManual>Ride 230</NameManual>
        <MomentStart>2026-07-22T10:00:00</MomentStart>
        <MomentEnd>2026-07-22T22:00:00</MomentEnd>
      </EoCustomLinkRide>
    </_TEoListBase_Items>
  </Data>
</EoCustomLinkStoreRides>

An Id of zero or less creates a new ride; a positive Id updates one. Do not use JobId unless instructed otherwise by MendriX — leave it at 0 as the safe default. See the field table under the Retrieve tab above — the same TEoCustomLinkRide shape is used for both directions.

Response uses the shared EoStoreResultList shape:

<?xml version="1.0" encoding="windows-1252"?>
<EoStoreResultList Type="TEoStoreResultList">
  <_TEoListBase_Items>
    <EoStoreResult Type="TEoStoreResult">
      <Id>30</Id>
      <IdOld>-1</IdOld>
      <RowsAffected>1</RowsAffected>
      <StoreDescription></StoreDescription>
      <StoreDetail>0</StoreDetail>
      <StoreResult>srInserted</StoreResult>
    </EoStoreResult>
  </_TEoListBase_Items>
</EoStoreResultList>

Changing only the time window

StoreRideTimeWindows moves a ride’s start/end without touching anything else — but in practice it is WorldLink Connector-only, not a general integrator command.

This command is not usable by a typical SOAP integration

StoreRideTimeWindows always requires JobInfoOrderImport.JobId to reference an active order-import Job — there is no way to omit it or pass 0, unlike StoreRides (see below). But there is no SOAP command to create a Job or upload a file; Jobs only exist because MendriX’s own WorldLink Connector creates them internally while processing a file uploaded through the WorldLink web UI. In that flow, when one import batch spans multiple orders sharing the same ride name, the Connector creates the ride once via StoreRides and then calls StoreRideTimeWindows for every later order in the same batch to stretch that ride’s window to cover the new task — all tagged with the same active JobId so only the still-running import may touch it. Outside that flow, you have no way to obtain a JobId that will pass the active-job check, so this command has nothing to act on. See the Command reference for the same note on the Jobs command family this depends on.

If you’re building order intake, use StoreOrdersNormal directly — it doesn’t require any JobInfoOrderImport tag, and rides are planned separately in the MendriX TMS UI.

Adding a non-order task to a ride

StoreRideNonOrderTask (payload TEoCustomLinkRideNonOrderTask, response a single, bare EoStoreResult — not the list-wrapped EoStoreResultList used by StoreRides/StoreRideTimeWindows) inserts, updates, or repositions a non-order task on a ride — used for breaks, rest periods, or manually linking/unlinking a task’s position within the ride’s sequence. This is distinct from order tasks (pickup/delivery), which come from StoreOrdersNormal instead.

StoreRideNonOrderTask hard-rejects bad input

Unlike StoreRides/StoreRideTimeWindows, StoreRideNonOrderTask does not use the soft per-item srError pattern. An unknown RideId, unknown task Id, wrong task type, a missing reference task, or invalid material each raise an exception that is not caught — the whole call fails rather than returning a per-item error result.

Scenarios

Scenario: create a new ride for tomorrow. Send StoreRides with Id=-1, MomentStart/MomentEnd set to tomorrow’s window, and NameManual set to your own label. The response’s IdOld=-1 pairs with the new positive Id.

Scenario: extend an existing ride’s end time. Retrieve the ride via RequestRides to confirm its current Id, then send StoreRides with the full ride and a later MomentEnd — StoreRideTimeWindows looks like a lighter-weight option for this, but it’s WorldLink Connector-only (see above), so a normal integration should use StoreRides instead.

Gotchas

• Ride Id-not-found is a soft per-item error, not a rejection — for StoreRides/StoreRideTimeWindows only — unlike orders, there is no “must have been requested first” enforcement for rides. A store to an unknown Id returns srError in the result list rather than failing the whole request. StoreRideTimeWindows also has its own unconditional active-job precondition — see the caution above.
• StoreRideNonOrderTask hard-rejects the whole call on bad input — unlike StoreRides/StoreRideTimeWindows, an unknown RideId, unknown task Id, wrong task type, missing reference task, or invalid material raises an exception and fails the entire call. It does not use the soft per-item error pattern described above.
• RequestLastRidePositions requires the Live Positions module license — it returns an error for tenants without it.
• Still recommended (not enforced): retrieve a ride before updating it, same reasoning as orders — a store call replaces fields you don’t include.

Related commands

• GdxEoStructures.xsd — TEoCustomLinkRide, TEoFilterPlannerMaster field definitions.
• Order intake — orders are planned onto rides but are a separate entity.