The current and future infrastructure to satisfy the changing needs of citizens in the EU will grant access
to wider postal stakeholders, including customers, postal suppliers, supply chain service providers, (i.e.
customs, fiscal authorities collecting VAT and related duties, transport providers like airlines or rail road
and other transport mode operators, non-profit organisations supporting supply chain traceability, etc.)
non-designated economic postal operators (Courier-, Express-, and Parcel delivery operators) that use,
or may wish to use products, services and solutions currently restricted to designated operators.
This document aims at the provision of a Single Digital Market in Europe is at the focus within CEN, in
particular:
• maintaining the integrity and independence of the European and worldwide delivery network
• no unfair advantage to any group or individual player, and thereby providing a level playing field
• clear delineation of the responsibilities and roles of all entities involved
• transparent management, control and integration of the postal supply chain as legally described in
EU legislation (EU Regulation 2018/644 on cross-border parcel delivery services)
• reciprocity of interconnection with other stakeholder networks, as applicable
• proper security mechanisms in place to ensure data protection and privacy
to provide the necessary implementation guidance of EAD for fiscal duties (VAT et al.), customs and
transport security.
The current MoU between the UPU and CEN offers the foundation to convert UPU specifications only
applicable to designated postal operators into open CEN specifications. The creation of a digital single
market has significant implications on cross border commerce and related delivery of merchandise.
This document provides the necessary implementation guidance. It is based on be the technical report
“Postal Services — Electronic advanced data (EAD) in postal operations compliant to security and
customs requirements”.
The document is based on the semantic mapping description of information on the characteristics or
attributes of Low Value Consignments (LVC) which parties in the digital commercial value chain acrossborders
are called upon to handle, compliant to the EU VAT Ecommerce Package as well as the UPU-WCO
customs model. It gives guidance by defining the use of unique transport identifiers, unique transaction
identifiers and the IOSS VAT Identification number.

  • Technical report
    53 pages
    English language
    sale 10% off
    e-Library read for
    1 day
  • Technical report
    52 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This document provides the semantic mapping description of information on the characteristics or
attributes of Low Value Consignments (LVC) which parties in the digital commercial value chain acrossborders
are called upon to handle, compliant to the EU VAT Ecommerce Package as well as the UPU-WCO
customs model.
This document is limited to LVC, the logical definition of an electronic message, which supports the
communication of information about postal items with a unique transport unit identifier.
While different customs processes apply to LVC (goods ≤ €150), and consignments exceeding an intrinsic
value of > €150, this technical specification only applies to LVC. Therefore, it applies to the collection of
import duties (VAT) and not to customs fees.
The document defines both EDIFACT directory 00A and XML implementations to bridge in a semantic
mapping between UPU M33 ITMATT messages and the EU customs data model and its super-reduced
data set, that can be used to convey item-level data for use in customs processing applications.
The document specifies that the supply of certain attribute values, segments and tags is mandatory (M),
whilst the supply of other attributes, segments and tags is specified as optional (O).
This document separates the financial, the data-elements and the physical flow of low value
consignments. Further it defines the use of unique transport identifiers, unique transaction identifiers
and the IOSS VAT Identification number.

  • Technical report
    93 pages
    English language
    sale 10% off
    e-Library read for
    1 day
  • Technical report
    98 pages
    English language
    sale 10% off
    e-Library read for
    1 day

2020-07-08 - TC - Correction of two formats in rows "Item identifier" and "Additional barcode" in Table 1

  • Corrigendum
    3 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This technical specification describes the technical features of digital, optional online connected, opening and closing systems for parcel receptacles for home use with free access for the delivery and collection operators and consumers.

  • Technical specification
    22 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This document specifies the information exchanges between various parties' infrastructures that take place in support of DPM applications. It complements standards that address the design, security, applications and readability of Digital Postage Marks.
The following items will be addressed by this document:
-   identification of parties participating in exchanges of information described by this document;
-   identification of functions (interactions, use cases);
-   definition of parties’ responsibilities in the context of above functions;
-   definition of messages between parties: message meaning and definition of communication protocols to support each function;
-   definition of significant content (payload) for each message;
-   security mechanisms providing required security services, such as authentication, privacy, integrity and non-repudiation.
This document does not address:
-   design of DPM supporting infrastructure for applications internal to providers and carriers;
-   design of DPM devices and applications for applications internal to end-users.
NOTE   Although there are other communications between various parties involved in postal communications, this document covers only DPM-related aspects of such communications.

  • Technical specification
    44 pages
    English language
    sale 10% off
    e-Library read for
    1 day
  • Technical specification
    43 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This document will specify the interface between the e-merchant (any commercial customer sending parcels) and the first logistic operator, including both public and private carriers. For the application of this document, a cross border parcel is a parcel crossing a border into and within Europe.
The interface composed on two items:
- the physical label attached on the parcel: contents, sizes, minimum requirements to guarantee the quality and efficiency of the logistic process (sorting, delivery).
- the electronic exchanges between the sender and the logistic operator with the description of the data to be provided, the forma of the exchanges.
While designated operators of UPU have drawn up business requirements using proprietary standards and related data components, online merchants have developed open, not‐for‐profit standards for final delivery which are integrated into their existing supply chain management environment.
The document aims to specify the interface between the e‐merchant (any commercial customer sending parcels) and the first logistic operator composed by incorporating the 3 elements:
- physical label attached to the parcel with information for item identification;
- electronic exchanges between the sender and the logistic operator concerning parcels dispatch;
- data needed for various delivery chain parts, in particular final delivery to the recipient, in order to facilitate exchange between the item‐specific identifiers.
NOTE 1 The last element enables the growth of integrated, data‐driven systems which support highly efficient and customer‐driven cross‐border ecommerce. This reflects the current trend to B‐to‐B‐to‐C delivery solutions in the European and international cross border e‐commerce markets. Delivery from original source to final consumer can be split over more than one service provider.
NOTE 2 C‐to‐B‐to‐B‐to‐C solutions will be an extension, in particular when returns are specified. The “first C” would indicate that consumers wishing to return items, or induct items themselves, will be able to print labels following the fundamentals specified in this standard.
E‐merchant exchange data with logistic operators (i.e. the postal operators, but not limited to those designated to fulfil the rights and obligations of UPU member countries) to help, simplify and enable the consequential logistic and transactional tasks. The establishment of common definitions and electronic formats, safeguards the reliability and decreases the overall costs by avoiding software development costs, multiple printing equipment, over‐labelling during the process, and the manual sorting. reliability and decreases the overall costs by avoiding software development costs, multiple printing equipment, over‐labelling during the process, and the manual sorting.

  • Technical specification
    32 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This document will specify the interface between the e-merchant (any commercial customer sending parcels) and the first logistic operator, including both public and private carriers. For the application of this document, a cross border parcel is a parcel crossing a border into and within Europe.
The interface composed on two items:
- the physical label attached on the parcel: contents, sizes, minimum requirements to guarantee the quality and efficiency of the logistic process (sorting, delivery).
- the electronic exchanges between the sender and the logistic operator with the description of the data to be provided, the forma of the exchanges.
While designated operators of UPU have drawn up business requirements using proprietary standards and related data components, online merchants have developed open, not‐for‐profit standards for final delivery which are integrated into their existing supply chain management environment.
The document aims to specify the interface between the e‐merchant (any commercial customer sending parcels) and the first logistic operator composed by incorporating the 3 elements:
- physical label attached to the parcel with information for item identification;
- electronic exchanges between the sender and the logistic operator concerning parcels dispatch;
- data needed for various delivery chain parts, in particular final delivery to the recipient, in order to facilitate exchange between the item‐specific identifiers.
NOTE 1 The last element enables the growth of integrated, data‐driven systems which support highly efficient and customer‐driven cross‐border ecommerce. This reflects the current trend to B‐to‐B‐to‐C delivery solutions in the European and international cross border e‐commerce markets. Delivery from original source to final consumer can be split over more than one service provider.
NOTE 2 C‐to‐B‐to‐B‐to‐C solutions will be an extension, in particular when returns are specified. The “first C” would indicate that consumers wishing to return items, or induct items themselves, will be able to print labels following the fundamentals specified in this standard.
E‐merchant exchange data with logistic operators (i.e. the postal operators, but not limited to those designated to fulfil the rights and obligations of UPU member countries) to help, simplify and enable the consequential logistic and transactional tasks. The establishment of common definitions and electronic formats, safeguards the reliability and decreases the overall costs by avoiding software development costs, multiple printing equipment, over‐labelling during the process, and the manual sorting. reliability and decreases the overall costs by avoiding software development costs, multiple printing equipment, over‐labelling during the process, and the manual sorting.

  • Technical specification
    32 pages
    English language
    sale 10% off
    e-Library read for
    1 day

The revision of EN 14142-1 aims at bringing together current an ongoing efforts within the Universal Postal Union (a special organisation of the United Nations), the CEN and ISO to create one global standard under the ISO/TC211 for International postal address components and template languages.
This document forms part 4 of ISO 19160. ISO 19160 consists of the following parts, under the general title Addressing:
Part 1: Terminology and conceptual model
Part 2: Good practices for address assignment schemes
Part 3: Quality management for address data
Part 4: International postal address components and template languages
Traditionally, postal operators have been highly flexible with regard to the manner in which postal items can be addressed: any form and content of address was acceptable as long as it permitted sufficiently unambiguous determination of the delivery point. Even today, many posts pride themselves on their ability, using staff intelligence and local demographic knowledge, to deliver postal items carrying incomplete or unusual address representations.
It has become more and more vital to ensure that the vast majority of postal items are addressed in a way which can be processed automatically, without risk of misinterpretation.
Today, the vast majority of postal items carry printed addresses which are extracted from computer databases.
Such databases need to be maintained in the face of population mobility, creation and suppression of delivery points and changes in their specification such as renaming of streets, renumbering of properties, etc. Moreover, there is a growing tendency for companies to exchange or trade address data and, in the context of the European Single Market, for companies in one country to hold address data of organisations and individuals in other countries, which might use different approaches to the structuring of printed addresses.
Addresses can be rendered according to rules that differ from country to country or from one mailing to another. This part of ISO 19160 does not impose any obligation on countries or mailers on how addresses shall be rendered but provides a language to express rendering rules recommended by postal operators or for various mailing purposes.
Templates specified according to this part of ISO 19160 may be used to exchange information about address rendering rules on international cross border mail and domestic mail.
This part of ISO 19160 defines key terms, a dictionary of postal address components and constraints on the use of the components. Further this part of ISO 19160 defines languages suitable for human comprehension and computer processing to formally express address rendering rules that stipulate how a postal address is to be written, including the order in which postal address components are to appear, required and optional components, and the presentation or rendition of the components, subject to constraints on the space available for that task. A formal expression of address rendering rules provided in one of the specified languages is defined in this part of ISO 19160 as postal address template.
This standard provides a dictionary of the possible components of postal addresses, together with examples of and constraints on their use.
Specifically, this part of ISO 19160The standard defines three hierarchical levels of postal address component:
> segments, such as addressee specification, which correspond to major logical portions of a postal address;
> constructs, such as organisation identification, which group elements within segments into units which are meaningful for human interpretation;
> elements, such as organisation name or legal status, which correspond to the lowest level of constructs, i.e., those which are not themselves made up of subordinate elements, though they may be sub-divided for technical purposes.
To cover multiple occurrences and locations of elements in an address, and to be able where necessary to work with sub-divisions of eleme

  • Standard
    71 pages
    English language
    sale 10% off
    e-Library read for
    1 day

An IDT-PAE interface enables interoperability among several systems and processes by providing specifications to the following requirements:
a)   Data Collection and Transfer:  Specification of data transported from the devices to higher level systems.  There may be more than one permissible protocol referring to different OSI layers. The standard will define where the communication requires polling and where asynchronous messages are used.
   The basis is messages triggered by events.
b)   Data Storage and Format:  Specification how data is formatted and structured. This concerns the choice between XML, CSV, EDI, JSON and other formats including possible binary representations.
c)   Data Model:  Specification of the semantics (meanings) behind the data. This is the most important part and the one of the most important objectives for the specification. This means that conceptual data model and its mapping to the Data Format will be developed. Major focus on specifications level of detail will be placed in order to provide a document that will provide detailed specification information without being too general or too specific.

  • Technical specification
    84 pages
    English language
    sale 10% off
    e-Library read for
    1 day

An IDT-PAE interface enables interoperability among several systems and processes by providing specifications to the following requirements:
a)   Data Collection and Transfer:  Specification of data transported from the devices to higher level systems.  There may be more than one permissible protocol referring to different OSI layers. The standard will define where the communication requires polling and where asynchronous messages are used.
   The basis is messages triggered by events.
b)   Data Storage and Format:  Specification how data is formatted and structured. This concerns the choice between XML, CSV, EDI, JSON and other formats including possible binary representations.
c)   Data Model:  Specification of the semantics (meanings) behind the data. This is the most important part and the one of the most important objectives for the specification. This means that conceptual data model and its mapping to the Data Format will be developed. Major focus on specifications level of detail will be placed in order to provide a document that will provide detailed specification information without being too general or too specific.

  • Technical specification
    84 pages
    English language
    sale 10% off
    e-Library read for
    1 day

The purpose of this Technical Specification is to define the syntax rules for a data stream for the submission of printing data to a Hybrid Mail operator or between Hybrid Mail operators. The Technical Specification defines a XML Schema Definition (XSD) describing the data stream.
The description is based upon the XML (eXtended Mark-up Language) definition of rules and semantics for defining an XSD. The purpose of this is to offer a generalised syntax description that can provide seamless integration with a number of existing applications generating data that is liable to be forwarded to or from a Hybrid Mail operator.
The use of an XSD will ensure that the documents confirm to the standard defined and that the output has the correct syntax. Software manufacturers can use an XSD to program applications that will produce correct outputs.
This Technical Specification defines the syntax for creating a data stream that will eventually be converted into a deliverable. The overall object (a batch) can be divided into one or more objects that again can be divided into objects. The hierarchy includes bundles that contain a common part and letters. Each object has a number of characteristics attached to it.
This diagram shows the structure of a HML (Hybrid Mail Language) document: each letter is self-contained (contains all the necessary information to be delivered on a certain destination).
Each letter can have one contact. Each contact can have multiple alternatives for delivery.
This Technical Specification does not define the specific services offered by local operators (Hybrid Mail operators).
This Technical Specification does not define the communication method used. It does only define the format of Hybrid Mail as such.

  • Technical specification
    58 pages
    English language
    sale 10% off
    e-Library read for
    1 day

The purpose of this Technical Specification is to define the syntax rules for a data stream for the submission of printing data to a Hybrid Mail operator or between Hybrid Mail operators. The Technical Specification defines a XML Schema Definition (XSD) describing the data stream.
The description is based upon the XML (eXtended Mark-up Language) definition of rules and semantics for defining an XSD. The purpose of this is to offer a generalised syntax description that can provide seamless integration with a number of existing applications generating data that is liable to be forwarded to or from a Hybrid Mail operator.
The use of an XSD will ensure that the documents confirm to the standard defined and that the output has the correct syntax. Software manufacturers can use an XSD to program applications that will produce correct outputs.
This Technical Specification defines the syntax for creating a data stream that will eventually be converted into a deliverable. The overall object (a batch) can be divided into one or more objects that again can be divided into objects. The hierarchy includes bundles that contain a common part and letters. Each object has a number of characteristics attached to it.
This diagram shows the structure of a HML (Hybrid Mail Language) document: each letter is self-contained (contains all the necessary information to be delivered on a certain destination).
Each letter can have one contact. Each contact can have multiple alternatives for delivery.
This Technical Specification does not define the specific services offered by local operators (Hybrid Mail operators).
This Technical Specification does not define the communication method used. It does only define the format of Hybrid Mail as such.

  • Technical specification
    58 pages
    English language
    sale 10% off
    e-Library read for
    1 day

The purpose of this Technical Specification is to define the requirements of the OCR/VCS Standard interface and to convey these requirements in context to the reader.
This document is arranged under 4 main clauses as described in Figure 1:
-   UCM (Use Case Model) describes the use cases for the IC/ED Interface using sequence diagrams with messages.
-   IDD (Interface Design Description) defines the data model for the IC/ED interface.
-   SDD (System Design Description) defines the mandatory specification of the IC/ED interface in terms of architecture, services and behavioural models. In the Common Part of this clause no middleware or transport layer is specified. The common part of this clause is intended to be middleware-independent.
-   SDD-TCP/IP, SDD-CORBA, in these specialized clauses. The specifications for 2 compatible transport solutions TCP/IP, CORBA are provided. Further middleware solutions (such as SOAP) can be added when available, provided that they are fully compatible with the Common Part.
(...)
As shown on Figure 2, there are many interfaces from an Enrichment Device to the rest of the system. This document is only concerned with the Mailpiece Processing part of the complete Standard Interface.
The mailpiece processing is concerned with the passing of a mailpiece to an Enrichment Device for processing.
(...)
Figure 3 depicts the system model of an Enrichment Device. As visible on the figure, an Enrichment Device is one of:
-   an OCR:
a single or a pool of automatic recognition and interpretation engines, which are capable of retrieving information from an image of a mailpiece without human intervention;
-   a VCS:
a single or a pool of video coding desks, which produce results from images of mailpieces; all tasks related to the management of the coders and the coding desks are encapsulated within the VCS system, or are accessible via interfaces which are outside the scope of the interface described within this document;
-   a Voter:
a system which can determine the most appropriate result for a mailpiece using data and/or an image of a mailpiece; typically, a voter determines the most appropriate result from two or more results.
This document therefore covers the Mailpiece Processing interface between the Image Controller and the Enrichment Devices.
The document describes the requirements in the case of real-time enrichment: operational mode of an Enrichment Device, where the ED replies within the specified expiration time to the IC; the IC has to keep track of all mailpieces waiting for a reply from an ED. The ED does not keep persistence of mailpieces outside a channel connection with the IC. The ED has to have the processing power available to enrich a mailpiece. There is one and only one response for a mailpiece.
A later version of the document shall describe the case of deferred enrichment: operational mode of an Enrichment Device, where the ED may pre-request mailpieces from the IC. The ED has to keep persistence of the mailpiece to enrich it later and keep the result available for a result request from the IC. There is no response expected by IC from the ED.
The interface between Image Controller and Image Controller is NOT part of this document.
Furthermore, there may be many IC connected to many ED’s, as shown in the following object model:
(...)
The submission strategy in case of one IC connected to many ED’s is not part of the interface. It is for optimizing the mail flow in case of identical ED’s, or for defining the order in which different ED’s are activated (cascaded versus parallel submission).
The submission strategy of the IC shall be part of the specification and certification of the IC, which is not part of this document.

  • Technical specification
    237 pages
    English language
    sale 10% off
    e-Library read for
    1 day

The purpose of this Technical Specification is to define the requirements of the OCR/VCS Standard interface and to convey these requirements in context to the reader.
This document is arranged under 4 main clauses as described in Figure 1:
-   UCM (Use Case Model) describes the use cases for the IC/ED Interface using sequence diagrams with messages.
-   IDD (Interface Design Description) defines the data model for the IC/ED interface.
-   SDD (System Design Description) defines the mandatory specification of the IC/ED interface in terms of architecture, services and behavioural models. In the Common Part of this clause no middleware or transport layer is specified. The common part of this clause is intended to be middleware-independent.
-   SDD-TCP/IP, SDD-CORBA, in these specialized clauses. The specifications for 2 compatible transport solutions TCP/IP, CORBA are provided. Further middleware solutions (such as SOAP) can be added when available, provided that they are fully compatible with the Common Part.
As shown on Figure 2, there are many interfaces from an Enrichment Device to the rest of the system. This document is only concerned with the Mailpiece Processing part of the complete Standard Interface.
The mailpiece processing is concerned with the passing of a mailpiece to an Enrichment Device for processing.
Figure 3 depicts the system model of an Enrichment Device. As visible on the figure, an Enrichment Device is one of:
-   an OCR:
a single or a pool of automatic recognition and interpretation engines, which are capable of retrieving information from an image of a mailpiece without human intervention;
-   a VCS:
a single or a pool of video coding desks, which produce results from images of mailpieces; all tasks related to the management of the coders and the coding desks are encapsulated within the VCS system, or are accessible via interfaces which are outside the scope of the interface described within this document;
-   a Voter:
a system which can determine the most appropriate result for a mailpiece using data and/or an image of a mailpiece; typically, a voter determines the most appropriate result from two or more results.
This document therefore covers the Mailpiece Processing interface between the Image Controller and the Enrichment Devices.
The document describes the requirements in the case of real-time enrichment: operational mode of an Enrichment Device, where the ED replies within the specified expiration time to the IC; the IC has to keep track of all mailpieces waiting for a reply from an ED. The ED does not keep persistence of mailpieces outside a channel connection with the IC. The ED has to have the processing power available to enrich a mailpiece. There is one and only one response for a mailpiece.
A later version of the document shall describe the case of deferred enrichment: operational mode of an Enrichment Device, where the ED may pre-request mailpieces from the IC. The ED has to keep persistence of the mailpiece to enrich it later and keep the result available for a result request from the IC. There is no response expected by IC from the ED.
The interface between Image Controller and Image Controller is NOT part of this document.
Furthermore, there may be many IC connected to many ED’s, as shown in the following object model:
The submission strategy in case of one IC connected to many ED’s is not part of the interface. It is for optimizing the mail flow in case of identical ED’s, or for defining the order in which different ED’s are activated (cascaded versus parallel submission).
The submission strategy of the IC shall be part of the specification and certification of the IC, which is not part of this document.

  • Technical specification
    237 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This Technical Specification constitutes the functional specification of a secure electronic postal service, referred to as the postal registered electronic mail or PReM service. PReM provides a trusted and certified electronic mail exchange between mailer, postal operators and addressee/mailee. In addition, evidence of corresponding events and operations within the scope of PReM will be generated and archived for future attestation.
The PReM service is defined by reference to the concepts, schemas and operations defined in CEN/TS 15121-1:2011. It utilises six SePS operational verbs (CheckIntegrity, LogEvent, Postmark, RetrieveResults, Sign and Verify) and the five additional server-side operational verbs (SendMessagetoDestination, Subscribe Notification, UnscbscribeNotification, RejectMessage and ReceiveNotification) to fulfil the operational requirements of a PReM System.
Return of Investment (ROI), market potential, revenues model, business plan and pricing policy are outside the scope of this functional specification. Postal operators are advised to make the necessary marketing study and research prior to considering leasing, procuring or developing such a PReM system in accordance with this functional specification.

  • Technical specification
    55 pages
    English language
    sale 10% off
    e-Library read for
    1 day

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.

  • Technical specification
    30 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This Technical Specification describes the “Open Standard Interface between Image Processor, Machine Control and Image Controller” (IP/MC/IC Interface) in the context of postal automation equipment.
The following architectural overview is the basis for this interface standardization:
It was agreed to unify the interfaces between
a) Image Processor and Image Controller,
b) Image Processor and Machine Control and
c) Machine Control and Image Controller
and to produce one common specification for this so-called IP/MC/IC Interface.
The communication partners of this interface will be called Machine or Machine Control (MC) on the one side and Reading/Coding (RC) System on the other side.
There may be several instances of this interface, depending on the implementation of the MC and the connected RC.
NOTE   interfaces for synchronizing the lifted images with their mailpiece_IDs provided by the machine are not shown in the figure above and are not subject of standardization within the first release of this interface.
From the customer point of view the following two scenarios are relevant. The systems MACHINE and RC SYSTEM are to be considered as "black boxes" thus not detailing internal system structure and interfaces.
1) The Machine already includes Camera and Image Processor and will be connected to a 3rd-party RC System including Image Controller and Enrichment Devices.
2) The Machine will be connected to a 3rd-party RC System including Camera, Image Processor, Image Controller and Enrichment Devices. The Camera and (possibly) the Image Processor will have to be mechanically integrated into the machine.
NOTE   The camera can be provided by any 3rd-party. This should not impede on the IP/MC/IC interfaces !
This standard is arranged under 4 main clauses as described in Figure 4.
- UCM (Use Case Model) describes the use cases for the IP/MC/IC Interface using sequence diagrams with messages.
- IDD (Interface Design Description) defines the data model (...)

  • Technical specification
    135 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This document defines a file format for the generation of postal address directories. It is designed to hold all information necessary to support address reading software including data required for forwarding applications. In typical postal automation systems these files will be processed by directory generation software which creates application specific loadable data. This data - usually referred to as operational directory - is heavily compressed and contains access tables tailored for the specific reading software.
Not in the scope of this document are topics external to file like compression, checksums, the interface for transmission to the supplier, modification permissions, error handling on inconsistent data and undo in updates.

  • Technical specification
    27 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This document defines a file format for the generation of postal address directories. It is designed to hold all information necessary to support address reading software including data required for forwarding applications. In typical postal automation systems these files will be processed by directory generation software which creates application specific loadable data. This data – usually referred to as operational directory – is heavily compressed and contains access tables tailored for the specific reading software.
Not in the scope of this document are topics external to file like compression, checksums, the interface for transmission to the supplier, modification permissions, error handling on inconsistent data and undo in updates.

  • Technical specification
    27 pages
    English language
    sale 10% off
    e-Library read for
    1 day

The scope will be defined during the preliminary stage.

  • Technical report
    93 pages
    English language
    sale 10% off
    e-Library read for
    1 day
  • Technical report
    98 pages
    English language
    sale 10% off
    e-Library read for
    1 day

The scope will be defined during the preliminary stage.

  • Technical report
    53 pages
    English language
    sale 10% off
    e-Library read for
    1 day
  • Technical report
    52 pages
    English language
    sale 10% off
    e-Library read for
    1 day

The objective of this document is to define the framework for secure, trustworthy and user-friendly opening systems for parcel boxes for home use. Particular attention is given to facilitating secure electronic authentication of the delivery operator. This document exists considering the Standardization request M/548 from the European Commission and it aims to solve the lack of operability between parcel box manufacturers and delivery operators.
Therefore, this document describes the minimal requirements of a digital, optional online connected, opening and closing system for parcel boxes and prerequisites to create favourable conditions of interoperability between all market participants.
This document is designed to fit with solutions already on the market and define the good practices and pathway for future systems. It adopts an approach which is open to innovation. It is expected to be possible to achieve the necessary requirements through different technologies.
The systems of opening rights are intended to open parcel boxes as defined in CEN/TS 16819. However, the specification is extended to other receptacle solutions, in the frame of the home use (e.g. garage door, bags, etc.), when these receptacle solutions are compliant with the requirements of CEN/TS 16819 when the case allows.

  • Technical specification
    22 pages
    English language
    sale 10% off
    e-Library read for
    1 day

2020-07-08 - TC - Correction of two formats in rows "Item identifier" and "Additional barcode" in Table 1

  • Corrigendum
    3 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This document:
- specifies a methodology for the measurement of defined print quality attributes of Digital Postage Marks in the form of two-dimensional bar code symbols on mail-pieces,
- defines methods for grading the results of these measurements and deriving an overall symbol quality grade as a guide to estimating the readability of the Digital Postage Marks,
- provides guidelines for printing and gives information on possible causes of deviation from high grades to assist users in taking appropriate corrective action,
- defines a test procedure for the assessment of printing systems for the production of Digital Postage Marks.
These provisions apply to the Digital Postage Mark blocks as they appear on fully produced mail items when remitted to postal operators, including the characteristics resulting from operations other than printing per se that affect their appearance to a mail processing system (covering, inserts into transparent window envelopes, affixed Digital Postage Mark labels).
This document does not define the qualification tests or sampling requirements necessary to determine the practical feasibility of any specific read rate.

  • Technical specification
    31 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This Technical Specification will specify the interface between the e-merchant (any commercial customer sending parcels) and the first logistic operator.
The interface is composed on two items:
-   the physical label stuck on the postal item: contents, sizes, minimum requirements to guarantee the quality and efficiency of the logistic process (sorting, delivery).
-   the electronic exchanges between the sender and the logistic operator with the description of the data to be provided, the format of the exchanges.
While designated operators of UPU have drawn up business requirements using proprietary standards and related data components, online merchants have developed open, not-for-profit standards for final delivery which are integrated into their existing supply chain management environment.
The Technical Specification aims to specify the interface between the e-merchant (any commercial customer sending postal items) and the first logistic operator composed by incorporating the 3 elements:
-   physical label attached to the postal item with information for item identification;
-   electronic exchanges between the sender and the logistic operator concerning parcels dispatch;
-   data needed for various delivery chain parts, in particular final delivery to the recipient, in order to facilitate exchange between the item-specific identifiers.
NOTE 1   The last element enables the growth of integrated, data-driven systems which support highly efficient and customer-driven cross-border ecommerce. This reflects the current trend to B-to-B-to-C delivery solutions in the European and international cross border e-commerce markets. Delivery from original source to final consumer can be split over more than one service provider.
NOTE 2   C-to-B-to-B-to-C solutions will be an extension, in particular when returns are specified. The “first C” would indicate that consumers wishing to return items, or induct items themselves, will be able to print labels following the fundamentals specified in this standard.
E-merchant exchange data with logistic operators (i.e. the postal operators, but not limited to those designated to fulfill the rights and obligations of UPU member countries) to help, simplify and enable the consequential logistic and transactional tasks. The establishment of common definitions and electronic formats, safeguards the reliability and decreases the overall costs by avoiding software development costs, multiple printing equipment, over-labelling during the process, and the manual sorting.

  • Technical specification
    56 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This Technical Specification will specify the interface between the e-merchant (any commercial customer sending parcels) and the first logistic operator.
The interface is composed on two items:
-   the physical label stuck on the postal item: contents, sizes, minimum requirements to guarantee the quality and efficiency of the logistic process (sorting, delivery).
-   the electronic exchanges between the sender and the logistic operator with the description of the data to be provided, the format of the exchanges.
While designated operators of UPU have drawn up business requirements using proprietary standards and related data components, online merchants have developed open, not-for-profit standards for final delivery which are integrated into their existing supply chain management environment.
The Technical Specification aims to specify the interface between the e-merchant (any commercial customer sending postal items) and the first logistic operator composed by incorporating the 3 elements:
-   physical label attached to the postal item with information for item identification;
-   electronic exchanges between the sender and the logistic operator concerning parcels dispatch;
-   data needed for various delivery chain parts, in particular final delivery to the recipient, in order to facilitate exchange between the item-specific identifiers.
NOTE 1   The last element enables the growth of integrated, data-driven systems which support highly efficient and customer-driven cross-border ecommerce. This reflects the current trend to B-to-B-to-C delivery solutions in the European and international cross border e-commerce markets. Delivery from original source to final consumer can be split over more than one service provider.
NOTE 2   C-to-B-to-B-to-C solutions will be an extension, in particular when returns are specified. The “first C” would indicate that consumers wishing to return items, or induct items themselves, will be able to print labels following the fundamentals specified in this standard.
E-merchant exchange data with logistic operators (i.e. the postal operators, but not limited to those designated to fulfill the rights and obligations of UPU member countries) to help, simplify and enable the consequential logistic and transactional tasks. The establishment of common definitions and electronic formats, safeguards the reliability and decreases the overall costs by avoiding software development costs, multiple printing equipment, over-labelling during the process, and the manual sorting.

  • Technical specification
    56 pages
    English language
    sale 10% off
    e-Library read for
    1 day

The purpose of this Technical Specification is to define the syntax rules for a data stream for the submission of printing data to a Hybrid Mail operator or between Hybrid Mail operators. The Technical Specification defines a XML Schema Definition (XSD) describing the data stream.
The description is based upon the XML (eXtended Mark-up Language) definition of rules and semantics for defining an XSD. The purpose of this is to offer a generalised syntax description that can provide seamless integration with a number of existing applications generating data that is liable to be forwarded to or from a Hybrid Mail operator.
The use of an XSD will ensure that the documents confirm to the standard defined and that the output has the correct syntax. Software manufacturers can use an XSD to program applications that will produce "correct" outputs.
This Technical Specification defines the syntax for creating a data stream that will eventually be converted into a deliverable. The overall object (a batch) can be divided into one or more objects that again can be divided into objects. The hierarchy includes bundles that contains a common part and letters. Each object has a number of characteristics attached to it.
This diagram shows the structure of a HML (Hybrid Mail Language) document: each letter is self-contained (contains all the necessary information to be delivered on a certain destination).

  • Technical specification
    49 pages
    English language
    sale 10% off
    e-Library read for
    1 day

The purpose of this Technical Specification is to define the syntax rules for a data stream for the submission of printing data to a Hybrid Mail operator or between Hybrid Mail operators. The Technical Specification defines a XML Schema Definition (XSD) describing the data stream.
The description is based upon the XML (eXtended Mark-up Language) definition of rules and semantics for defining an XSD. The purpose of this is to offer a generalised syntax description that can provide seamless integration with a number of existing applications generating data that is liable to be forwarded to or from a Hybrid Mail operator.
The use of an XSD will ensure that the documents confirm to the standard defined and that the output has the correct syntax. Software manufacturers can use an XSD to program applications that will produce "correct" outputs.
This Technical Specification defines the syntax for creating a data stream that will eventually be converted into a deliverable. The overall object (a batch) can be divided into one or more objects that again can be divided into objects. The hierarchy includes bundles that contains a common part and letters. Each object has a number of characteristics attached to it.
This diagram shows the structure of a HML (Hybrid Mail Language) document: each letter is self-contained (contains all the necessary information to be delivered on a certain destination).

  • Technical specification
    49 pages
    English language
    sale 10% off
    e-Library read for
    1 day

The purpose of this document is to define the requirements of the OCR/VCS Standard interface and to convey these requirements in context to the reader.
The interface specification is contained in the two appendices of this document, both of them normative:
·   System Design Description (SDD)
This document specifies the class model, dynamic behaviour and exception handling of the interface. The API is included.
·   Interface Design Document (IDD)
The IDD in Annex B defines the "payload" information for the interface. That is the data which is required for processing a mailpiece e.g.
Figure 1 - Interface environment of an Enrichment Device
As shown on Figure 1, there are many interfaces from an Enrichment Device to the rest of the system. This document is only concerned with the Mailpiece Processing part of the complete Standard Interface.
The mailpiece processing is concerned with the passing of a mailpiece to an Enrichment Device for processing.

  • Technical specification
    213 pages
    English language
    sale 10% off
    e-Library read for
    1 day

TC - B.6.3.4.3.5, 2nd paragraph - Correction of reference

  • Corrigendum
    2 pages
    English language
    sale 10% off
    e-Library read for
    1 day

TC - B.6.3.4.3.5, 2nd paragraph - Correction of reference

  • Corrigendum
    2 pages
    English language
    sale 10% off
    e-Library read for
    1 day

The purpose of this document is to define the requirements of the OCR/VCS Standard interface and to convey these requirements in context to the reader.
The interface specification is contained in the two appendices of this document, both of them normative:
·   System Design Description (SDD)
This document specifies the class model, dynamic behaviour and exception handling of the interface. The API is included.
·   Interface Design Document (IDD)
The IDD in Annex B defines the "payload" information for the interface. That is the data which is required for processing a mailpiece e.g.
Figure 1 - Interface environment of an Enrichment Device
As shown on Figure 1, there are many interfaces from an Enrichment Device to the rest of the system. This document is only concerned with the Mailpiece Processing part of the complete Standard Interface.
The mailpiece processing is concerned with the passing of a mailpiece to an Enrichment Device for processing.

  • Technical specification
    213 pages
    English language
    sale 10% off
    e-Library read for
    1 day