Interface for Scope to send order data to the haulage contractor when printing a transport order.
For more details see https://service.riege.com/en/knowledge/transport-order-interface.
The transportorder message has been designed to feed external truckers with transportorders generated by Scope.
Transportorders entered in Scope for shipments can be sent out to external truckers using the RSI internal generic transportorder XML format.
The message transmission is triggered by printing the transportorder in Scope.
The specific message format version is provided in the processing Clearing Center.
The interface supports outgoing direction only, meaning that Scope can send but will not receive those messages.
Each message contains exactly one transportorder.
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<transportOrderMessage xmlns="http://dtd.riege.com/scope/transportorder"
xmlns:to="http://dtd.riege.com/scope/transportorder" schemaVersion="1.15">
The root element transportOrderMessage
contains the used version of the provided transportorder.
This information is provided by attribute schemaVersion
and can be configured in the processing
clearing center.
A message consists below the root element transportOrderMessage
of following two child elements:
<messageHeader>
and<transportOrder>
or<fclTransportOrder>
<messageHeader messageCreation="YYYY-MM-DDThh:mm:ssZ">
<sender code="ABC">Alpha Beta Club</sender>
<recipient code="DEF">Delta Echo Fanclub</recipient>
<messageId>1234567890</messageId>
<contact>John Doe</contact>
</messageHeader>
The header contains
<messageHeader>
<sender>
and <recipient>
codes with optional names<messageId>
<contact>
.By field <messageId>
the specific message can be identified.
This id does not identify a specific transportorder.
Depending on the transportorder to be transmitted, exactly one of the following two elements is used:
transportOrder
(for lcl cargo)fclTransportOrder
(for containerized cargo)<transportOrderMessage>
<messageHeader/>
<transportOrder transportOrderId="ID_123456789" transportOrderType="pickup">
...
</transportOrder>
</transportOrderMessage>
or
<transportOrderMessage>
<messageHeader/>
<fclTransportOrder modeOfTransport="road" transportOrderId="ID_123456789" transportOrderType="fclPickup">
...
</fclTransportOrder>
</transportOrderMessage>
Both elements have following mandatory attributes:
transportOrderId
which identifies a specific transportorder. In case an update of the specific
transportorder needs to be sent with a later message, that can be done by using the same id.transportOrderType
which identifies the type of transportorderFollowing additional mandatory attribute exists for a the fclTransportOrder
:
modeOfTransport
, defining the mode of transport (i.e. “road, rail or inlandWaterway”)In case of a transportOrder
, the following transportOrderType
values are available:
In case of a fclTransportOrder
, the transportOrderType
values are:
Each of above two types of transportorder has a slightly different list of possible child elements. The main differences for both types are the following ones:
transportOrder
fclTransportOrder
Child elements of above two types are:
service
- optionalreferences
- mandatorygoods
- mandatorycontainers
- mandatory (only available for type fclTransportOrder
)pickupLocation
- mandatory (only available for type transportOrder
)deliveryLocation
- mandatory (only available for type transportOrder
)freight
- optionalremarks
- optionalshipmentDataAir
- optional (only available for type transportOrder
)shipmentDataSea
- optionalshipmentDataRoad
- optional (only available for type transportOrder
)attachment
- optionalIn this section we do not describe all elements of the whole schema, but describe
only specifics or differences in case of usage in the different transportorder
types transportOrder
and fclTransportOrder
.
goods
:<goods>
<totals>
<package packageType="PX">24</package>
<grossWeight unit="KGM">2400.000</grossWeight>
<netWeight unit="KGM">2157.000</grossWeight>
<volume unit="MTQ">7.850</volume>
<loading unit="MTR">2.150</volume>
</totals>
<natureOfGoods>Goods Description ....</natureOfGoods>
<gid/>
<gid/>
<gid/>
...
</goods>
The goods
element
totals
element (holding total values, as number and
type of packages, total net weight, total gross weight, volume and loading meters)transportOrder
and mandatory for transportorders of type fclTransportOrder
.Each gid
element describes one specific cargo item:
<gid>
<totals>
...
</totals>
<natureOfGoods>Nature of goods description</natureOfGoods>
<dims/>
<labels/>
<dangerousGoods/>
<handlingInfo/>
<stackability/>
<temperatureRange/>
</gid>
In case of transportorders of type fclTransportOrder
, each gid
element also holds an optional
attribute loadedInto
which holds the id of the relating container, which then need also to be defined
in the message in the element group containers
. By this id the message describes, which cargo
item is loaded into which container. If the loadedInto
is not defined, the cargo item is interpreted
as non-containerized:
<gid loadedInto="container-id">
...
</gid>
Example for the relation between a gid element and a container:
...
<goods>
...
<gid loadedInto="container-id-132456">
...
</gid>
...
</goods>
<containers>
<container containerId="container-id-132456" ...>
...
</container>
...
</containers>
...
containers
and container
:The element containers
is only available - as said above - for fclTransportOrder
s. This element
is used to describe all containers of the transportorder and must contain at least one container
element.
<containers>
<container containerId="container-id-132456" number="TEMU0220422" shippersOwned="false">
<type>22G0</type>
<sealNumber>YMAC307601</sealNumber>
<settings/>
<outOfGauge/>
<stops/>
</container>
<container>
...
</container>
...
</containers>
Attribute containerId
is mandatory and must be unique among all containers described in the
message, since this id is used in the gid elements to describe, which cargo is stuffed
into which container. The other two attributes (number
and shippersOwned
) are optional.
container
:type
- (mandatory) describes the ISO 6346 container typesealNumber
- (optional) seal of the container (optional), may repeat in case of multiple sealssettings
- (optional) used to describe specific settings of a container (like temperature, humidification, ventilation, etc.)outOfGauge
- (optional) specific information about the dimensions of the container, if it exceeds the standard sizesstops
- (mandatory) list of “places” (like empty / full pickup, delivery, empty return, …) where the container needs
to be moved to on its journey from initial pickup to final delivery; each place is defined by a stop
element in the list;
at least one stop
needs to be definedstop
:The stop element is used in all transport messages. While a list of stops is defined per
container in a message of type fclTransportOrder
, messages of type transportOrder
have exactly
two stops, which are not named stop
, but pickupLocation
and the deliveryLocation
.
Each stop
has following structure:
<stop role="pickup">
<address/>
<contact/>
<location/>
<intervalLower/>
<intervalUpper/>
<references/>
<remarks/>
</stop>
As said above, in case of a message of type transportOrder
, elements pickupLocation
and deliveryLocation
are used (but have the same list of child elements):
<pickupLocation role="pickup">
<address/>
...
</pickupLocation>
<deliveryLocation role="delivery">
<address/>
...
</deliveryLocation>
Besides element address
all other elements of a stop
element are optional and hold
additional information concerning the defined stop address (like who is to contact,
UN locode of the address, from when until when to arrive at given address, references and remarks).
Attribute role
is mandatory and can have one of following values:
Elements to allow transmission of additional shipment data are:
shipmentDataAir
shipmentDataSea
shipmentDataRoad
These elements are optional and contain specific information about the relating air, sea or road shipment. All of them may hold information of the main addresses of the shipment:
In addition shipmentDataAir
may contain information about the security status
of the shipment, the main shipments loading and destination UN locode and the
relating flights.
In case of shipmentDataSea
the main shipments receipt, loading, destination
and release locations (UN locodes), carrier and vessel information and some
dates (ets, eta, closing) can be transmitted.
The first four examples show messages with the absolut minimum of data for a
These examples do not make to much sense, since they really provide only the minimum data to please the relating schema. So we continue with examples for “properly filled” transportorders of the different types, before continuing with specific examples on specific areas:
In the following one example is given, where a goods entry (element gid
)
holds a list of dimensions (available as a list of dims
elements):
Following example shows a transportorder with two pdf documents, which can
be transferred as base64 encoded strings. These are transferred in the
attachment
elements:
Now an example with several stop addresses for a container:
Finally an example with dangerous goods cargo: