35.240.69 - IT applications in postal services
ICS 35.240.69 Details
IT applications in postal services
Uporabniške rešitve IT pri poštnih storitvah
General Information
e-Library Subscription
Create subscription and get permanent access to documents within 35.240.69 - IT applications in postal services
Currently subscription includes documents marked with .We are working on making all documents available within the subscription.
ISO 19160-4:2017 defines key terms for postal addressing, postal address components and constraints on their use.
Specifically, ISO 19160-4:2017 defines postal address components organized into three hierarchical levels:
- elements, such as organization name or postcode, which have well-defined conceptual meaning and are not themselves made up of subordinate components, though they may be sub-divided for technical purposes;
- constructs, such as organization identification, which group elements into units form a logical portion of a postal address;
- segments, such as addressee specification, which group-related postal address constructs and/or postal address elements into units with a specific defined function.
ISO 19160-4:2017 also specifies a mechanism for creation of sub-elements, which correspond to either sub-divisions of element content, such as door type or door indicator or to multiple occurrences and locations of elements in an address, such as levels of administrative regions.
ISO 19160-4:2017 does not specify the length of any component nor the value range of any component.
Moreover, ISO 19160-4:2017 defines the codes to identify elements and sub-elements.
Further, ISO 19160-4:2017 specifies postal address rendering rules. This includes identification and ordering of output lines in a rendered address, conditions for selection of candidate lines, the order and concatenation of postal address components, required and optional components, parameters to contextualize address for rendering and the formatting of the components, subject to constraints on the space available for that task. Postal address rendering rules are represented in ISO 19160-4:2017 as a postal address template.
Finally, ISO 19160-4:2017 specifies language suitable for computer processing to formally express postal address templates.
- Standard74 pagesEnglish languagesale 10% offe-Library read for1 day
- Draft70 pagesEnglish languagesale 10% offe-Library read for1 day
This document defines key terms for postal addressing, postal address components and constraints on their use.
Specifically, this document specifies postal address components organized into three hierarchical levels:
— elements, such as organization name or postcode, which have well-defined conceptual meaning and are not themselves made up of subordinate components, though they can be sub-divided for technical purposes;
— constructs, such as organization identification, which group elements into units form a logical portion of a postal address;
— segments, such as addressee specification, which group related postal address constructs and/or postal address elements into units with a specific defined function.
This document also specifies a mechanism for the creation of sub-elements, which correspond to either sub-divisions of element content, such as door type or door indicator or to multiple occurrences and locations of elements in an address, such as levels of administrative regions.
This document does not specify the length of any component nor the value range of any component.
Moreover, this document specifies the codes to identify elements and sub-elements.
Further, this document specifies postal address rendering rules. This includes:
— identification and ordering of output lines in a rendered address;
— conditions for the selection of candidate lines;
— the order and concatenation of postal address components;
— required and optional components;
— parameters to contextualize an address for rendering;
— the formatting of the components, subject to constraints on the space available for that task.
Postal address rendering rules are represented in this document as a postal address template.
Finally, this document specifies language suitable for computer processing to formally express postal address templates.
This document does not cover the topic of data protection. Users of the document are nevertheless reminded that the storage and exchange of personal data are subject to legislation in many countries.
- Standard74 pagesEnglish languagesale 10% offe-Library read for1 day
- Draft70 pagesEnglish languagesale 10% offe-Library read for1 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 specification30 pagesEnglish languagesale 10% offe-Library read for1 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.
Although this document is not intended for barcodes (other than Digital Postal Marks) which can be printed on mail pieces for item identification or additional services, a similar methodology can be applied.
- Technical specification30 pagesEnglish languagesale 10% offe-Library read for1 day
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 report53 pagesEnglish languagesale 10% offe-Library read for1 day
- Draft52 pagesEnglish languagesale 10% offe-Library read for1 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 report93 pagesEnglish languagesale 10% offe-Library read for1 day
- Draft98 pagesEnglish languagesale 10% offe-Library read for1 day
The scope will be defined during the preliminary stage.
- Technical report93 pagesEnglish languagesale 10% offe-Library read for1 day
- Draft98 pagesEnglish languagesale 10% offe-Library read for1 day
The scope will be defined during the preliminary stage.
- Technical report53 pagesEnglish languagesale 10% offe-Library read for1 day
- Draft52 pagesEnglish languagesale 10% offe-Library read for1 day
2020-07-08 - TC - Correction of two formats in rows "Item identifier" and "Additional barcode" in Table 1
- Corrigendum3 pagesEnglish languagesale 10% offe-Library read for1 day
2020-07-08 - TC - Correction of two formats in rows "Item identifier" and "Additional barcode" in Table 1
- Corrigendum3 pagesEnglish languagesale 10% offe-Library read for1 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 specification22 pagesEnglish languagesale 10% offe-Library read for1 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 specification22 pagesEnglish languagesale 10% offe-Library read for1 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 specification44 pagesEnglish languagesale 10% offe-Library read for1 day
- Draft43 pagesEnglish languagesale 10% offe-Library read for1 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 specification32 pagesEnglish languagesale 10% offe-Library read for1 day
- Draft33 pagesEnglish languagesale 10% offe-Library read for1 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 specification32 pagesEnglish languagesale 10% offe-Library read for1 day
- Draft33 pagesEnglish languagesale 10% offe-Library read for1 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 specification84 pagesEnglish languagesale 10% offe-Library read for1 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 specification84 pagesEnglish languagesale 10% offe-Library read for1 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 specification58 pagesEnglish languagesale 10% offe-Library read for1 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 specification58 pagesEnglish languagesale 10% offe-Library read for1 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 specification237 pagesEnglish languagesale 10% offe-Library read for1 day
- Draft246 pagesEnglish languagesale 10% offe-Library read for1 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 specification237 pagesEnglish languagesale 10% offe-Library read for1 day
- Draft246 pagesEnglish languagesale 10% offe-Library read for1 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 specification55 pagesEnglish languagesale 10% offe-Library read for1 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 specification30 pagesEnglish languagesale 10% offe-Library read for1 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 specification135 pagesEnglish languagesale 10% offe-Library read for1 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 specification27 pagesEnglish languagesale 10% offe-Library read for1 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 specification27 pagesEnglish languagesale 10% offe-Library read for1 day
Scope of the proposed deliverable
This document focuses on assigning and maintaining addresses that allow the unambiguous determination of an object in the physical world for purposes of identification and location in the context of public administration and public service delivery. During assignment an address is first associated with a particular object in the physical world. During maintenance the address changes, e.g., it is re-assigned to a different object, one or more of the address components are modified (e.g. a street name change), or the address is retired when it is no longer used. This document
— establishes an overall set of objectives for assigning and maintaining addresses;
— specifies the principles for assigning and maintaining addresses;
— specifies a good practice for assigning and maintaining addresses; and
— specifies a governance framework for assigning and maintaining addresses;
Very often local governments (e.g. municipalities) are assigned the mandate for the planning, implementation, evaluation, and ongoing maintenance of addresses, and they are often supported by other organizations, such as national government, private sector companies and national or regional organizations. This document is of relevance and applicable to all these organizations who have an interest, role or responsibility in address assignment and maintenance, such as
— developing legislation, policies or regulations for addressing;
— facilitating and coordinating the naming of address components (the constituent parts of an address) and announcing and communicating these names;
— installing address component signs in the physical world;
— designing and implementing business processes related to address assignment and maintenance;
— designing, implementing and maintaining access to address data;
— developing software to facilitate the above; and
— using addresses.
- Draft134 pagesEnglish languagesale 10% offe-Library read for1 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
- Standard71 pagesEnglish languagesale 10% offe-Library read for1 day
- Draft76 pagesEnglish languagesale 10% offe-Library read for1 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 specification56 pagesEnglish languagesale 10% offe-Library read for1 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 specification56 pagesEnglish languagesale 10% offe-Library read for1 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 specification49 pagesEnglish languagesale 10% offe-Library read for1 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 specification49 pagesEnglish languagesale 10% offe-Library read for1 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 specification213 pagesEnglish languagesale 10% offe-Library read for1 day
TC - B.6.3.4.3.5, 2nd paragraph - Correction of reference
- Corrigendum2 pagesEnglish languagesale 10% offe-Library read for1 day
TC - B.6.3.4.3.5, 2nd paragraph - Correction of reference
- Corrigendum2 pagesEnglish languagesale 10% offe-Library read for1 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 specification213 pagesEnglish languagesale 10% offe-Library read for1 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 specification31 pagesEnglish languagesale 10% offe-Library read for1 day