|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|
|||
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|
|||
Version 1.0.0 – 30/09/2024
The European Maritime Single Window environment (EMSWe) Regulation (EU) 2019/1239 (R01), building on the existing Maritime National Single Windows (MNSWs), establishes a common, interoperable environment for the reporting of information from ships to shore during a port call. In particular, it empowers the European Commission to define a harmonised data set covering all reporting obligations and to develop and maintain common interfaces and services for the MNSWs.
The EMSWe Regulation requires the Commission, in close cooperation with the Member States, to develop a harmonised Reporting Interface Module (RIM), which is a middleware component of the MNSWs through which information can be exchanged between the information system used by the declarants or data service providers and the relevant MNSW.
According to the Implementing Regulation (EU) 2023/2790 (R06) laying down functional and technical specifications for the RIM, the Commission shall define and maintain a Message Implementation Guide in close collaboration with the national coordinators for the EMSWe and with the assistance of the European Maritime Safety Agency (EMSA).
The Message Implementation Guide (MIG) of the EMSWe aims at providing a functional specification of messages exchanged between declarants or data service providers and MNSWs through the RIM.
Messages described in this MIG relate to the communication by declarants and data service providers of information necessary for the fulfilment of the reporting obligations defined in the Annex of the EMSWe Regulation and to the communication of responses from the MNSWs and authorities.
Note: For any inquiries regarding the application of the MIG or interfacing with Maritime National Single Windows, please reach out to the respective EMSWe national coordinators.
The following principles are leading for the design of the information exchange by messages between declarants or data service providers and MNSWs:
MIG-P1 – The concept of formality is applied for information exchange between declarants and authorities
The information exchange between declarants and authorities uses the concept of formality, identified by a type of formality (e.g. notice of pre-arrival), to support the reporting obligations. The term "formality" is used as general term for declarations as well as for notifications. A formality consists of a coherent set of data elements related to reporting obligations. Each formality may address one or more reporting obligations. In line with the "reporting once-only" principle, the overlap of data elements in distinct formalities is minimised. Each formality must be provided with a header part MAI (i.e. Main), which contains information applicable to all formalities (e.g. identification of the declarant, identification of formality type, metadata).
The following formalities are handled in the MNSW (the table indicates the corresponding reporting obligations, as identified in the annex of the EMSWe Regulation (R01), that can be fulfilled using each formality):
| Type of formality | Description | Corresponding reporting obligation |
| ABS | Absentee declaration | C |
| ACT | Expected activities notification | C |
| ATA | Notification of actual arrival | C |
| ATD | Notification of actual departure | C |
| BKA | Bunkers at arrival | C |
| BKD | Bunkers at departure | C |
| BLU | Safe loading and unloading of bulk carriers | A8 |
| BWA | Ballast water | C |
| CAR | CGM amendment request | A7.4 |
| CGA | Cargo declaration at arrival | A10 B2 |
| CGD | Cargo declaration at departure | A10 B2 |
| CGM | Customs goods manifest | A7.4 |
| COA | Cancellation of port call | n/a |
| CRT | Ship certificates | C |
| CWA | Crew list at arrival | A2 A6.2 B5 |
| CWD | Crew list at departure | A2 A6.2 B5 |
| DUE | Fairway and port dues declaration | C |
| EFF | Crew's effects declaration | B4 |
| EXP | Notification of expanded inspection | A9 |
| EXS | Exit summary declaration | A7.7 |
| EXT | Exit notification | A7.6 |
| HOS | Hospitalised crew member declaration | C |
| HZA | Notification of hazardous materials (dangerous and polluting goods) on board at arrival | A3 B7 |
| HZD | Notification of hazardous materials (dangerous and polluting goods) on board at departure | A3 B7 |
| HZS | Notification of hazardous materials (dangerous and polluting goods) on board during a shift | C |
| MDD | Maritime declaration of health details | B8 |
| MDH | Maritime declaration of health | B8 |
| MTS | Maritime transport statistics | A10 |
| NAC | Notification of arrival to the customs office of first entry | A7.1 |
| NAV | Navigation report | C |
| NOA | Notice of pre-arrival | A1 A6.1 B1 |
| NOD | Notice of pre departure | A6.1 B1 |
| NOS | Notification of shift in port | C |
| PBK | Passenger booking | C |
| PNO | Presentation notification | A7.2 |
| POA | Notification of pontoon arrival | C |
| POD | Notification of pontoon departure | C |
| PPA | Presentation of the proof (at arrival) | A7.4 |
| PXA | Passenger list at arrival | A2 A6.2 A10 B6 |
| PXD | Passenger list at departure | A2 A6.2 A10 B6 |
| REN | Re-export notification | A7.8 |
| SDA | Supplementary documents at arrival | A7.4 |
| SDD | Supplementary documents at departure | A7.4 |
| SEC | Notification of security information | A5 |
| SHP | Ship information | C |
| SID | Ship identifiers notification | n/a |
| SRV | Request for service | C |
| SSA | Ship to ship activity declaration | C |
| STA | Declaration of stores on board at arrival | B3 |
| STD | Declaration of stores on board at departure | B3 |
| STW | Stowaways notification | C |
| TRA | Electronic transport documents used for transit at arrival | A7.5 |
| TRD | Electronic transport documents used for transit at departure | A7.5 |
| TSD | Temporary storage declaration | A7.3 |
| VID | Request for Visit ID | n/a |
| VIS | Ship visitors declaration | C |
| WAR | Waste delivery receipt | A4.2 |
| WAS | Advance notification for waste delivery to port reception facilities | A4.1 |
MIG-P2 – The concept of responses is applied for information exchange between authorities and declarants
The information exchange between authorities and declarants uses the concept of responses, identified by a type of response, to report decisions and process results of relevant authorities. A response consists of a coherent set of data elements, which is returned by the MNSW on behalf of one or more relevant authorities. Each response must be provided with a header part RES (i.e. Response) which contains information applicable to all responses (e.g. identification of authorities, identification of referenced formality, metadata).
MIG-P3 – Single reporting, multiple use of formalities
Formalities for (multiple) authorities can be reported on a single basis to the MNSW. The MNSW will communicate the formality to one or more relevant authorities. The principle of single reporting is applied:
MIG-P4 – There is a single declarant per formality
A formality is always reported by one and only one declarant.
MIG-P5 – Authorities are responsible for supervision and enforcement
Competent authorities in respect of the underlying reporting obligations remain responsible for supervision and enforcement. The MNSW will not change existing legal responsibilities and competences.
MIG-P6 – One message for all types of formalities with one formality per message
All formalities can be reported by one single type of message. This message is called a formality message. Each formality message contains exactly one formality. The message contains a header part MAI and the formality content corresponding to the formality type (e.g. NOA).
Note: An exception to the above is the case of a withdrawal (refer to principle MIG-P29) where the message contains the header part MAI only.
MIG-P7 – Use of unique identifications for port calls in formalities and responses
Formalities and responses need to have a unique identification for a ship port call: the Visit ID. The Visit ID is unique at the Member State level. It is issued by the MNSW or by an authority (e.g. port authority, single window authority) through the MNSW.
The Visit ID is communicated in the formality response message (response type FRM) sent as response to a request for Visit ID (formality type VID). Member States may allow declarants to request the Visit ID through other channels (e.g. through Port Community Systems) provided that those channels are voluntary for the declarants.
Each Visit ID is related to one ship and one port of call. It is not allowed to change the ship or the port associated to a certain Visit ID.
MIG-P8 – Use of identification for ship in formalities and responses
The identification of the ship consists of the identification type and the identification number. Declarants need to use the types of identification in the following sequence of priority:
If a vessel has multiple types of identification, the type with the highest priority must be used (as listed above).
Ship identifiers are initially reported through the formality type VID. If the ship's identifiers change (e.g. change of MMSI following change of Flag), then a formality of type SID must be sent. Once an IMO number or ENI number has been specified, it cannot be changed for the same port call.
MIG-P9 – Use of unique identification of declarants and authorities in formalities and responses
Two types of identifications are used for involved parties:
MIG-P10 – Use of unique location code for port of call
Each Visit ID is related to exactly one location code to identify the port of call for that particular port call. All location codes are registered in the EMSWe common location database (refer to R03).
MIG-P11 – Formalities can be reported by electronic messages through the RIM or through the MNSW GUI
Declarants may report formalities by sending electronic formality messages to the RIM's system-to-system interface or by entering or uploading the data in the MNSW's Graphical User Interface (GUI). The same principles and rules for processing the formality are applied in both the RIM and the GUI. Formalities related to the same Visit ID may be submitted either through the RIM or through the GUI.
If a formality is reported by a declarant using the RIM's system-to-system interface, the same declarant may view or update that formality in the MNSW's GUI.
Note: Not all MNSWs may allow the fulfilment of all formalities via the GUI. This depends on national requirements.
MIG-P12 – Formalities can be reported by different declarants
Different declarants (with different EORI numbers) may report formalities for the same port call (same Visit ID).
MIG-P13 – Number of possible formalities of the same type per port call
There can be only one formality per port call (i.e. per Visit ID) for the following formality types: ATA, ATD, BKA, BKD, BWA, COA, CWA, CWD, EFF, EXP, HZA, HZD, MDD, MDH, MTS, NAC, NAV, NOA, NOD, PBK, POA, POD, PXA, PXD, SEC, SHP, SID, SSA, STA, STD, VID, WAS.
The following formality types can be reported in several formalities per port call (i.e. per Visit ID) and by different declarants: ACT, ABS, BLU, CAR, CGA, CGD, CGM, CRT, DUE, EXT, EXS, HOS, HZS, NOS, PPA, PNO, REN, SDA, SDD, STW, SRV, TRA, TRD, TSD, VIS, WAR.
MIG-P14 – Use of formality reference numbers – LRN
The formality messages for formality types ACT, ABS, BLU, CAR, CGA, CGD, CGM, CRT, DUE, EXT, EXS, HOS, HZS, NAC, NOS, PPA, PNO, REN, SDA, SDD, STW, SRV, TRA, TRD, TSD, VIS and WAR must include a formality reference number. This mandatory reference number is a unique LRN which is issued by the sender of the formality message.
The LRN is used by the MNSW to track updates of the same formality for cases of formalities that can be reported more than once per port call (see principle MIG-P13) and is used by the customs authorities according to the Union Customs Code[1].
MIG-P15 – Use of response message for formality responses and process responses
The MNSW uses the response message for communicating authorities' responses to the declarants. There are two categories of responses:
If the formality does not pass the semantics checks, it will not cause any further processing by the authorities. The formality response will indicate the reasons for the rejection in form of a list of errors. Each formality which is rejected due to semantic checks will need to be corrected and resent (with a distinct Message Identifier).
The formality response must include the message status (accepted, rejected), the Visit ID, the type of formality, the formality reference number (when relevant, see MIG-P14), the reference number of the formality message (message identifier) and possibly a process reference number issued by an authority (e.g. MRN – Master Reference Number as defined in R04).
In the case of a rejection, the formality response includes a list of errors identified by a code and with an optional textual description. The formality response may as well include a list of warnings identified by a code with an optional textual description. Warnings do not imply a rejection of the formality and may be provided in both cases where the formality passes the semantics checks or is rejected. Along an error or a warning, the reference to one or several classes or attributes in the formality may be provided. The attribute or class reference takes the form of a position in the formality message in xpath format, and eventually of an item number if the position corresponds to an attribute in a list (if the list contains a "sequence number" attribute, the value of the sequence number of the received occurrence is used. If there is no attribute "Sequence number" in the list, the position of the occurrence in the list is used).
Such responses must include the Visit ID, the type of formality and the formality reference number (when relevant, see MIG-P14). In some case the response of the authority might include the assignment of a process reference number (e.g. MRN).
Both the formality responses and process responses are communicated by the MNSW-Core to the RIM which relays them to the declarant.
Examples of transaction patterns are shown in Figure 1 and Figure 2 below.
Figure 1: Example transaction pattern of a formality message and
corresponding response messages
Figure 2: Example transaction pattern of a semantic check with rejection
MIG-P16 – Type of responses
Each response message contains exactly one response type in addition to the header part RES. The RES needs always to be sent in combination with any type of response. The following table provides the list of response types and the corresponding formalities.
| Type of response | Category of response | Description | Corresponding formality |
| FRM | Formality | Formality response | Any |
| CLR | Process | Ship clearance decision: decision from the relevant authority to authorise the ship to enter the port, shift within the port, or leave the port | NOA, NOS, NOD |
| BLR | Process | Response to a notification for safe loading and unloading of bulk carriers | BLU |
| SRR | Process | Response to a service request | SRV |
| CUS | Process | Response from customs authorities to a customs formality | NAC, PNO, TSD, CGM, PPA, SDA, SDD, CAR, TRD, TRA, EXT, EXS, REN |
MIG-P17 – Clearance model
Three clearance models may be applied by the MNSWs:
The clearance model applied in the port is communicated in the formality response FRM sent in response to a NOA, NOS or NOD formality depending on the context (arrival, shift, departure).
Examples of transaction patterns in the case of silent clearance are shown in Figure 3 and Figure 4 below.
Figure 3: Example transaction pattern in the case of silent clearance and where the ship is authorised to enter the port
Figure 4: Example transaction pattern in the case of silent clearance and where the ship is not authorised to enter the port
MIG-P18 – Communication of responses to declarants
Formality and process responses are communicated by the MNSW to the declarant who submitted the corresponding formality.
MIG-P19 – Channel for communicating responses to declarants
If a formality is submitted through the RIM, the corresponding formality response is communicated back through the RIM.
If a formality is submitted through the MNSW GUI, the corresponding formality response can be consulted by the declarant in the MNSW GUI.
Process responses can be consulted by the declarant in the GUI and are communicated through the RIM if the corresponding formality was submitted through the RIM.
MIG-P20 – Information submitted is checked against EMSWe databases
The MNSW checks the content of received formality messages against the EMSWe databases (refer to R03):
In case where one or more warnings are generated by the checks above, the MNSW returns a formality response to the declarant with the warnings.
MIG-P21 – Use of control messages for returning results of syntax, rule and conditions checks
The RIM will return a control message in situations where a received message does not meet the common agreed syntax, rules and conditions (as defined in the MIG).
In case a formality message does not meet the syntax, rules or conditions, it will be rejected, will not be forwarded to the MNSW-Core and will not cause any further processing.
In case a response message does not meet the syntax, rules or conditions, it will be rejected, will not be forwarded to the declarant, and will not cause any further processing.
The control message will indicate which parts of the message caused the rejection. Each message which is rejected due to syntax, rules or conditions checks will need to be corrected and resent (with a distinct message identifier).
The transaction patterns for the cases of syntax, rules and conditions checks are provided in Figure 5 and Figure 6 below.
Figure 5: transaction pattern of a syntax, rules and conditions check of a formality with rejection
Figure 6: transaction pattern of a syntax, rules and conditions check of a response with rejection
MIG-P22 – Either a control message or a formality response is sent by the MNSW
On each formality either one control message (in case of syntax, rules or conditions errors) or one formality response (with an acceptance or rejection based on semantic checks) follows.
MIG-P23 – Each formality message must contain sequence information
Updating or withdrawing [2] a formality is done by sending a formality message. Updates and withdrawals are therefore done per individual formality. For an update or withdrawal, the formality message must contain the Visit ID, the type of formality, and when necessary, the formality reference number (i.e. LRN), as in the initial message. For customs formalities, the MRN assigned to the initial formality must be reported.
To control the sequence of formality messages per message chain, each message needs to contain the following data elements:
When a formality message is received by the MNSW in the wrong sequence, i.e. the message's timestamp is earlier than the timestamp of the latest message already received and accepted by the MNSW for the same formality, then the message is rejected by the MNSW (formality response with message status "rejected").
When a formality message with function code "withdrawal" is received by the MNSW while no previous formality message for the same formality had been received by the MNSW, then the message is accepted by the MNSW and any formality message for that formality with an earlier timestamp than the accepted withdrawal message's timestamp will be rejected because out of sequence.
MIG-P24 – Allowed updates of formalities
Formalities of the following types can be updated[3]: ABS, ACT, ATA, ATD, BLU, BKA, BKD, BWA, CGA, CGD, CGM, CRT, CWA, CWD, DUE, EFF, EXP, EXS, HOS, HZA, HZD, HZS, MDD, MDH, MTS, NAV, NOA, NOD, NOS, PBK, POA, POD, PPA, PXA, PXD, REN, SEC, SID, SHP, SRV, SSA, STA, STD, STW, TRA, TRD, TSD, VIS, WAS, WAR.
Formalities of other types cannot be updated: CAR, COA, EXT, PNO, NAC, SDA, SDD, VID.
This rule will be controlled by the MNSW-Core in the semantic checks (refer to MIG-P15).
If formalities cannot be updated, then the update needs to be arranged through relevant procedures defined by the corresponding authority(ies) if needed and allowed.
MIG-P25 – Replace mechanism is applied for formalities updates
Each formality must start with one initial formality message followed by update formality messages in case updates are needed. For formalities updates, the "Replace" mechanism is applied. In the "Replace" mechanism all data of a formality is included in the update message regardless of whether the data is changed or not.
MIG-P26 – Updates and withdrawals of a formality must be from the same declarant as the initial formality
Updates and withdrawals of a reported formality must be from the same declarant as the declarant of the initial formality. In the case of formality types that can only be reported once per port call (see MIG-P13), this rule is applicable to the formalities with the same formality type and Visit ID. In the case of formality types that can be reported several times per port call (see MIG-P13), this rule is applicable to the formalities with the same formality type, Visit ID and LRN.
MIG-P27 – Updates and withdrawals of a formality must refer to the same ship and port
Updates and withdrawals of a reported formality must be related to the same port of call and the same ship as reported in the initial formality.
MIG-P28 – Cancellation mechanism
If a ship will not visit the port, all the related formalities can be cancelled by sending a formality of type COA. A COA formality means that the call of the ship in port is cancelled. A COA can only be reported by the declarant of the VID formality.
Cancellation requests need to be acknowledged by a formality response. After successful cancellation of a visit, no further formalities can be sent for the same Visit ID. Cancellations are final and cannot be withdrawn.
MIG-P29 – Withdrawing previously provided formalities
Formalities of the following types can be withdrawn: ABS, ACT, BLU, BKA, BKD, BWA, CGA, CGD, CRT, CWA, CWD, DUE, EFF, EXP, EXS, HOS, HZA, HZD, HZS, MDD, MDH, MTS, NAV, NOS, PBK, POA, POD, PNO, PXA, PXD, REN, SEC, SHP, SSA, STA, STD, STW, SRV, TRA, TRD, TSD, VIS, WAS, WAR.
Formalities of the following types cannot be withdrawn: ATA, ATD, CAR, CGM, COA, EXT, NAC, NOA, NOD, PPA, SDA, SDD, SID, VID.
Once a withdrawal request is received and accepted (by a formality response message), the corresponding formality is ignored by the authorities and will not generate any further processing. After a successful withdrawal, the same or a different declarant may submit a new formality of the same type.
If formalities cannot be withdrawn, then the withdrawal needs to be arranged through relevant procedures defined by the corresponding authority(ies) if needed and allowed.
MIG-P30 – Formalities can be updated or withdrawn by electronic messages through the RIM or through the MNSW GUI.
Declarants may update or withdraw formalities by sending electronic messages to the RIM's system-to-system interface or by entering or uploading the data in the MNSW's Graphical User Interface (GUI) regardless of whether the initial formality was reported through the RIM or the GUI. The same principles and rules for processing the formalities are applied in the MNSW when reported through the RIM or GUI.
MIG-P31 – Date-time information
The date-time format in all messages must be compliant with the format defined in the EMSWe dataset. All times must be reported either in UTC or with the indication of a time zone.
MIG-P32 – Unit information
There are multiple EMSWe data elements which represent measures (e.g. gross weight, draughts). These data elements must be reported along with the data element "Measurement unit, coded", which identifies the unit. A rule associated to the element indicates which unit(s) must be used.
For instance, data element "Cargo item net mass" must be reported along with the element "Measurement unit, coded" with value "KGM".
MIG-P33 – Unknown data
In case data value to be reported is unknown for an optional data element in a formality, the data element must not be included in the formality message. Therefore, the use of "" (empty text field), 0 or NULL to indicate that the data for a data element is unknown is not allowed.
MIG-P34 – Use of uppercase and lowercase
Codes of code lists are considered case sensitive. All data elements of type "Code" are therefore considered case sensitive.
All data elements of type "Identifier" are considered case insensitive; these references can be returned in responses and by considering these references case insensitive there is no chance of mismatches due to use of uppercase/lowercase by systems in the chain.
All other reported data is considered case sensitive.
MIG-P35 – Terms and definitions
For the purposes of this document, the following terms and definitions apply.
Formality: A formality consists of a coherent set of data elements which is reported by a declarant to authorities to fulfil reporting obligations. Refer to principle MIG-P1.
Response: A response consists of a coherent set of information, which is returned by a relevant authority to a declarant to report decisions and process results following the receipt of one or several formalities. Refer to principle MIG-P2.
Formality message: Message sent by a declarant through the RIM to a MNSW containing a formality. Refer to principle MIG-P6.
Response message: Message sent by a MNSW through the RIM to a declarant containing a response. Refer to principle MIG-P15.
Control message: Message sent by the RIM when a message is rejected following syntax, rules and conditions checks by the RIM. Refer to principle MIG-P21.
Port call: Port call means the arrival of a ship at, the stay of a ship in, and the departure of a ship from a maritime port in a Member State (refer to Article 2 of R01)
Visit ID: Unique identifier for the call of a ship in a port which is issued by a MNSW or by an authority. Refer to principle MIG-P7.
Rule: An instruction that specifies how an attribute or class must be filled in. It places a constraint on the content. It is always computable and can be tested.
Condition: An instruction that specifies whether an attribute or class is mandatory or optional or cannot be reported depending on other information within the same message. It places a constraint on when the data shall be reported, and not on its content. It is always computable and can be tested.
Guideline: An indication on how to fill in a class or attribute. It may relate to a check that will be performed by the MNSW or another system following the RIM checks. It may be computable and testable, but not necessarily.
The RIM performs the following functions:
Note. The following functions are not performed by the RIM:
The messages that the RIM receives and forwards have the same message content in terms of formalities/responses. The RIM does not touch upon the message content. It simply handles the transfer of the message.
The EMSWe MIG versioning policy applies the following semantic versioning rule:
EMSWe MIG Version <Major version number [n..2]>.<Medium version number [n..2]>.<Minor version number [n..2]>
Example: EMSWe MIG Version 3.11.1
Major versions refer to MIG releases that include major changes including but not limited to:
Major versions are not backward compatible with earlier versions.
Medium versions relate the general maintenance of the MIG and include:
Medium versions are backward compatible with versions from the same major version, e.g. version 3.3.0 is backward compatible with versions 3.2.0, 3.1.0 and 3.0.0.
Minor versions relate to changes that do not affect the substance of the medium and major version and will not lead to changes in messages. Minor versions will only clarify the meaning of previously unclear text but shall not impose new meaning, or broaden the meaning beyond the original intent of the MIG.
Such changes may include:
Major versions have a validity period from a begin date until an end date. The end date for the most recent major version is undetermined until the begin date of the next major version is known. At the begin date of a major version all MNSWs will support the new major version. The declarants / data service providers have time to migrate to the new major version during a transition period (period between the begin date of the new major version and the end date of the old/current major version, as depicted in the diagram below). The length of the transition period is determined per new major version and is indicated in the MIG.
Figure 7: Transition period between two major versions
The validity period for a medium version is the begin date of the medium version until the end date of the related major version. The validity periods of medium versions of a major version end all at the same time. At the begin date of a medium version all MNSWs will support the medium version. MNSWs implement the most recent medium versions per major version. Since medium versions are backwards compatible, the MNSWs implicitly support previous medium versions as well for the same major version. Declarants and data service providers can make use of 'older' medium versions as long as the use of an older medium version still satisfies the legal rules for reporting data for the corresponding reporting party(ies). If that is not the case, the declarant or data service provider needs to migrate to the new medium version. There is no transition period for new medium versions.
The different data elements that are part of the formalities are listed in R02. Every data element is identified by a unique identification number (with prefix 'DE') and is given a name, a textual description and a format, as defined in R02.
The descriptions of the data structure of each formality and of the header MAI are provided in page "Formalities". Each formality message must include the header MAI and the formality content (e.g. NOA, HZA). Messages may include as well one or several binary attachment files, if this is allowed by the MNSW for the specified formality. An exception is the case of withdrawal of a formality, where the formality message only includes the header MAI.
Data structures apply version D22B of the Multi-Modal Transport Reference Data Model (MMT) of the UNECE[4]. They are therefore defined in terms of MMT classes and attributes. The mapping of MMT attributes with the corresponding EMSWe data elements are provided in the corresponding formality page in tab "mapping".
The data structure defines the different classes and attributes that are part of the formality, the sequence of the classes and attributes, and the level of hierarchy of the classes. The following information is provided for the classes and attributes:
Note: EMSWe data set applied by this Message Implementation Guide consists of a revision of the data set published under Delegated Regulation (EU) 2023/205 (R02). The corresponding Delegated Act is under preparation.
In order to go down one level in the hierarchy, the class at the higher level in the hierarchy needs to be present. Submission of empty classes should be avoided (i.e. all classes should contain at least one data element).
Attributes corresponding to data elements of type "Measure" contain a mandatory sub-attribute which corresponds to data element DE-001-01 (Measurement unit, coded). This sub-attribute does not appear in the data structures provided in page "Formalities".
Attributes corresponding to data elements of type "Text" may contain an optional sub-attribute indicating the language of the text using ISO 639-1 2A codes. This sub-attribute does not appear in the data structures provided in page "Formalities".
Responses refer to a reference data set which is distinct from the EMSWe data set (ref. R02). It is provided in page "Downloads". Every data element is identified by a unique identification number (with prefix 'RE'). Data elements of responses are described in a similar manner as data elements of formalities, with the indication of:
The descriptions of the data structures of responses and of the header RES are provided in page "Responses". Each message must include the header RES and the response content (e.g. FRM). Messages may include as well one or several binary attachment files, if this is allowed by the MNSW for the specified response.
The data structures apply as well the UNECE MMT Reference Data Model and are described in the same manner as data structures of formalities.
The description of each rule, condition, or guideline applicable to attributes or classes in the formalities and responses is provided in page "Rules, conditions, guidelines".
The following naming convention is applied for identifying a rule, a condition or a guideline: "P-XXX-NNN", where:
Rules and conditions are meant to be checked automatically by the RIM (refer to section 3.4).
A guideline provides indications on how to use a certain attribute or class.
Some MNSW may require or accept that certain binary files are attached to a formality. Such files generally consist of copies of supporting documentation.
The MNSWs of the following countries accept attachment files: BE, CY, FI, HR, IE, IT, MT, PL.
Other MNSWs don't accept attachment files.
The table below provides the list of possible types of attachments and their corresponding formalities and MNSW countries. Each type of attachment is identified by a code, as defined in the EMSWe dataset (see reference R02, Code list "Attachment type").
| Code | Name | Description | MNSW country | Corresponding formality |
| ATT-001 | Additional declarations required by the products tables | Additional declarations required by the tables Relating to the individual products | IT | BLU |
| ATT-002 | Additional documentation on railway wagons goods transport | Additional documentation for goods transported in railway wagons required by Decree 303/2014 point 7.3.c of the Italian Ministry for Infrastructure and Transport. | IT | HZA |
| ATT-003 | Analysis certificates and related declarations of carried substances | certificates of analysis and related declarations referred to in Section 4.3 of Italy D.M. 22/07/1991 | IT | BLU |
| ATT-004 | Authorization for radioactive materials transport | Decree authorizing the transport of radioactive materials issued to the carrier (7.1a) | IT | HZA |
| ATT-005 | Authorization to embark | IT | CGA | |
| ATT-006 | Boarding form of non-hazardous waste including list | Instance - boarding of non-hazardous waste (including waste list) | IT | CGA |
| ATT-007 | Bunker delivery receipt | MT | BKD | |
| ATT-008 | Cargo information form | Form for cargo information referred to in section 4.2. of Italy D.M. 22.07.1991 | IT | BLU |
| ATT-009 | Carrier's declaration on radioactive materials | declaration by the carrier, by a qualified expert attesting that all the procedures required by the current legislation for the transport of radioactive materials have been observed (7.1c) | IT | HZA |
| ATT-010 | CIPE Authorization | Authorization of the Italian Comitato Interministeriale per la Transizione Ecologica with relative declaration of consent of the State of destination (waste destined for non-EU countries) | IT | CGA |
| ATT-011 | Cisterns residues exemption declaration | Ship declaration exempted from compliance with maximum values of residues in cisterns. | IT | HZA |
| ATT-012 | Clearance from terminal | IT | CGA | |
| ATT-013 | Communication and receipt certificate for waste destinated to EU countries | Communication to the competent authority of destination and relative certificate of receipt (waste destined for eu countries) | IT | CGA |
| ATT-014 | Communication of incoming waste and certificate of receipt | Communication to the territorially competent Region and relative certificate of receipt (incoming waste) | IT | CGA |
| ATT-015 | Consent to retain waste and the related washing /prewashing waters | Copy of the consent of the waste and of the relative washing / prewashing waters with the indication of the final destination of the same | IT | HZA |
| ATT-016 | Containers loader declaration | Loader declaration for the containers (7.2 c1 c2) | IT | HZA |
| ATT-017 | Cyanide transport Police Authorization | IT | HZA | |
| ATT-018 | Dangerous goods manifest or stowage plan | Special poster or loading plan according to rule 7-2.2 part A-1 of the chapter. VII of SOLAS | IT | BLU |
| ATT-019 | Solid bulk cargo density declaration | Declaration pursuant to rule 10.2 of chap. XII of SOLAS issued by a testing body accredited by the Administration of the country where the product is produced or, failing that, by the accredited measurement organization as defined in paragraph 2.2 of annex 1 of Decree 30.11.2010 No. 1340 or, in case of justified urgency, by a chemist registered in the professional register. | IT | BLU |
| ATT-020 | harbour chemist visa | IT | CGA | |
| ATT-021 | Holds security status certification | Security status certification of the holds issued by a port chemical consultant in compliance with the provisions of art. 25 of Italy Legislative Decree 272/99 | IT | BLU |
| ATT-022 | International trips accompanying documents and financial guarantee | A copy of the accompanying documents referred to in Regulation (EC) No 1013/2006 and subsequent amendments, and the financial guarantee referred to in Italy Ministerial Decree of 3 September 1998, n. 370 until it is replaced by the decree referred to in art. 194 paragraph 4 of the Italy legislative decree 3 April 2006, n. 152 (international travel only) (7.3b) | IT | HZA |
| ATT-023 | Loading and unloading plan | IT | BLU | |
| ATT-024 | Manual referred to in rule 5.3.5 of Annex II to Marpol 73/78 | Manual, approved by the Administration, ensuring that no operational mixing of cargo residues and water will occur and that no cargo residues will remain in the tank after applying the ventilation procedures prescribed in the Manual. | IT | HZA |
| ATT-025 | Manufacturer statement on the goods to be loaded | goods manufacturer statement about the characteristics and quantity of the substances / products to be loaded | IT | HZA |
| ATT-026 | Means used to carry explosive materials | data relating to the means of transport used for entry into or exit from the port of the explosives to be loaded or disembarked (7.2 d) | IT | HZA |
| ATT-027 | Means used to carry radioactive materials | Data relating to the means of transport used for entry or exit of the radioactive material to be loaded or disembarked (7.1b) | IT | HZA |
| ATT-028 | Multimodal dangerous goods declaration | dangerous goods declaration according to SOLAS 74, chapter VII, regulation 4; MARPOL 73/74 Annex III, Regulation 5.2. | IT | HZA |
| ATT-029 | No impediment to goods unload | Form to communicate that there are no impediments to the unloading of the goods | IT | CGA |
| ATT-030 | Non-hazardous waste loading declaration | IT | CGA | |
| ATT-031 | Permission to disembark | IT | CGA | |
| ATT-032 | Person's photograph | BE | STW, ABS | |
| ATT-033 | Pilot card | SRV | ||
| ATT-034 | Road vehicles and rail cars loader declaration | Declaration of the loader for road vehicles and rail cars (7.2 b2 b3) | IT | HZA |
| ATT-035 | Road vehicles registration certificate | Registration certificate, for road vehicles, with annotation on the suitability of transportation of explosives (or equivalent) (7.2 b1) | IT | HZA |
| ATT-036 | Safety checklist | IT | BLU | |
| ATT-037 | Ship certificate | CY, FI, IT | CRT | |
| ATT-038 | Side shell plan | IE | NOA | |
| ATT-039 | Suitability Attestation | Attestation of suitability as per Italy D.P.R. 50/84 | IT | HZA |
| ATT-040 | Suitability tanks statement | Commander Statement regarding tank suitability and their facilities to receive the substances / products to be loaded | IT | HZA |
| ATT-041 | Technical special standards compliance certification | Certification of compliance with the special technical standards referred to in Article 8 of Italy D.P.R. 50/84 | IT | HZA |
| ATT-042 | Towage certificate | MT | SRV | |
| ATT-043 | Towage plan | MT | SRV | |
| ATT-044 | Towage recommendations | MT | SRV | |
| ATT-045 | Waste classification declaration | Waste classification declaration (art.5 paragraph 2 of Italy dm 459/1991) | IT | CGA |
| ATT-046 | Waste tracking documentation | Documentation for the traceability of waste provided for in articles 188-bis, 188-ter and 193 of Italy Legislative Decree 3 April 2006, n. 152 (7.3a) | IT | HZA |
| ATT-047 | NIL list | Document used by ship masters to inform that there is no animals, ammunitions, weapons, dangerous goods etc. on board the ship | HR | NOA |
| ATT-048 | Technical data form for lightering of mineral oil | Form to be provided in case of lightering of mineral oil according to Italy DM 3/5/1984 | IT | SRV |
| ATT-049 | Technical data form for lightering of gas | Form to be provided in case of lightering of gas according to Italy DM 3/5/1984 | IT | SRV |
| ATT-050 | Master declaration as per art. 21 – DM 3/5/1984 | Ship master declaration to be provided in case of lightering of mineral oil according to Italy DM 3/5/1984 | IT | SRV |
| ATT-051 | Master declaration as per art. 23 – DM 3/5/1984 | Ship master declaration to be provided in case of lightering of gas according to Italy DM 3/5/1984 | IT | SRV |
| ATT-052 | Statement of suitability as per art.1, par.2 - DM 3/5/1984 | Statement of suitability to be provided in case of lightering of gas according to Italy DM 3/5/1984 | IT | SRV |
| ATT-053 | Master declaration as per R.D. 30 march 1942, n. 327 -art.179 | Declaration to be provided by the master in order to get the clearance at departure. | IT | NOD |
| EMSA | European Maritime Safety Agency |
| EMSWe | European Maritime Single Window environment |
| EORI | Economic Operators Registration and Identification |
| EU | European Union |
| GUI | Graphical User Interface |
| HLSG | High-Level Steering Group for Governance of the Digital Maritime System and Services |
| IMO | International Maritime Organization |
| ISO | International Organization for Standardization |
| LRN | Local Reference Number |
| MIG | Message Implementation Guide |
| MMT | Multi-Modal Transport Reference Data Model |
| MNSW | Maritime National Single Window |
| MRN | Master Reference Number |
| MS | Member State |
| RIM | Reporting Interface Module |
| UCC | Union Customs Code |
| UN/LOCODE | United Nations Code for Trade and Transport Locations |
| UNECE | The United Nations Economic Commission for Europe |
[1] As specified by the UCC/DA Annex B – TITLE II (R04): "The local reference number (LRN) shall be used. It is nationally defined and allocated by the declarant in agreement with the competent authorities to identify each single declaration"
[2] The corresponding term used in UCC is "invalidation".
[3] The corresponding term used in UCC is "amendment".
|
|
|
|
|
|
|
|
|
|
|||||||||||||||||||||||||||||||||||||||||
