Order retrieval & sync

Retrieving orders is a two-step process: first ask for matching Ids, then request the full data for those Ids.

When to use

Situation	Command
Find which orders match a filter (date range, client, operator)	RequestOrdersNormalIds
Get the full XML for specific known Ids	RequestOrdersNormal
Poll for only what changed since your last check	RequestOrdersNormalIds with SequenceMinimum
Create a new order	StoreOrdersNormal instead
Change an existing order	StoreOrdersNormal instead

Step 1 — request matching Ids

<?xml version="1.0" encoding="windows-1252"?>
<EoCustomLinkRequestOrdersNormalIds Type="TEoCustomLinkRequestOrdersNormalIds">
  <Nested>False</Nested>
  <Filter Type="TEoFilterOrdersNormal">
    <PeriodBegin>2026-07-01T00:00:00</PeriodBegin>
    <PeriodEnd>2026-07-31T00:00:00</PeriodEnd>
    <ClientNo>110</ClientNo>
    <OperatorId>-1</OperatorId>
  </Filter>
</EoCustomLinkRequestOrdersNormalIds>

Filter field	Meaning
PeriodBegin / PeriodEnd	Inclusive date range. Defaults to today if omitted.
ClientNo	Client’s database key. -1 = no client filter.
OperatorId	Single Id or CSV list (e.g. 130,131,152). -1 = no operator filter.
KeysExplicitAsCsv	Explicit order Ids instead of a period/client/operator filter.
SequenceMinimum	Only return orders with Sequence at or above this value — see incremental sync below.
IgnShowAlways	Whether always-visible (ShowAlways) orders bypass the period/client/operator filters. Unrelated to SequenceMinimum/SequenceMaximum, which are always applied regardless of this flag. Per the schema, normally True for retrieval (default is False).

The response returns matching Ids plus a SequenceMaximum:

<?xml version="1.0" encoding="windows-1252"?>
<EoCustomLinkResponseOrdersNormalIds Type="TEoCustomLinkResponseOrdersNormalIds">
  <Data Type="TEoKeyIntList">
    <SequenceMaximum>7086</SequenceMaximum>
    <_TEoListBase_Items>
      <EoKeyInt Type="TEoKeyInt"><Id>349</Id></EoKeyInt>
      <EoKeyInt Type="TEoKeyInt"><Id>371</Id></EoKeyInt>
    </_TEoListBase_Items>
  </Data>
</EoCustomLinkResponseOrdersNormalIds>

Step 2 — request the full order data

<?xml version="1.0" encoding="windows-1252"?>
<EoCustomLinkRequestOrdersNormal Type="TEoCustomLinkRequestOrdersNormal">
  <Nested>False</Nested>
  <Filter Type="TEoFilterOrdersNormal">
    <KeysExplicitAsCsv>349,371</KeysExplicitAsCsv>
  </Filter>
</EoCustomLinkRequestOrdersNormal>

Don't request too many at once

Experiment with server load and response time for your tenant; request orders one by one where possible, and never in one giant batch. See Custom Link: rules of engagement.

Response fields (TEoOrderMx)

The full order XML returned here uses the same TEoOrderMx shape as the store request — see Key order fields on the Order intake page for the field table. Fields unique to reading an order (not meaningful to set):

Field	Type	Description
Amount	decimal	Read-only. Live total of the order’s sold articles (ArticlesSell) — recalculated continuously as the order changes, not just once invoiced. Stops updating only once the order reaches its final, locked invoice status.
Distance	decimal	Read-only. Total distance in km, calculated from the route (see AddressStart/AddressEnd below).
AddressStart / AddressEnd	address	Optional. Not just a mirror of the first/last task — if set, these addresses are added as the actual start/end leg of the order’s route for distance/duration calculation, instead of starting and ending at the first and last task. Custom Link callers can set these explicitly; otherwise MendriX fills them from the client’s or administration’s configured default depot address (if the client has that default address configured).

AmountVat is not an order-level field

VAT is calculated only in invoice generation, not on a plain order — there is no live, invoice-independent VAT total to read here. If your integration needs VAT, read it from the invoice via RequestInvoices once the order has been invoiced.

Why AddressStart/AddressEnd matter

This is most relevant for orders billed from your own location rather than planned into a normal task-to-task distribution ride — for example urgent/same-day orders that go out as a dedicated trip from your depot. Setting AddressStart/AddressEnd (or having your client configured to default to them) changes the distance/duration — and therefore any distance-based automatic articles — MendriX calculates for the order.

Polling incrementally with Sequence

Sequence is a database-wide counter incremented on every committed change; everything changed in one transaction shares the new value. Once you have a SequenceMaximum from a prior call, pass it back as SequenceMinimum (one higher) to get only what changed since:

<Filter Type="TEoFilterOrdersNormal">
  <PeriodBegin>2026-07-01T00:00:00</PeriodBegin>
  <PeriodEnd>2026-07-31T00:00:00</PeriodEnd>
  <ClientNo>110</ClientNo>
  <OperatorId>-1</OperatorId>
  <SequenceMinimum>7087</SequenceMinimum>
</Filter>

Why this matters

Using Sequence to limit your result set lowers server load compared to re-requesting and diffing everything yourself. See Custom Link: rules of engagement for more background.

Sequence is assigned synchronously

As of a 2026 rework, Sequence is assigned synchronously — in the same database statement that performs the store. There is no background-process lag to account for (this replaced an older architecture where a separate background job updated Sequence asynchronously; that mechanism no longer exists).

Scenario: first poll (cold start). Request order Ids with a period filter and no SequenceMinimum. Store the returned SequenceMaximum (e.g. 7086) as your local high-water mark.

Scenario: incremental poll. On your next run, add <SequenceMinimum>7087</SequenceMinimum> (one higher than your stored value) to the same filter. Only orders changed since your last poll come back, each with a new SequenceMaximum — update your stored value to the new maximum before your next run.

The 2026.2 period-matching change

Since MendriX 2026.2, an order matches a PeriodBegin/PeriodEnd filter when any of its tasks is active at any point in the period — not only when a task moment falls inside it. A task requested from 10 March to 25 March is returned by a filter for 15-20 March, even though neither endpoint falls in that window, because the task is active throughout it.

If your integration depends on the pre-2026.2 point-in-period behavior, add the compatibility switch:

<Filter Type="TEoFilterOrdersNormal">
  <PeriodBegin>2026-07-01T00:00:00</PeriodBegin>
  <PeriodEnd>2026-07-31T00:00:00</PeriodEnd>
  <UseLegacyOrderFilterPeriodMatching>True</UseLegacyOrderFilterPeriodMatching>
</Filter>

Full details: Custom Link: rules of engagement.

Gotchas

• Sequence is assigned synchronously with the store — there is no background-process lag; a sequence-filtered read immediately after a store reflects it right away.
• IgnShowAlways is unrelated to Sequence filtering — SequenceMinimum/SequenceMaximum are always applied to the result set regardless of this flag. IgnShowAlways only controls whether always-visible (ShowAlways) orders bypass the period/client/operator filters; per the schema, it should normally be set True for retrieval (default is False).
• The default period is today if PeriodBegin/PeriodEnd are omitted — don’t assume “no period” means “all orders.”

Related commands

• Order intake / Order update — the create/update counterpart; updates require a prior RequestOrdersNormal.
• GdxEoStructures.xsd — TEoFilterOrdersNormal and TEoOrderMxList field definitions.