CEN/TS 16316:2012

Postal services - Open interface - Sortplan

This Technical Specification specifies the sort plan file content and structure. It does not deal with other configuration files in sorting machines nor is it applicable to the transport mechanism.
The content of a sort plan allows the specification of the following capabilities:  
-   sorting by address and non-address attributes;
-   sorting of code ranges;
-   sorting of rejects;
-   support of display and label texts;
-   dynamic outlet groups;
-   sorting to more than one outlet;
-   overflow handling;
-   support of cut off time before dispatch;
-   sequence sorting;
-   provide volume information (option);
-   support of Cards;
-   possibility to add simple manufacturer specific information;
-   support of various sort code formats and non-address attributes;
-   support of various display and label formats;
-   check against characteristics of the sorting machine.

Postalische Dienstleistungen - Offene Schnittstelle - Sortierplan

Diese Technische Spezifikation legt Inhalt und Struktur der Sortierplandatei fest. Sie behandelt keine sonstigen Konfigurationsdateien in Sortiermaschinen und ist auch nicht auf die Transportmechanismen anwendbar.
Der Inhalt eines Sortierplans ermöglicht die Festlegung folgender Fähigkeiten:
-   Sortieren nach Adressattributen und Nichtadressen Attributen;
-   Sortieren nach Codebereichen;
-   Sortieren von zurückgewiesenen Sendungen;
-   Unterstützung von Anzeige- und Leitzetteltext;
-   dynamische Ausgangsgruppen;
-   Sortieren mit Zuordnung zu mehr als einem Ausgang;
-   Überlaufhandhabung;
-   Unterstützung einer Cut off Zeit vor dem Versand;
-   Gangfolgesortierung;
-   Bereitstellung von Informationen zum Volumen (optional);
-   Unterstützung von Karten (Cards);
-   Möglichkeit des Hinzufügens einfacher herstellerspezifischer Informationen;
-   Unterstützung verschiedener Sortiercodeformate und Nichtadressen Attribute;
-   Unterstützung verschiedener Anzeige- und Leitzettelformate;
-   Abgleich mit Kenndaten der Sortiermaschine.

Services postaux - Interface ouverte - Plan de tri

Poštne storitve - Odprti vmesniki - Sortirni načrt

Te tehnične specifikacije določajo vsebino in strukturo datoteke z načrtom razvrščanja. Ne zadevajo drugih konfiguracijskih datotek v napravah za razvrščanje, prav tako ne veljajo za transportne mehanizme. Vsebina načrta razvrščanja določa specifikacije naslednjih zmogljivosti: – razvrščanje po naslovu in atributih brez naslova; – razvrščanje po kodi; – razvrščanje po zavrnitvah; – podpora za prikazna besedila in besedila nalepk; – dinamične izhodne skupine; – razvrščanje na več kot en izhod; – obvladovanje presežkov; – podpora za krajši čas pred razpošiljanjem; – zaporedno razvrščanje;  – pridobivanje podatkov o količini (izbirno); – podpora za kartice; – možnost dodajanja osnovnih podatkov o proizvajalcu; – podpora za različne oblike kod sortiranja in atribute brez naslova; – podpora za različne oblike prikaza in nalepk; – preverjanje lastnosti naprave za razvrščanje.

General Information

• Status: Published
• Publication Date: 12-Jun-2012
• ICS: 03.240 - Postal services
• ICS: 35.240.69 - IT applications in postal services
• ICS: 35.240.99 - IT applications in other fields
• Technical Committee: CEN/TC 331 - Postal services
• Drafting Committee: CEN/TC 331/WG 3 - Automatic identification of items - Addresses
• Current Stage: 9093 - Decision to confirm - Review Enquiry
• Start Date: 27-Jun-2025
• Completion Date: 23-Sep-2025
• Mandate: M/428 - Standardisation Mandate addressed to CEN in the field of Postal services and equipment
• Ref Project: SIST-TS CEN/TS 16316:2012 - Postal services - Open interface - Sortplan

Overview

CEN/TS 16316:2012 - "Postal services - Open interface - Sortplan" is a CEN Technical Specification that defines the content and structure of sort plan files used by postal sorting machines. It standardizes how an Information System describes sorting operations (assignment of mail items to outlets, display texts, labels, sequence rules, etc.) so different suppliers’ equipment can interoperate. The document specifies that sort plans are Unicode text files (UTF‑8 encoding), described in XML (see Annex A for XML data structure and examples). It does not cover other machine configuration files or the transport mechanism.

Key Topics

• Sort plan file format: Unicode text, UTF‑8 encoding; XML schema provided for validation (Annex A).
• SortingProducts and classifications: item‑related (e.g., destination sort code, priority) and machine‑related (special sorts like rejects/overflow).
• Outlet allocation:
  • Static outlets: explicit physical outlet assignment.
  • Dynamic outlet groups: machine assigns outlets at runtime for load balancing.
• Sequence sorting: support for multi‑pass sequencing, walk positions, and optional volume information to allocate outlets.
• Actions supported: sort to outlets, sequence mail, print on label/mail, show on display, sweep operations.
• Cards: definition and requests to separate mail during sequence sorting.
• Operational features: sorting of code ranges, rejects handling, sorting to multiple outlets, overflow handling, cut‑off time before dispatch.
• Text and label support: display and label texts, multiple label/display formats and layouts, literal and variable content, barcode printing.
• Extensibility and checks: optional manufacturer‑specific fields and validation against sorting machine characteristics.
• No normative references: the TS stands alone for its scope.

Applications

• Postal operators and mail centers using mixed-vendor sorting lines to ensure interoperable sort plans across different suppliers.
• Sorting machine manufacturers and software developers implementing the open interface for receiving, parsing, and validating sort plans.
• System integrators and procurement teams writing tenders or integrating heterogeneous automation equipment to reduce project‑specific interfaces and integration costs.
• IT teams that generate or manage sorting configuration files as part of mail routing, sequencing, and label-print workflows.

Related standards

• Prepared by CEN/TC 331 (Postal Services) and intended as an open interface for postal automation. The specification complements other CEN postal interoperability work and can be used as a reference in procurement and integration projects.

Standards Content (Sample)

SLOVENSKI STANDARD
01-september-2012
3RãWQHVWRULWYH2GSUWLYPHVQLNL6RUWLUQLQDþUW
Postal services - Open interface - Sortplan
Postalische Dienstleistungen - Offene Schnittstelle - Sortierplan
Services postaux - Interface ouverte - Plan de tri
Ta slovenski standard je istoveten z: CEN/TS 16316:2012
ICS:
03.240 Poštne storitve Postal services
35.200 Vmesniška in povezovalna Interface and interconnection
oprema equipment
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

TECHNICAL SPECIFICATION
CEN/TS 16316
SPÉCIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION
June 2012
ICS 03.240; 35.240.99
English Version
Postal services - Open interface - Sortplan
Services postaux - Interface ouverte - Plan de tri Postalische Dienstleistungen - Offene Schnittstelle -
Sortierplan
This Technical Specification (CEN/TS) was approved by CEN on 9 January 2012 for provisional application.

The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to submit their
comments, particularly on the question whether the CEN/TS can be converted into a European Standard.

CEN members are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS available
promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in parallel to the CEN/TS)
until the final decision about the possible conversion of the CEN/TS into an EN is reached.

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, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom.

EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2012 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 16316:2012: E
worldwide for CEN national Members.

Contents Page
Foreword .3
Introduction .4
1 Scope .5
2 Normative references .5
3 Terms and definitions .5
4 Format .6
5 Definition of sort plan concepts .6
5.1 Sort plan concepts general .6
5.2 Definition of SortingProducts .6
5.2.1 Item related .6
5.2.2 Machine related .7
5.3 Definition of Cards .7
5.4 Definition of Actions .7
5.4.1 Sort to outlets .7
5.4.2 Sequence mail .7
5.4.3 Print on label .8
5.4.4 Show on display .8
5.4.5 Print on mail item .8
5.4.6 Sweep .8
6 Structure of the sort plan file .8
6.1 Sort Plan .8
6.1.1 General .8
6.1.2 Flag .9
6.1.3 MailAttribute . 10
6.1.4 Card . 10
6.1.5 SortingProduct . 11
6.1.6 Destination . 11
6.1.7 CardRequest . 12
6.1.8 SpecialSort . 12
6.2 OutletGroup . 12
6.3 SweepGroup . 13
6.4 Action . 14
6.4.1 General considerations . 14
6.4.2 Sort . 14
6.4.3 Print . 15
6.4.4 Sweep . 15
7 Precedence rules . 15
7.1 General considerations . 15
7.2 Sorting Product . 16
7.3 Action . 16
8 Implementation chart . 16
Annex A (informative) XML data . 17
A.1 XML data structure . 17
A.2 Example of Destination Sort Plan . 29
A.3 Example of Sequence Sort Plan . 30

Foreword
This document (CEN/TS 16316:2012) has been prepared by Technical Committee CEN/TC 331 “Postal
Services”, the secretariat of which is held by NEN.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such patent rights.
This document has been prepared under a mandate given to CEN by the European Commission and the
European Free Trade Association.
According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following
countries are bound to announce this Technical Specification: 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, Romania, Slovakia, Slovenia,
Spain, Sweden, Switzerland, Turkey and the United Kingdom.

Introduction
In a very generic postal system architecture, an Information System manages the creation, production and life
cycle of sort plans. This Information System is also responsible for distributing sort plans to Sorting Machines.
Sorting machines use several configuration files. A sort plan is a kind of configuration file dedicated to the
description of sorting operations executed by a sorting machine. Sorting operations are mainly the assignment
of mail items to physical outlets, the display text and the tray labels. As both, the Information System and the
several types of Sorting Machines, have to interpret this sort plan file. This file format therefore is the interface
between them.
In order to optimise performance, there is a growing demand of the postal operators to combine parts of their
sorting automation equipment from different suppliers. In the past this has led to project-specific interfaces
being negotiated between one postal operator and one or multiple suppliers. These project-specific interfaces
were developed by the suppliers and maintained for an agreed period of time. However, this approach has
several disadvantages:
 the interface is derived from an interface that was not intended to be open;
 the interface is developed for a single project and works only in the context of that project (extra costs);
 each participating supplier has to implement the interface (multiple efforts);
 experience shows that integration of components with project-specific interfaces is complex and
expensive;
 project-specific interfaces are not integrated into the product line and once the initially agreed
maintenance period is over it may be difficult and expensive to maintain and/or may hinder the adoption
of equipment upgrades.
This has led to “open interfaces” defined by one supplier. Yet these still have the disadvantage of being in
product use only by one supplier.
Within a group of postal operators and suppliers, it was decided to develop a set of “open standard interfaces”
which will be developed by the suppliers and referred to by the postal operators. It was explained that the
benefits of these interfaces will be that they:
 are fixed in an international standard (with change control);
 are agreed and implemented by major suppliers;
 are agreed by customers and therefore used in calls for tenders;
 will result in net savings, higher initial development effort and consequent higher basic equipment prices
being more than offset by reduced project development, integration and maintenance costs;
 will minimize the need for project integration effort by reducing implementation timescales;
 will increase competition between suppliers by stimulating product improvements.
This technical specification is based on the "Common Sortplan Format" which was used in projects before this
standard was developed.
1 Scope
This Technical Specification specifies the sort plan file content and structure. It does not deal with other
configuration files in sorting machines nor is it applicable to the transport mechanism.
The content of a sort plan allows the specification of the following capabilities:
 sorting by address and non-address attributes;
 sorting of code ranges;
 sorting of rejects;
 support of display and label texts;
 dynamic outlet groups;
 sorting to more than one outlet;
 overflow handling;
 support of cut off time before dispatch;
 sequence sorting;
 provide volume information (option);
 support of Cards;
 possibility to add simple manufacturer specific information;
 support of various sort code formats and non-address attributes;
 support of various display and label formats;
 check against characteristics of the sorting machine.
2 Normative references
There are no normative references for this document.
3 Terms and definitions
3.1
configuration file
one of the different files specifying actions to be processed by a sorting machine during operation time
3.2
configuration file set
complete set of configuration files needed by a machine to operate at a given time
3.3
cut off time
time to empty a certain outlet of a machine for dispatch
3.4
dispatch time
time when the transport leaves the sorting centre
3.5
dynamic outlet groups
outlets automatically assigned by the Machine Control during processing operation according to a defined set
of rules
3.6
outlet
output bin or stacker of a sorting machine
3.7
separation
characterization of a part of the mail flow processed by a machine
3.8
sort plan
configuration file specifying sort operations, that is, the assignment of mail items to outlets
4 Format
The sort plans are exchanged as Unicode text files, and are therefore printable: Unicode 16 bits is used. As a
deviation, the Unicode 32 bits could be used if necessary. The encoding used is the UTF 8 standard.
The XML language is used to describe the content of a sort plan. As such, a sort plan can be validated against
a formal specification, which can be found in A.1.
5 Definition of sort plan concepts
5.1 Sort plan concepts general
This Clause defines the main concepts of the sort plan; the structural details are given in Clause 6.
The sort plan consists mainly of defining the sorting products (what is sorted), the cards and the actions
performed on these sorting products.
5.2 Definition of Sorting Products
5.2.1 Item related
Item related conditions are attached to and travel with the mail item (i.e. they are intrinsic to the mail item).
The format supports classifying mail by the following item related attributes:
a) destination;
NOTE Destination is expressed by a sortcode.
b) other item attributes.
EXAMPLE Priority or MailFormat.
5.2.2 Machine related
Machine related conditions describe events that occur on a machine, but will often not travel with the mail item.
These are referred to as special sorts.
EXAMPLE Mechanical reject or overflow.
The format supports building reasonably complex classifications. Please note that in reality classifications are
typically built from either item-related or machine-related conditions but not from both.
5.3 Definition of Cards
Cards are typically used to separate the mail in the outlet during sequence sorting. The sort plan supports the
following information:
a) definition of a Card;
b) request for a Card at a specific position in the sequence of mail.
5.4 Definition of Actions
5.4.1 Sort to outlets
The most important action is to sort a mail item to a given outlet or a group of outlets. Specifying the
destination on the machine comes in two options:
 Static outlet allocation. The specified outlet points to a physical outlet on the machine. If more than one
outlet is specified, these should all be used for the same classification and effectively just form a “bigger
outlet”. The machine can decide if it wants to fill up the outlets of a group one after the other or all at the
same time.
 Dynamic outlet allocation. This only makes sense when more than one outlet is specified. The machine
chooses an outlet for the first mail item of each classification and sorts subsequent mail items of the same
classification to the same outlet until the outlet is emptied. In theory, the number of SortingProducts can
exceed the number of outlets as long as not all products “occur” at the same time.
A group of outlets may be defined either by enumerating the names of the outlets or by indicating the number
of outlets needed in this group.
5.4.2 Sequence mail
Mail can be sequenced using two or more passes. Either a separate sort plan for each pass or a single sort
plan that contains enough information so the machine knows what to do in each pass can be used. The latter
is the more elegant solution because the machine can make better use of volume information gathered in the
first pass.
In order to sequence mail, the sort plan includes the following information:
 the walk position of each destination within its respective postman walk;
 the fact that this mail shall be sequenced (in case not all mail that is fed to this sort plan shall be
sequenced);
 optionally volume information, so the machine can allocate enough outlets.
5.4.3 Print on label
Mail bundles are often shipped with a label that is printed on-demand by a label printer. The labels contain
Text and often a Barcode.
 Label layouts. Sometimes different label layouts requiring different fields are in use. The format allows
for the use of different label layouts.
 Literal content. Most label fields will contain literal text, i.e. text that shall be printed verbatim or printed
as a barcode.
 Variable content. Some fields may be populated with keywords that will be evaluated at runtime. A
typical example is the current date. This specification does not prescribe the list nor describes the format
of such keywords.
5.4.4 Show on display
Displays are treated in basically the same manner as labels except Displays are usually much simpler than
Labels. A regular two lines Display will typically accept only a single Format consisting of two lines of text.
5.4.5 Print on mail item
This format has no special support for controlling the printing of barcodes or cancellation bitmaps on mail
items. This should be done in separate configuration files.
5.4.6 Sweep
Sometimes outlets need to be emptied at a certain point in time or when other conditions become true. This is
referred to either as
 clearance times (sweep at a certain point in time), or
 sweep groups (sweep together with other Sorting Products).
The machine can use this information to either sweep some outlets with a robot or to signal a human operator
what outlets to sweep.
6 Structure of the sort plan file
6.1 Sort plan
6.1.1 General
The entire file is a single sort plan. In this clause, the file structure is described in a formal way. Practical
examples are given in A.2 (Destination Sort Plan) and A.3 (Sequence Sort Plan).
Figure 1 — SortPlan
The attributes of the sort plan are:
 Name (required): the name of the sort plan;
 Version (optional): an identification of the version of the sort plan;
 Comment (optional): a free text field for comment;
 Valid From (optional): date from which the sort plan may be used by the sorting machine. If this field is not
used the sort plan may be used by the machine as soon as it receives it;
 Id (optional): a unique identifier as handle for external information system.
6.1.2 Flag
Arbitrary name-value pairs can be attached to a sort plan (see Figure 2). This is used to express machine-
specific extensions.
Figure 2 — Flag
6.1.3 MailAttribute
A MailAttribute is a list of non-address attributes such as mail format, weight, priority, etc (see Figure 3).

Figure 3 — Mail Attribute
A MailAttribute is identified by its name: a unique key inside the sort plan is used to identify this occurrence of
Mail Attribute. This name is mainly used by the sort plan management system.
A MailAttribute is described by a list of couple measurement – value:
 measurement: The name of the measurement performed by the machine on mail items. This string
should be recognised as a keyword by the target machine software.
EXAMPLE 1 measurement ="length"
 value: The description of the set of value for this category. The target machine software should know how
to interpret the format of this string.
EXAMPLE 2 measurement ="length" value="[10mm, 100mm]"
Inside a MailAttribute, the pairs of measurement - value are combined together with a logical AND.
It is essential that the MailAttributes used within a single sort plan do not overlap.
6.1.4 Card
Cards are used as separators, mostly within sequencing sort plans (see Figure 4).

Figure 4 — Card
The Card section maps card codes to card types ("colors"). Typically, there are several codes that are
mapped to the same type.
6.1.5 SortingProduct
The SortingProduct describes "what the machine produces". This is typically the content of an Outlet (see
Figure 5).
Figure 5 — SortingProduct
6.1.6 Destination
The Destination describes a set of Addresses possibly combined with MailAttributes. Addresses are
represented by Sortcode Ranges (see Figure 6).

Figure 6 — Destination
Foreign destinations are also represented by Sortcodes which may live in a per-country address space. This
can be achieved by prefixing the Sortcodes of foreign destinations with a country prefix.
Sortcode ranges are defined by a SortcodeLow and a SortcodeHigh which shall have the same length and
format. The set of Sortcodes that fall into a range is defined as all Sortcodes, S, such that SortcodeLow <= S
<= SortcodeHigh. The less-or-equal operator (<=) has an obvious meaning for numeric codes but may require
clarification for alphanumeric codes.
In sequencing sort plans, each sortcode range should have a walkPosition, which describes the relative
position of an address within a postman's walk. Additionally, a mailVolume attribute can be used to indicate
the expected number of mail items for this address. This can be used by the machine to allocate outlets in an
optimal way, or to refuse to load the sort plan in cases where mail volume is too large.
6.1.7 CardRequest
The CardRequest causes a Card to be sorted in front of a specific walkPosition within a postman's walk (see
Figure 7).
Figure 7 — CardRequest
Dynamic Cards (with isDynamic=true) will only be requested if there is a corresponding mail item at the given
walkPosition. Consequently, there must be at least one Destination with the same walkPosition. Static Cards
will be requested unconditionally and they can have a unique or an already-used walkPosition. More than one
card may be requested by setting the attribute numberOf to an integer larger than one.
6.1.8 SpecialSort
A SpecialSort is an event that may occur while the mail item is being processed (see Figure 8).

Figure 8 — SpecialSort
Typical examples are “REJECT” or “OVERFLOW”. The set of available special sorts is usually very machine-
specific.
6.2 OutletGroup
An OutletGroup is a group of physical outlets (see Figure 9).
Figure 9 — OutletGroup
An OutletGroup can be static or dynamic. A static OutletGroup can only accept a single SortingProduct even if
the OutletGroup contains more than one outlet. A dynamic OutletGroup can accept several SortingProducts;
the machine makes sure they are properly separated.
The sequencing pass indicates for which pass an OutletGroup is defined. The idea is to split up the available
outlets into several groups. This splitting can be done for each sequencing pass separately.
OutletGroups can be specified either by a machine enumerating all its outlets or by specifying only the number
of outlets in that group. In the latter case the machine is free to allocate those outlets where needed.
Especially in sequencing a sort plan, it is often the case that it is preferable to divide the sorting machine into
several sections like "sequencing", "direct outlet assignments" and "special sorts". These kinds of
OutletGroups shall carry a "specialType" attribute whose values shall be negotiated with the machine
manufacturer. It is good practice to name an OutletGroup so it reflects the sequencing pass (e.g. "Walk3-
Pass2").
Regular user-definable outlet groups do not need a specialType attribute and can be given any name.
The following names are suggestions for how to name specialTypes:
 stdArea - Area used for direct-stackers assignments (i.e. mail that shall not be sequenced even though
the sort plan is a sequencing sort plan);
 seqArea - Area used for sequenced mail;
 rejectArea - Area for SpecialSort;
st
 seqOvfArea - Area for overflow stackers, typically used in the 1 pass when the mail volume is not yet
precisely known. This area consists of all the remaining stackers.
Each area can be defined for every pass and for each pass the sum of all outlets in all areas shall be (less or)
equal to the number of outlets in the machine.
6.3 SweepGroup
SortingProducts that belong to the same SweepGroup shall be swept together (see Figure 10). The machine
may either signal to a human operator that some outlets need sweeping or it may have a robot that carries out
this function.
Figure 10 — SweepGroup
The SweepType shall be set to a value that has been negotiated with the machine manufacturer and
describes the event that triggers a sweep, e.g. "clearance".
6.4 Action
6.4.1 General considerations
Actions describe what the machine shall do with a mail item that falls into a specified SortingProduct (see
Figure 11).
Figure 11 — Action
6.4.2 Sort
A Sort action is specified by a SortingProduct and the OutletGroup where it shall be sorted to (see Figure 12).
Additionally, it is possible to specify a position within that OutletGroup (only meaningful for dynamic
OutletGroups in sequencing) and to specify if mail shall be sequenced or not.
In sequencing, the position indicates the order of the SortingProduct in the dynamic OutletGroup (both are
linked by an action): in this way, the walks can be ordered in the last pass.

Figure 12 — Sort
This allows any combinations of direct outlet assignments and sequencing over any number of passes. A real
sorting machine will most likely restrict the possibilities quite a bit.
The sorting machine can use the sortType indicator to increment different counters.
EXAMPLE Outward, Delivery Office, Walk or Sequenced Walk
Note that there is no well-defined meaning for the attempt to sort a product more than once. Thus, for any
Product there should only be a single Sort action.
6.4.3 Print
The Print action describes what shall be printed on a label or a display for mail items that fall into a
...