Itinerary_1

This should become the summary page of the itinerary.

Name of Itinerary: Description for the icon for the itinerary: ?

Description of the itinerary in one §:

Throughout a cross-border trade transaction [HvM1] various documents and forms are filled out, submitted, exchanged and delivered between the various parties intervening in the process. The document and data requirements can in fact be more complex [GNS2] than the regularity environment and cause delays and costs for traders and the public bodies. Document requirements are a major concern for traders and governments [GNS3]. Every document and form entails multiple formalities to be undertaken. The efforts involved in completing, presenting and processing documents and data require time and are costs factor for both trading community and the public agencies processing the document. In order to reduce the complexity of document requirements, efforts should aim at simplifying the requirements and the processing and aligning and harmonizing the documents and data.

Summary and link of each of the pages that are part of the itinerary:

Below is the text from the itinerary document on the dropbox.


 * 1) Document data requirementss seems to grow (in numbers and in data included), particularly in the recent past - why? new regulations, supply chain security measures, administrations tends to demand more and more information. Also documents are changing from paper to electronic and are no longer bound by the paper limitations of manually filling in and the amount of text that can be captured.There is also a trend in electronic communication to send smaller sets of information until the full information set is exchanged rather than fully completed documents, in transport for example sending initially information that 3 containers will be shipped followed by detailed information about the cargo once available.
 * 2) Fundamental: every document item (information, data, numbers on the trade documents) is a characteristic based on a requirement (see above, i.e. security measure) from one or more stakeholders. Often the stakeholder requirements are conflicting and so a compromise will often take place. Stakeholder requirements may also differ in detail, for example the customs declaration could in principle also be used for agricultural validation, were it not that the codification of the agricultural produce is to be more detailed for the phytosanitary permit than is required for customs purposes
 * 3) To reduce the complexity of used trade documents, start with (1) analysis of the underlying requirements. (2) analyze how this requirements is fulfilled (information flow) (3) eliminate redundancy and bottlenecks (timing aspect) in the information flow. Development of an to-be-model, derive data requirements (data model) for each document from to-be-model. [too much ?] add sth regarding comment#2 here.
 * 4) Redundancies and bottlenecks will be removed by lean documents. Do not start from scratch, use best practice models/examples.
 * 5) Compatibility between paper and e-doc
 * 6) Doc often contain more info than needed to satisfy the original process because there are requirements from other related processes as well …
 * 7) Ultimately the Data Model should be presented to be harmonized into existing or new standards. This helps to ensure a wider use of the models, review by peers and other stakeholders in the area and validation by going through an audit process. This process should ultimately provide longevity for the documents involved and help all stakeholders form consensus on the solution.

First page: Documentation

[HvM1] Certain users of the TFIG may need explanation to understand what this is [GNS2] Requirements are not complex, they may be not appropriate (anymore) … became obsolete …because of changes in process/procedure requirement , b [GNS3] ecause …? See page 2.