SIST EN 18158:2026

SLOVENSKI STANDARD
01-september-2026
Ravnanje z odpadki - Mobilni informacijski sistemi - Zahteve za vmesnik XML
Office-Mobile
Waste management - Mobile IT systems - Requirements for the XML interface Office-
Mobile
Abfallwirtschaft - Mobile IT-Systeme - Anforderungen an die XML-Schnittstelle Office-
Mobile
Gestion des déchets - Réseaux IT mobiles - Exigences pour l'interface XML Office-
Mobile
Ta slovenski standard je istoveten z: EN 18158:2026
ICS:
13.030.40 Naprave in oprema za Installations and equipment
odstranjevanje in obdelavo for waste disposal and
odpadkov treatment
35.240.99 Uporabniške rešitve IT na IT applications in other fields
drugih področjih
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EN 18158
EUROPEAN STANDARD
NORME EUROPÉENNE
June 2026
EUROPÄISCHE NORM
ICS 13.030.40
English Version
Waste management - Mobile IT systems - Requirements
for the XML interface Office-Mobile
Gestion des déchets - Réseaux IT mobiles - Exigences Abfallwirtschaft - Mobile IT-Systeme - Anforderungen
pour l'interface XML Office-Mobile an die XML-Schnittstelle Office-Mobile
This European Standard was approved by CEN on 6 April 2026.

CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this
European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references
concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN
member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management
Centre has the same status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2026 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 18158:2026 E
worldwide for CEN national Members.

Contents Page
European foreword . 4
1 Scope . 5
2 Normative references . 5
3 Terms and definitions . 5
4 Objective of the Office-Mobile interface . 9
5 Interfaces . 9
5.1 Classification of the interface . 9
5.2 Interface — Exchange of information in files . 10
5.3 Basic structure . 11
5.3.1 General. 11
5.3.2 MasterData, OrderPlan, OrderReport, StatusReport . 11
5.4 Data transmission . 11
6 Disposal XML schema . 11
6.1 Specifications for creating the schema . 11
6.1.1 Example for naming job designations . 11
6.1.2 Tour, Job, Service . 12
7 Variables and structure of the schema . 12
7.1 Format . 12
7.2 Object-based layout of the elements . 12
7.3 Attributes of elements . 13
7.4 Naming conventions . 14
7.5 Elements XXXNumber when generating on the mobile technology . 14
7.6 EventLog . 14
7.7 Handling of Tour, Job, Service . 15
7.7.1 Planned jobs . 15
7.7.2 Unplanned jobs . 15
7.8 Basic structures . 16
7.8.1 MasterData . 16
7.8.2 OrderPlan . 18
7.8.3 OrderReport . 19
7.8.4 StatusReport . 21
7.9 Enumeration types . 23
7.9.1 ActivityBaseType . 23
7.9.2 ContentType. 23
7.9.3 DataSetStatusType . 24
7.9.4 DataSourceType . 24
7.9.5 DrivingDirectionType . 25
7.9.6 GeoPositionValidityAndQualityType . 25
7.9.7 LifterType . 25
7.9.8 Material HandOverActionType . 26
7.9.9 StatusMessageType . 26
7.9.10 StaffActivityStatusType . 28
7.9.11 SystemMessageType . 28
7.9.12 VehicleBaseType . 28
7.9.13 WeighingStatusType . 29
7.10 Physical variables . 29
7.10.1 General . 29
7.10.2 MassType . 29
7.10.3 LatitudeType and LongitudeType . 30
7.11 ComplexTypes . 30
7.11.1 ActivityType . 30
7.11.2 AddressType . 30
7.11.3 BusinessPartnerType . 30
7.11.4 CarrierType . 30
7.11.5 CompanyType . 30
7.11.6 RFIDType . 31
7.11.7 ContainerldentificationType . 31
7.11.8 MessageType . 31
7.11.9 OrderPlanHeaderType . 34
7.11.10 OrderReportHeaderType . 34
7.11.11 BinListType. 35
7.11.12 TourType . 37
7.11.13 TourAcknowledgementType . 38
7.11.14 JobBaseType . 39
7.11.15 JobType . 40
7.11.16 JobAcknowledgementType . 40
7.11.17 ServiceType . 40
7.11.18 ServiceAcknowledgementType . 41
7.12 EventType . 42
7.12.1 General . 42
7.12.2 UserEventType . 42
7.12.3 EmptyingEventType . 43
7.12.4 IdentificationEventType . 43
7.12.5 WeighingEventType and VolumeEventType . 44
7.12.6 GenericValueEventType . 44
8 Scenarios and examples . 44
8.1 Use of StatusReport . 44
8.2 Household-related collection . 45
8.2.1 General . 45
8.2.2 No preparation/tracking/recording of performance data . 45
8.2.3 Vehicle position . 45
8.2.4 Black and white lists of transponders during household-related collection . 46
8.2.5 Planned tour without sites, vehicle-related framework specifications . 46
8.2.6 Planned route with tour, sites and containers . 47
8.3 Commercial waste disposal with job management . 47
9 Transfer of data services. 48
Annex A (informative) XML schema Interface-Office-Mobile-2.22EN.XSD . 49
Bibliography . 50

European foreword
This document (EN 18158:2026) has been prepared by Technical Committee CEN/TC 183 “Waste
management”, the secretariat of which is held by DIN.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by December 2026, and conflicting national standards shall
be withdrawn at the latest by December 2026.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document is intended to be read in conjunction with the digital files of the XSD schema as listed in
Annex A.
Any feedback and questions on this document should be directed to the users’ national standards body.
A complete listing of these bodies can be found on the CEN website.
According to the CEN-CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria, Croatia,
Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland,
Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of North
Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and the United
Kingdom.
1 Scope
This document specifies the standard for the digital exchange of data between the disposition (i.e.
registered Office) and the mobile waste and recycling collection units (revolving emptying system
according to the EN 840 series and the EN 13071 series and refuse collection vehicles according to the
EN 1501 series).
The technique of data transmission is not part of this document.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp
— IEC Electropedia: available at https://www.electropedia.org/
3.1
Extensible Markup Language
XML
language not specific to the system and hardware to illustrate data and their structure in an XML
document
Note 1 to entry: An XML document is a text object that contains the data and markup and that defines the structure
of the data.
Note 2 to entry: For details see XML – Extensible Markup Language 1.0, Fifth Edition, 26-Nov-2008 [13].
[SOURCE: IEC 62755:2012+A1:2020 (VDE 0493-6-3), 3.1.40]
3.2
World Wide Web Consortium
W3C
main international standardisation organisation that maintains the definitions for XML and associated
standards
[SOURCE: IEC 62755:2012+A1:2020 (VDE 0493-6-3), 3.1.39]
3.3
job processing software
software that generates jobs for mobile technology on a stationary computer and adopts and further
processes the job data processed on the mobile technology
3.4
mobile technology
MobT
computer technology on board the waste disposal vehicle or handheld device via which data is collected
on the execution state of the jobs during a waste collection tour (or job processing tour in the further
sense)
3.5
refuse collection vehicle
RCV
vehicle used for the collection and transportation of refuse (e.g. household refuse, bulky refuse, recyclable
materials) based on loading via refuse containers or by hand
Note 1 to entry: Most of the time it consists of a chassis or rigid chassis onto which a bodywork is mounted.
Sometimes it can also be a truck and trailer combination.
Note 2 to entry: An RCV is a special purpose vehicle according to Regulation (EU) 2018/858. Regulation (EU)
2018/858 contains requirements for special purpose vehicles.
[SOURCE: EN 1501-1:2021, 3.1]
3.6
electronic waste verification procedure
eANV
waste verification procedure for waste that needs to be verified
Note 1 to entry: This is generally hazardous waste.
3.7
Office
registered Office for the waste management company that exchanges information with the vehicles
3.8
mobile devices
all of the on board computers and handheld devices (handhelds) used for providing disposal services
3.9
Office-Mobile interface
uniform interface for the computer-assisted exchange of information between the Office and the disposal
vehicles/mobile devices
3.10
data transmission
transfer of data from one point to one or more other points over telecommunication facilities
[SOURCE: EN ISO/IEC 19762-1:2012, 01.02.16]
3.11
OrderPlan
all of the orders that are processed for a defined period of time
Note 1 to entry: The OrderPlan is used to transfer job data to the mobile device and data to the organization. The
OrderPlan contains all of the information required on the mobile device to process jobs.
Note 2 to entry: The job data are subdivided into Tours, Jobs and Services.

Figure 1 — Linking the OrderPlan into the information structure
3.12
MasterData
organisational information that is required on the mobile device to process jobs as part of the OrderPlan
Note 1 to entry: See Figure 2. It can be transmitted to the mobile device with every OrderPlan or in separate files.
It contains:
— personnel lists;
— unloading points;
— transponder lists for black/white list;
— messages.
Figure 2 — Integration of the MasterData into the information structure
3.13
OrderReport
report which contains all of the data that is documented as part of job processing and provides
confirmation from the vehicle about the OrderPlan
Note 1 to entry: It is generated by the mobile device during the provision of services. The data in the OrderReport
provides the Office software with a usage-based invoice of the processed jobs.

Figure 3 — Integration of the OrderReport into the information structure
3.14
StatusReport
report that transmits short status messages and/or status requirements from the Office to the mobile
device and vice versa
Note 1 to entry: The StatusReport can be used to exchange requirements or information on the job processing
procedure, the position of the mobile device and job-independent status information (see Figure 4).
Note 2 to entry: No performance data are transmitted with the StatusReport.

Figure 4 — Integration of the StatusReport into the information structure
3.15
tour
sequencing of individual services and jobs
Note 1 to entry: To cover the event that a RCV/mobile device processes several disposal areas, several tours can be
transmitted at the same time. They are summarized in a TourList.
A tour primarily includes:
— description and identification of the tour using a name;
— all job data;
— amendment information, validity;
— references to “Black list”/”White list” (TransponderLists) and unloading points, which have been transmitted
in MasterData;
— applicable documents (e.g. from eANV – electronic waste verification procedure);
— tour profile for activating/deactivating certain functions of the RCV.
3.16
job
individual work order from the tour
Note 1 to entry: A job contains the necessary information to process jobs at a site (a place of performance).
Essentially, this includes:
— site where a job is to be executed;
— customer for whom a job is to be executed (generator);
— services to be provided;
— additional information;
— information about a route (tour specification).
Note 2 to entry: All of the jobs in a tour are summarized in a JobList.
EXAMPLE Handling the vessel.
3.17
service
activities for the individual work order
Note 1 to entry: A service contains the information on the services that are to be provided at the place of
performance. Essentially, this includes:
— planned time of the service provision;
— quantity specification regarding the service to be provided;
— container data;
— material data;
— activities (work process);
— processing status.
Note 2 to entry: All services of a job are summarized in a ServiceList.
EXAMPLE positioning, emptying and replacing a container.
3.18
disposal XML schema
information to be exchanged in a structure which is normal for XML
Note 1 to entry: XML and XML schema are recommendations of the World Wide Web Consortium (W3C).
3.19
EventLog
central point for collecting all of the data accumulated for a job
3.20
ComplexType
description of the enumeration types divided into their elements and attributes
4 Objective of the Office-Mobile interface
The interface enables data to be exchanged between components (Office and the waste disposal
vehicles/mobile devices) including ones from different manufacturers. In this way, the waste disposal
companies are more flexible, when it comes to the selection of components to support the disposal
process.
5 Interfaces
5.1 Classification of the interface
Figure 5 shows an overview of the interfaces in the waste management industry and the classification of
the Office-Mobile waste interface described here.
Key
BMU Federal Ministry for the Environment, Nature Conservation, Nuclear Safety and Consumer Protection
eANV electronic waste verification procedure
AvaL exchange of job-specific performance data
Figure 5 — Classification of the interface
5.2 Interface — Exchange of information in files
The interface between the mobile technology for job processing on disposal vehicles and mobile devices
shall be realized by data in XML format. See Figure 6.
This data are exchanged in the form of files. The following file names are used within this document for
the purpose of uniform naming. In this specific case, the file names may deviate and contain a date stamp,
mobile device ID etc.:
— The file OrderPlan.xml contains all of the information transmitted from the Office to the mobile device
(see Figure 1).
— The file MasterData.xml contains organisational data and is transmitted from the Office to the mobile
device where necessary (initial preparation, amendment of MasterData) (see Figure 2).
— The file OrderReport.xml contains all of the information transmitted from the mobile device to Office
(see Figure 3).
— The file StatusReport.xml contains current status messages on the job processing and is used to
update the Office software.
All of the information for processing the job is included in the files.
Generally, jobs are generated by an Office software. The job data are made available to the mobile
technology. The execution of the jobs is documented using the mobile technology. The jobs processed
there are also transferred to the post-processing software via this XML interface.
Figure 6 — Structure of the file-based exchange of data
5.3 Basic structure
5.3.1 General
The data exchange between Office and the mobile device takes place by transmitting the data elements.
5.3.2 MasterData, OrderPlan, OrderReport, StatusReport
The interface is split into mobile jobs, which are then divided into the OrderPlan, OrderReport and
StatusReport (see terms and definitions in Clause 3). The organisational information in the MasterData
are referenced by the mobile jobs.
5.4 Data transmission
The wireless data transmission with or without a provider is usually implemented via standard such as
WLAN, GSM/GPRS, UMTS.
6 Disposal XML schema
6.1 Specifications for creating the schema
6.1.1 Example for naming job designations
The companies use different designations to name and invoice the disposal services, including:
— Job;
— Tour;
— Service certificate.
6.1.2 Tour, Job, Service
Every BaseType of the job interface (Tour, Job, Service) contains further elements (not mentioned here)
that serve for more detailed specification of the jobs. Their meaning, format and contents are described
in Clause 3. For these BaseTypes, the term “service elements” is also used in the documentation. For the
relationship between the job elements, refer to the following Table 1.
Table 1 — Relationships between Tour, Job, Service job elements to actual jobs
Designation Time period Vehicle Place of Services Container
mobile device performance
1−n days (shift)
Tour (holiday pre- 1 vehicle n sites 1-n 1-n
/post-runs)
1-n of a waste
Job 1 day (shift) 1 vehicle 1 site 1-n
category
Service 1 day (shift) 1 vehicle 1 site 1 1-n
7 Variables and structure of the schema
7.1 Format
The meaning, validity periods of the contents of the XML tags as well as the additional information are
described in this document and potential usage scenarios are explained using examples. The following
clauses only consider those elements for which explanations are required beyond this document.
The elements necessary for job processing are mandatory elements. They shall therefore be completed.
7.2 Object-based layout of the elements
In order to illustrate common and different data in the OrderPlan and OrderReport in the XML schema,
an “item-orientated” layout of the data structures is used.
For Job and Service, there is a BaseType (JobBaseType, ServiceType), which contains the common data
and any diverted types for OrderPlan (JobType, ServiceType shall be used without an amendment in the
OrderPlan and shall hence not be diverted) and OrderReport (JobAcknowledgementType,
ServiceAcknowledgementType), which contain additional data elements according to the respective
requirements. The JobBaseType is thus a BaseType. See Figure 7.

b) For JobAcknowledgementType in the
a) For JobType in the OrderPlan
OrderReport
d) ServiceAcknowledgementType in the
c) ServiceType in the OrderPlan
OrderReport
Figure 7 — Example of BaseTypes of the JobBaseType
Since the elements TourType in the OrderPlan and TourAcknowledgementType in the OrderReport are
very different (the TourAcknowledgementType contains only the essential TourNumber and Status, as
well as the Duration, JobList and EventList), a common BaseType has not been used.
7.3 Attributes of elements
Attributes are permitted for some elements, see Table 2. The use of attributes is optional.
Table 2 — Permitted attributes and their use
Attribute Type Purpose
ID IDType The ID constitutes a clear code of a data set so that the Office
software can retrieve the data sets transmitted to a mobile device
and processed there in the database. Since there are different
procedures for clear IDs from the Office software, the type was
defined on xs:token, which is a string without formatting characters
(no line feeds, tabs, leading and trailing space characters). GUIDs,
figures or other strings can thus be transmitted.
Source DataSourceType The application, which generates an element and enters it into the
interface, writes this attribute.
Through assessment, every application of the entire system Office /
mobile device software can determine through which application
the element was generated and react accordingly.
CSVendor xs:string The manufacturer-specific checksum across the entire entry can, for
example, be used to ensure the integrity of the data when
generating/transporting/processing the data.
CSBDE xs:unsignedlnt Designed to secure the data integrity with a simple CRC-32
algorithm IEEE 802.3.
It is determined across the entire enclosed node, and all of the
whitespaces (tabs, spaces, line breaks) are ignored.
An amendment to the usage content of the data are therefore no
longer possible, but better formatting (“pretty print XML“) is.
7.4 Naming conventions
Consistent naming has been implemented by giving similar elements the same postfix:
— All numbers are referred to as XXXNumber and are transmitted as xs:nonNegativeNumber;
exceptions include terms that are also designated as numbers in colloquial language, but still include
letters, e.g. container number.
— All IDs are called XXXID and are transmitted as IDType (xs:token); so that GUIDs and combinations of
figures/letters can also be transmitted as IDs.
— All lists are identified with XXXList.
In order to support a better automatic code generation, the PascalCase style has been applied for
enumerations, i.e. no space within an enumeration and capital letters for each word (“OrderPlanRequest”,
“InProgress”).
7.5 Elements XXXNumber when generating on the mobile technology
When processing the job, the mobile technology generates certain data sets. These elements are
TourType, JobType and ServiceType. They can be identified using a number. The mobile technology
generates data sets. In this case, this data are assigned ascending numbers (0, 1, etc.) by the mobile
technology. These are included in the abbreviation XXXNumbers.
In this case, the source attribute of the element is given the value OnBoardComputer. The rule applies to
the element types specified in Table 3 and the types derived from this.
Table 3 — Affected attributes and their use
Element type Derived element type
TourType TourNumber
JobType JobNumber
ServiceType ServiceNumber
7.6 EventLog
The EventLog is the central point for collecting all of the data accumulated in connection with processing
the job. All collected information is regarded as an event.
Events can be generated through both operator actions and technical components. They are recorded in
the EventLog with a time stamp and optionally with a GeoPosition.
The EventLog is part of the OrderReport. Tours, Jobs, and Services can reference individual or several
events in the EventLog. It is thus possible to assign the events to certain jobs and to document the
provision of services.
7.7 Handling of Tour, Job, Service
7.7.1 Planned jobs
The Office software assigns clear IDs or numbers to the Tours, Jobs and Services in the OrderPlan. The
mobile devices reference the planned job items using:
— Automatic criteria (examples):
— Container identification in a reloading tour: Transponder number is transmitted in the container
element during the service and the associated service can thus be selected;
— GPS-coordinates for industry tour: In the job, a GeoPosition is transmitted in the JobLocation
element and the job can be selected using the current position;
— Manual selection of the job by the operator from a list (industry tour without automatic
identification).
After the job selection, data are collected and saved as an event in the EventLog. There is an
EventLogEntryList within each job item (Tour, Job, Service) in which the unique IDs of the events are
stored. Each job item thus references any number of events in the EventLog.
When being imported, the Office software can create the reference to the job items of the OrderPlan and
OrderReport via the IDs or the numbers and assign the data collected from the mobile device to the
individual database items.
7.7.2 Unplanned jobs
Not all emptying tours are performed with a tour specification. Transponders are identified to which no
site and no job can be assigned on the mobile technology. It may also be possible for services to be
provided that are not included in the OrderPlan (household waste collection tour).
As described above, accumulated data (emptying, weights, additional inputs) is stored in the EventLog.
In the simplest case, the OrderReport can only contain one EventLog (the TourList is optional). In order
to transmit the data to the Office, the mobile device shall not generate a Tour with Job and Service in the
OrderReport. The Office software imports all of the events and can, in the event of a household waste
collection tour, for example, assign emptying events to the individual data using EmptyingEvents, which
contain the transponder identification.
However, there is also a possibility that the mobile device will generate an individual tour in the
OrderReport. In this case, proceed as follows.
For each container that is processed, and which is not planned in any job, a new Service will be created.
Depending on the requirements resulting from the type of application, two procedures can be used:
— A new Job is also created for each new Service. The new Service is attached to this Job.
— When creating the first new Service, a new Job is created. All other new Services are attached to this
new Job.
However, it is once again important that the data are stored in the EventLog and that reference is made
to this within the Service via the EventLogEntryList.
7.8 Basic structures
7.8.1 MasterData
The MasterData can be sent to a mobile device independently of an OrderPlan for initial commissioning
with the MasterData (personnel lists, unloading points, black / white lists), see Figure 8.
Figure 8 — MasterData schema
The following rules apply to the use:
— A transmitted list replaces an existing list on the device.
— No incremental updates of the lists are supported (e.g. no individual transmission of a new driver, all
of them shall be transmitted).
— All lists can be deleted via a flag (PreDeleteAll) before importing the MasterData.
— Then all of the lists in the MasterData shall be retransmitted in their current status.
— MasterData in the OrderPlanHeader apply to the current OrderPlan; e.g. the
MasterData.PersonnelList can be used to transfer the entire personnel list of the waste disposal
company and OrderPlan.OrderPlanHeader.MasterData.PersonnelList can be used to specify which
driver shall drive the specific tour.
— It depends on the mobile software whether it adopts unknown data from the
OrderPlan.OrderPlanHeader.MasterData into its own MasterData.
7.8.2 OrderPlan
The OrderPlan contains the organisational data and MasterData for the job or jobs and the TourList; see
Figure 9, Table 4 and Table 5.

Figure 9 — OrderPlan schema
Table 4 — Elements in the OrderPlan
Name Type Meaning
OrderPlanHeader OrderPlanHeaderType Organisational data of the job or jobs
TourList List of TourTypes Composition of all tours that are to be processed by
the RCV
Table 5 — Valid attributes OrderPlan
Attribute Comment
ID Approved
Source Not approved
7.8.3 OrderReport
OrderReport: Transmitted from the vehicle to the Office after the services have been provided, see
Figure 10, Table 6, Table 7 and Table 8.

Figure 10 — OrderReport schema
Table 6 — Elements in the OrderReport
Name Type Meaning
OrderReportHeader OrderReportHeaderType Organisational data on the job or jobs that
are reported back
TourAcknowledgementList List of TourAcknowledgementType Composition of all tours that are reported
back by the RCV
EventLog List of EventLogEntryType Contains all of the events which have been
recorded in the log book while processing
the job.
Table 7 — Valid attributes OrderReport
Attribute Comment
ID Approved
Source Not approved
Table 8 — Valid constraints OrderReport
Constraint Comment
EventLogEntryKey Clear code of an entry in the log book
RefID Name of the code reference
7.8.4 StatusReport
See Figure 11, Table 9 and Table 10.

Figure 11 — StatusReport schema
Table 9 — Elements in the StatusReport
Name Type Meaning
Transmitter xs:string See schema for description.
StatusNumber xs:nonNegativelnteger Consecutive number for all of the
StatusReports for a system; can be used for
gap identification.
StatusList StatusListType List of status messages.
Elements in a StatusMessage of the type StatusType
TimeStamp xs:dateTime Time at which the status was recorded.
StatusMessage MessageStatusType See schema.
OtherStatusMessage xs:string User-defined messages, which are not
specified in the schema.
OtherStatusMessageData xs:string Content data for the user-defined
StatusMessage.
GeoPosition GeoPositionType Geocoordinates
TourNumber xs:nonNegativelnteger Number of the tour to which the
StatusReport relates.
JobNumber xs:nonNegativelnteger Number of the job to which the StatusReport
relates.
ServiceNumber xs:nonNegativelnteger Number of the service to which the
StatusReport relates.
Comment xs:string Message which can be displayed on the
mobile device following receipt of the
StatusReports or additional information/that
has been generated by the mobile device.
Table 10 — Valid attributes StatusReport
Attribute Comment
ID Approved
Source Not approved
7.9 Enumeration types
7.9.1 ActivityBaseType
Indication of which activity shall be executed or has been executed by the vehicle. Service types according
to disposal catalogue. See Table 11.
Table 11 — ActivityBaseType: Description of the applicable values
Value Meaning
Empty Emptying a container
Deliver Delivery (e.g. positioning a container)
PickUp Collection (e.g. of a container)
Other Deviating service type
Service type is specified in an additional string in the ActivityType.

7.9.2 ContentType
Possible file types for attached documents. Used in DocumentType. See Figure 12 and Table 12.

Figure 12 — DocumentType schema
Table 12 — Description of valid values ContentType
Value Meaning
PDF PDF document
Doc WORD document
CSV Comma separated text file
Image Image file, image format is derived from extension of the file name.
EanvBgs eANV dispatch note
EanvUns eANV consignment note
Mime User-specific type, which is more accurately specified via MIMEType.
7.9.3 DataSetStatusType
Type to transfer the status for the OrderPlans, Tours, Jobs, Services, etc. See Table 13.
Table 13 — Description of valid values DataSetStatusType
Value Meaning
Add Adding an element
Delete Deleting an element
Update Replace
Done Processing completed
Refused Processing refused
InProgress Element is being processed
Suspended Processing suspended
7.9.4 DataSourceType
Indication through which data of an element has been generated. See Table 14.
Table 14 — Description of valid values DataSourceType
Value Generated by
Office Job processing software in the registered Office
OnBordComputer Automatically created by the job proces
...