1. ESPO Reporting formalities and trade facilitation
Rotterdam, March 23, 2017

2. ESPO and the Reporting Formalities
Re. PROTECT’s meeting in Bremen; June 28, 2016;
Update on the eManifest project and EMSW project;
ESPO’s involvement in eManifest and EMSW projects
Update on the RFD refit;

3. Re. PROTECT’s meeting in Bremen; June 28, 2016 (1)
ESPO’s road map for trade facilitation
The system:
Electronic reporting should be facilitated through robust and resilient systems that ensure data is reliable (maximum use of source data).
ESPO believes that a network of interconnected reporting systems sharing the same functional specifications would be the best solution at European level.

4. Re. PROTECT’s meeting in Bremen; June 28, 2016 (2)
ESPO’s road map for trade facilitation
2. The data/formalities:
Ships calling EU ports report in each port the same data in the dame format, and only when justified by local requirements, additional data
ESPO calls the Commission to set up an industry expert working group (replacing the eMS working group), to contribute achieving the above exercises.

5. Re. PROTECT’s meeting in Bremen; June 28, 2016 (3)
DG MOVE
DG TAXUD
EMSA
‘Leading’
‘Supporting’
‘The contractor’
Blue Belt
CGM
NSW prototype
eManifest
EMSW
Input (expertise) required from MS and industry !!

6. eManifest project – issue 1: Definitions
DG MOVE and DG TAXUD agreed to launch with the assistance of EMSA a pilot project demonstrating how the full eManifest, including different cargo notifications1 that could be used for maritime and/or customs purposes, can be reported together with the other reporting information by electronic means in a harmonised manner via a European Maritime Single Window prototype (EMSW). The Maritime Single Window (MSW) prototype developed by EMSA will be enhanced and used for the purpose of testing the eManifest.
Note:
After discussions, this eManifest is further considered to be an assembly of notifications once these are all made. Before they are all there, there probably would not be something that can be called ‘a single, coherent eManifest’ but only notifications that are its building blocks.
(Ref: eManifest Business Rules draft consolidated version ver. 2)
1 DG MOVE considers the DPG notification as a ‘cargo notification’.

7. eManifest project – issue 2: Reporting DPG
ESPO pointed out that usually the DPG details are not provided by the cargo agents. EMSA said that if the DPG information will be separated from the cargo description, it will create two channels of submission and the principle of reporting only once will not be applied. ESPO was of the opinion that the reporting once principle remains because the DPG details are reported only to the authority for the vessel clearance. In addition, ESPO said that the DPG notification is not used as a cargo formality but it is sent to the port authorities only once. The combination of the DPG and cargo information will complicate the notification. ESPO was in favour of separating the DPG from the cargo description in order to avoid additional burdens in the process.
…… DG MOVE concluded that the default option will be that DPG data is treated distinctly from cargo data. The possibility of re-using some of the cargo data when reporting DPG will be assessed.
(Ref: Minutes eManifest meeting )

8. eManifest project – issue 3: Reporting ATA
ESPO inquired whether differences in the customs and maritime definitions of the term ETA (Estimated Time of Arrival) have been taken into account for the formulation of data mapping. EMSA said that the same elements apply to ETA for both customs and maritime formalities, adding that DG TAXUD experts were consulted on this matter. According to EPSO, the issue of definition should be resolved before proceeding with the amendments for Phase 2. EMSA clarified that the definition of the term ETA (date of arrival of the transport mean at the port of call) is attributed to both customs and maritime, and the same wording is used in the UCC.
IPCSA mentioned that the ETA definition was derived from the FAL Form 2 and other FAL forms. IPCSA informed that the IMO electronic FAL Compendium is currently under revision, and the WCO project team members dedicated to this task have presented a different understanding of the ETA definition. IPCSA stressed the importance of clarifying this definition in the data mapping. EMSA replied that the definition used for the data mapping is the same as that defined in the maritime National Single Window (NSW) guidelines for the implementation of Directive 2010/65/EU. In the meantime, if the IMO will propose a clearer definition, it will be taken into consideration.
(Ref: Minutes eManifest meeting )

9. eManifest project – issue 4: Data model (1)
WCO assisted EMSA in the development of WCO data model compliant messages for the EMSW prototype.
UN/CEFACT pointed out that UNECE and UN/CEFACT have their own data model which represents an overall modelling of trade, regulatory and transport data. The WCO has a different data model based on different modelling techniques and structures. There are hardly any messages commonly used by the transport industry. For this reason, more time has to be invested in analyzing the data mapping, the business processes and the relationship between the two models.
DG TAXUD gave a presentation on the work accomplished in establishing the European Customs Data Model (EU CDM) and the progress made so far with the message structures prepared by EMSA.
UN/CEFACT presented the schema on the international trade Single Window (SW), which illustrates the Business to Business (B2B) trade environment and the government side of the SW. UN/CEFACT stressed that the focus should be on the data harmonization behind the SW by involving both sides. Further, UN/CEFACT noted that it is working together with the UNECE and the WCO to ensure the mapping between the core component library, which covers the B2B trade environment and a considerable part of the government side, as well as the data harmonization.
IPCSA expressed concern that the simplification of procedures is becoming complicated due to various data models (ISO 28005, WCO DM, core component library and EU CDM) used for different purposes.
A few fragments of ongoing discussions dd Oct. 2016

10. eManifest project – issue 4: Data model (2)
EMSA gave a presentation on the state of play on the MIG implementation in the EMSW prototype. Such MIG is derived from the WCO Data Model and includes XML and EDIFACT messages. Once the MIG is approved, the corresponding system interfaces will be implemented in the EMSW Prototype (in addition to the existing system interface which is derived from the ISO standards in XML).
IPCSA pointed out that all members of the UN/CEFACT Transport and Logistics Domain are volunteers dedicated to maintaining and further developing existing UN/CEFACT standards of relevance to the transport industry.
IPCSA mentioned that EMSA hired an expert to work on the mapping of EDIFACT messages for the WCO data model (GOVCBR message) and inquired whether this could also be done in the current context in order to complete the work on the mapping with the UN/CEFACT EDIFACT messages (e.g. CUSCAR, CUSREP, IFTDGN, BERMAN) within the timescale of the eManifest.
EMSA replied that WCO has a mechanism that enables organisations to hire an expert.
IPCSA advised that considering the substantial work needed and considering that the IMO FAL Compendium would be revised, it was of the opinion that producing the mapping with UN/CEFACT messages was premature.
A few fragments of ongoing discussions dd Febr. 2017

11. EMSW project EMSW PCS Customs Health Other Web Country A Country B NSW
Country C
Country B
Country A
PCS
Customs
Health
Other
Web
EMSW project
Ref. EMSW vision paper; DG MOVE Oct. 2016

12. EMSW vision paper from the Commission
DG MOVE stated that the sketch presented is not ideal, since it confronts operators with systems that are differentiated between MSs; it might also be illegal, whenever differences persist within any MS.
Still, the benefits, according to DG MOVE:
Less expensive alternative to providing harmonized reporting in ports that still have limited electronic capability;
The EMSW would be easier to maintain;
For the ship operators there would be a reduction in administrative costs;
Further simplification can be achieved if the same information can be re-used for different calls;
Data accuracy and consistency is improved;
Where national or local systems are already in place, parallel availability of the EMSW would ensure compliance with the RFD;
Even for a perfectly functioning nationally harmonized system, the EMSW would provide valuable redundancy;
Furthermore, NSWs, and to certain extend PCS, would benefit from commonly developed specifications;
The EMSW would automatically fulfil the information exchange requirements.

13. EMSW project – test results so far
The EMSW is based op the NSW prototype from EMSA;
EMSW has to facilitate the exchange of the eManifest (as an assembly of notifications);
So far, test results show:

14. EMSW project – next steps
Data mapping and messages.
SW Group to consider changes to Data Mapping Report (Oct. 2017)
Spreadsheet.
Harmonised spreadsheet files would represent significant improvement for ship masters and data providers;
Different contents. Therefore not possible to agree in the short term on a harmonised template for all MS;
Industry’s input needed.
Peer reviews
Best practices and recommendations >> EMSW
SSN central databases
Central Hazmat database
Central Ship database
To be used in NSW’s and EMSW

15. ESPO’s ROAD MAP FOR MARITIME TRADE FACILITATION
ESPO’s involvement
eManifest project and EMSW project (restructuring the HLSG SSN and eMS expert group)
HLSG for Governance of the Digital Maritime System and Service's
subgroup eManifest
subgroup EMSW
ESPO’s ROAD MAP FOR MARITIME TRADE FACILITATION

16. RFD refit - update
Peer reviews
Online survey (RF and VTMIS Directives)
eManifest- and EMSW projects (in parallel)
“The eManifest initiative and the interlinked EMSW project are not substitutes for a legislative process nor can these have mandatory effects…..
Nevertheless, the results of these projects would help to determine if there is scope to continue to work on the implementation of the eManifest and the EMSW also through legislative changes. The results would be considered in the evaluation of the RFD as a possible solution for further simplification and harmonization of reporting formalities” (Ref. EMSW vision paper; DG MOVE Oct. 2016).

17. State of play on the implementation of the RFD
“The requirement to set up a single window for reporting formalities entered into force on 1 June, 2015.
After a few months of adjustment, MSs report that National Single Windows (NSWs) are up and running, although many indicate that certain formalities or functionalities still need to be added to their systems.
Feedback from industry suggests that the situation is still very patchy, with many ports, formalities and/or functionalities not yet covered or lacking harmonization.
There are some indications that the new reporting processes introduced in some MSs are actually more burdensome than those before. This raises doubts on the claim that the RFD is correctly applied in many MSs.”
Ref. EMSW vision paper; DG MOVE Oct. 2016

18. Limits of the RFD in its present formulation
“Harmonization is only imposed at national level: real facilitation would require EU harmonization;
The list of the EU legal acts or formalities currently included is not comprehensive: an eManifest for cargo reporting and custom formalities is needed.
Clearance functions are not included: “active” Single Window functionalities should be a added;
‘Reporting only once’ is not achieved: data, including ENS data, should be re-used for subsequent port calls in different MSs;
Nationally required data (‘Part C’ in the RFD) is excessive, non-harmonised and can be left outside of the single window: a standardized maximum data set should be introduced;
The present RFD does not include delegated powers for the adoption of binding technical specifications;
An appropriate governance method to ensure technical maintenance and update of reporting requirements in line with changes in legislation is not in place.”
Ref. EMSW vision paper; DG MOVE Oct. 2016

19. Results from the Dutch Peer review
Perceptions about reporting formalities and trade facilitation differ:
EMSA and COM use the EU Directives as their reference;
The Dutch port sector use national/regional legislation and daily practice as their reference.
EMSA and COM expected MS to implement the RFD on national level.
The Dutch ports have arranged their reporting formalities on regional level.
EMSA and COM see a large potential for re-use of data (reported once) between the relevant authorities.
The Dutch ports see only ship’s arrival and departure times as the potential for re-use between these authorities.
EMSA and COM present SafeSeaNet as a system for re-use of data between the relevant authorities and between EU ports, facilitating the ‘reporting once principle’.
The Dutch ports do not consider SafeSeaNet as a system for re-using data between ports.

20. On line survey (RF and VTMIS Directives)
See separate document:
PWC enquete on the refit of the RF- and VTMIS Directives