Order intake

StoreOrdersNormal creates a new order when you send a negative OrderId/Id. The same command also updates existing orders when you send a positive Id — for that retrieve-then-store workflow, see Order update.

When to use

Situation	Command
Create a brand-new order	StoreOrdersNormal with a negative OrderId/Id
Instantiate order(s) from a recurring template	ActivateOrderTemplate
Change an existing order	See Order update instead
Just read an order, no changes	See Order retrieval & sync instead

Creating a new order

Set OrderId/Id to any negative number — this tells Custom Link to insert a new record. New orders are exempt from the retrieve-before-store rule that applies to updates.

A realistic order is built from three separate lists hung off the order: Goods (the packages/cargo), Tasks (the pickup/delivery stops), and GoodsToTasks (which good moves through which task). All three are needed — a Tasks-only payload with no Goods/GoodsToTasks creates an order with stops but no cargo recorded against it:

<?xml version="1.0" encoding="windows-1252"?>
<EoCustomLinkStoreOrdersNormal Type="TEoCustomLinkStoreOrdersNormal">
  <ApplyImportSettings>1</ApplyImportSettings>
  <Data Type="TEoOrderMxList">
    <_TEoListBase_Items>
      <EoOrderMx Type="TEoOrderMx">
        <OrderId Type="TEoKeyIntInfraMx"><Id>-1000</Id></OrderId>
        <ClientNumber>1001</ClientNumber>
        <Reference>PO-2026-00042</Reference>
        <Contact>Jan de Vries</Contact>
        <Goods Type="TEoGoodMxList">
          <_TEoListBase_Items>
            <EoGoodMx Type="TEoGoodMx">
              <GoodId Type="TEoKeyIntInfraMx"><Id>-1</Id></GoodId>
              <Barcode>MXG00000087</Barcode>
              <Comments>2 pallets general cargo</Comments>
              <Parts>2.0</Parts>
              <Weight>480.0</Weight>
            </EoGoodMx>
          </_TEoListBase_Items>
        </Goods>
        <Tasks Type="TEoTaskMxList">
          <_TEoListBase_Items>
            <!-- Pickup task -->
            <EoTaskMx Type="TEoTaskMx">
              <TaskId Type="TEoKeyIntInfraMx"><Id>-100</Id></TaskId>
              <TaskTypeIdEx>1</TaskTypeIdEx>
              <Address Type="TEoAddress">
                <Name>Acme Warehouse</Name>
                <Street>Havenweg</Street>
                <Number>12</Number>
                <PostalCode>3011 XA</PostalCode>
                <Place>Rotterdam</Place>
                <CountryCode>NL</CountryCode>
              </Address>
              <ContactName>Jan de Vries</ContactName>
              <Requested Type="TEoDateTimeWindow">
                <DateTimeBegin>2026-07-22T08:00:00</DateTimeBegin>
                <DateTimeEnd>2026-07-22T12:00:00</DateTimeEnd>
              </Requested>
              <Instructions>Call on arrival</Instructions>
              <ReferenceYour>PICKUP-42</ReferenceYour>
            </EoTaskMx>
            <!-- Delivery task -->
            <EoTaskMx Type="TEoTaskMx">
              <TaskId Type="TEoKeyIntInfraMx"><Id>-200</Id></TaskId>
              <TaskTypeIdEx>2</TaskTypeIdEx>
              <Address Type="TEoAddress">
                <Name>Beta Distribution</Name>
                <Street>Industrieweg</Street>
                <Number>88</Number>
                <PostalCode>5651 GH</PostalCode>
                <Place>Eindhoven</Place>
                <CountryCode>NL</CountryCode>
              </Address>
              <Requested Type="TEoDateTimeWindow">
                <DateTimeBegin>2026-07-22T14:00:00</DateTimeBegin>
                <DateTimeEnd>2026-07-22T17:00:00</DateTimeEnd>
              </Requested>
              <ReferenceYour>DELIVERY-42</ReferenceYour>
            </EoTaskMx>
          </_TEoListBase_Items>
        </Tasks>
        <GoodsToTasks Type="TEoGoodToTaskMxList">
          <_TEoListBase_Items>
            <EoGoodToTaskMx Type="TEoGoodToTaskMx">
              <GoodId Type="TEoKeyIntInfraMx"><Id>-1</Id></GoodId>
              <TaskId Type="TEoKeyIntInfraMx"><Id>-100</Id></TaskId>
            </EoGoodToTaskMx>
            <EoGoodToTaskMx Type="TEoGoodToTaskMx">
              <GoodId Type="TEoKeyIntInfraMx"><Id>-1</Id></GoodId>
              <TaskId Type="TEoKeyIntInfraMx"><Id>-200</Id></TaskId>
            </EoGoodToTaskMx>
          </_TEoListBase_Items>
        </GoodsToTasks>
      </EoOrderMx>
    </_TEoListBase_Items>
  </Data>
</EoCustomLinkStoreOrdersNormal>

The same good (GoodId=-1) is linked to both tasks here — it’s picked up at the first task and delivered at the second. This is the normal shape for a simple pickup-and-deliver order: one GoodsToTasks entry per (good, task) pair the good passes through, not one entry per good. See Linking goods to tasks below for the full field reference and more scenarios (multiple goods, goods that touch only one task, what happens if you forget the link).

StoreResultList returns the new positive Id MendriX assigned, paired with the negative Id you sent — see the full worked round trip in the order intake example.

ApplyImportSettings

Setting ApplyImportSettings to 1 lets Custom Link apply your tenant’s configured defaults — automatic order confirmation, default country, automatic goods, and more. See your MendriX contact for which settings apply to your tenant.

ApplyImportSettings overrides Confirmed, not just defaults it

With ApplyImportSettings=1, the tenant’s automatic-preplanning setting always wins — whatever Confirmed value you send is discarded, not just used as a fallback when omitted. If you need explicit control over Confirmed, set ApplyImportSettings to 0.

Linking goods to tasks

Goods (the packages/cargo on an order) and tasks (the pickup/delivery stops) are declared as two separate lists on the order — Goods (TEoGoodMxList) and Tasks (TEoTaskMxList). Neither list says which good moves through which task. That link is a third list, GoodsToTasks (TEoGoodToTaskMxList), where each EoGoodToTaskMx entry is just a GoodId/TaskId pair.

Reuse the same negative Ids everywhere

When creating a new order, you invent negative Ids for new goods and new tasks (e.g. GoodId=-1, TaskId=-100). The GoodsToTasks entries must reference those exact same negative Ids — the schema explicitly allows negative Ids here specifically so you can link not-yet-created records to each other in one call. If a GoodsToTasks entry references a negative Id that doesn’t match anything in your Goods or Tasks lists (a typo, or forgetting to update it after renumbering a task), the good is silently created with no task link — MendriX does not return an error for an orphaned or mismatched link.

Key good fields (TEoGoodMx)

Field	Type	Description
GoodId	key	Negative = insert, positive = update.
Barcode	string (max 100)	Barcode without start/end characters.
Comments	string (max 50)	Description of the good’s contents.
Parts	decimal	Number of parts this good consists of.
Weight	decimal	Weight of all parts, in kg.
Height / Width / Depth	decimal	Dimensions per part, in cm.
Volume	decimal	Calculated automatically from dimensions unless VolumeManual=True.
Packing	packing	Packing type/name (e.g. “pallet”, “envelope”).
CharacteristicsRestricted	CSV of int	Good characteristics — 2 no-neighbor-delivery, 4 ADR, 18 age 18+, 40 cool, 41 freeze, 42 dry/ambient, 43 deep freeze. Only one temperature-range characteristic (40/41/42/43) takes effect; the last one listed wins if more than one is given.
ADR / UNNumber	string / int	Dangerous-goods classification, if applicable.

Key task fields (TEoTaskMx)

Field	Type	Description
TaskId	key	Negative = insert, positive = update.
TaskTypeIdEx	int	The task type — 1 Get/pickup, 2 Bring/delivery, plus 3 swap, 4 return, and others. Set this field, not TaskTypeId (see caution below).
Address	TEoAddress	Name/street/postal code/place/country for this stop.
Requested	TEoDateTimeWindow	The client’s requested time window for this task; narrow it as the actual moment approaches.
ContactName	string (max 100)	Contact person for this task, distinct from the order-level Contact.
Connectivity	TEoConnectivity	Contact details for this task. The type also has a Web field, but the schema documents only Email/Fax/Mobile/Phone as supported at the task level.
Instructions	string (max 1000)	Free-text instructions for the operator performing the task.
HandlingTimeInMinutes	int	Duration of the task in minutes. MendriX calculates this automatically unless HandlingTimeManual=True.
ReferenceOur / ReferenceYour	string (max 100)	Internal reference (yours) vs. the client’s own reference for this task.
OperatorId / VehicleId / MaterialId	key	Assign a specific operator, vehicle, or material (e.g. coolbox, trailer) to this task.

TaskTypeId is read-only — use TaskTypeIdEx

TaskTypeId looks like the field to set (1 = get/load, 2 = bring/unload), and older integrations sometimes still send it, but the schema documents it as read-only. Setting the task type is done through TaskTypeIdEx instead — it accepts the same basic values (1 get, 2 bring) plus more specific ones (3 swap, 4 return, 5–10 container/trailer/rest-period variants) and drives TaskTypeId under the hood.

Scenarios

The example above already shows the normal shape — one good linked to both a pickup and a delivery task. The scenarios below cover the variations and the failure mode:

Scenario: a good that only touches one task. If a good is, say, collected and consumed at a single task (not moved between two), it still needs at least one GoodsToTasks entry linking it to that task — a good with zero GoodsToTasks entries is not associated with any stop on the order.

Scenario: multiple goods across multiple tasks. Each good needs its own GoodsToTasks entry for every task it passes through. Two goods each moving through the same two tasks means four GoodsToTasks entries total (good 1 → task A, good 1 → task B, good 2 → task A, good 2 → task B) — there’s no shorthand for “all goods to all tasks.”

Scenario: forgetting the link (what goes wrong). You send Goods with one new good (GoodId=-1) and Tasks with one new task (TaskId=-100), but omit GoodsToTasks entirely. The store succeeds — StoreResult=srInserted for the order — but the good has no task association in MendriX. Nothing in the response signals this; the only way to catch it is to retrieve the order afterward and check that GoodsToTasks came back non-empty.

Scenario: create an order and get back its assigned Id. Send StoreOrdersNormal with OrderId/Id set to -1. The response’s EoStoreResult has IdOld=-1 and Id=<the new positive Id> with StoreResult=srInserted — use that Id for any follow-up retrieval or update.

Key order fields (TEoOrderMx)

The fields most integrators read or set on an order, beyond the nested Tasks/Goods/ArticlesSell lists already shown above:

Field	Type	Description
OrderId	key	Negative = insert, positive = update (requires prior retrieval).
ClientId / ClientNumber	key / string	Set one, not both. ClientNumber is resolved to a ClientId automatically.
Contact	string (max 100)	The person who gave the order — distinct from a task’s ContactName.
Reference	string (max 100)	Your order reference.
Moment	dateTime	Date/time of entry.
Notes	string (max 250)	Free-text notes on the order.
OrderType	int	100 = Concept, 200 = Offer, 400 = Normal (default if omitted).
ProductIdAutomaticArticles	boolean	True adds and calculates this order’s product’s automatic articles for the client’s specific prices. Leave False if you’re specifying articles yourself via ArticlesSell.
Confirmed	boolean	Confirmed for driver/vehicle. Default True.
Cancelled	boolean	Order is cancelled but still calculated/invoiced.
InvoiceStatusId	int	0 open, 1 never invoice, 2 ready to invoice, 10 on invoice, 20 locked on invoice.
VehicleRequirements	string (CSV)	Requirements for the vehicle(s)/material, e.g. REFRIGERATION, TAIL_LIFT, ADR. Replaces the full set when included.
OperatorRequirements	string (CSV)	Requirements for the operator(s), e.g. DRIVERS_MATE, ADR. Replaces the full set when included.
AmountInsured	decimal	Amount this order is insured for.
ExternalDone	boolean	Marks this external order as accepted by planning. Requires ExternalSource.
ExternalSource	int	Source of this external order. 0 regular, 1 WorldLink, 2 imported.

Amount and Distance are read-only — MendriX calculates these; sending them has no effect. AddressStart/AddressEnd are not read-only — Custom Link callers can set them explicitly to define the actual start/end leg of the order’s route; if omitted, MendriX fills them from the client’s or administration’s configured default address. There is no AmountVat on a plain order — VAT is calculated at invoice time, not order time. See Response fields on the Order retrieval & sync page for the full explanation of these fields.

See GdxEoStructures.xsd for the complete field list, including less commonly used fields.

The store response (EoStoreResultList)

Every store command — not just orders — returns the same shape, a list of EoStoreResult items:

Field	Type	Description
Id	int	The database Id of the stored item (the new positive Id for an insert).
IdOld	int	The Id you sent in the request (often negative, for a new item).
RowsAffected	int	Number of database rows affected.
StoreResult	enum	srInserted, srUpdated, srError, srNone, srFailed.
StoreDescription	string	Textual detail, especially for srError — often the exception message.
ErrorType	enum	etNone, etStructural, etIncidental, etUnknown. Retry requests with etIncidental errors; don’t retry etStructural unchanged.

Match IdOld back to the negative Id you sent to correlate results with your original request, the same way ReferenceYour/Reference correlate task-level data — see the order intake example.

Activating an order template

Rather than hand-building XML for each order, you can instantiate orders from a recurring order template using ActivateOrderTemplate. The command matches a template by task type and address, checks if the template’s time window contains your requested moment, and if the template repeats on that day, activates it — creating real order(s) from the template. If no matching template is found, no orders are created. The response is EoStoreResultList, just like a regular store.

Template activation is useful for recurring pickups or deliveries where the order structure stays the same and you only need to trigger it for a specific date and time.

One order per call

Don't batch stores

Submit one order per StoreOrdersNormal call, even though the schema technically allows up to 50. See Custom Link: rules of engagement for why. Retrieval (RequestOrdersNormal) may still be batched. The same one-per-call rule applies when updating orders — see Order update.

Related commands

• Order update — the retrieve-then-store workflow for changing an existing order.
• RequestOrdersNormal / RequestOrdersNormalIds — retrieval and incremental sync.
• GdxEoStructures.xsd — full field definitions for TEoOrderMx, TEoTaskMx, and related types.
• Order intake example — a complete envelope-wrapped request/response pair.