eDouane EMCS WORKFLOW SPECIFICATIONS - douanes … · Administration des Douanes et Accises du Luxembourg eDouane EMCS – Workflow Specifications – Fast Guide p. 4/41 1 Introduction

Administration des Douanes et Accises du Luxembourg

Auteur Administration des Douanes et Accises du Luxembourg (ADA) - Division EMCS

Version 1.1 Dernière mise à jour 18/02/2011

eDouane EMCS

WORKFLOW SPECIFICATIONS

Fast Guide

Version 1.1


eDouane EMCS – Workflow Specifications – Fast Guide p. 2/41

TABLE OF CONTENTS

1 Introduction ................................................................................................................. 4

2 Reference documents ................................................................................................. 5

3 Basic Scenarios........................................................................................................... 6

3.1 Submission & registration of e-AAD ................................................................................. 6

3.1.1 Overview ..................................................................................................................... 6

3.1.2 Description .................................................................................................................. 6

3.2 Submission of Report of Receipt ..................................................................................... 7

3.2.1 Overview ..................................................................................................................... 7

3.2.2 Description .................................................................................................................. 7

3.2.2.1 Delivery Accepted ............................................................................................................... 8 3.2.2.2 Delivery Refused ................................................................................................................. 8 3.2.2.3 Delivery partially Refused ................................................................................................... 9

3.3 Cancellation of an e-AAD by the consignor ...................................................................... 9

3.3.1 Overview ................................................................................................................... 10

3.3.2 Description ................................................................................................................ 10

4 Change of Destination before the reception of RoR .............................................. 11

4.1 Change MS of Destination ............................................................................................. 11

4.1.1 Overview ................................................................................................................... 11

4.1.2 Description ................................................................................................................ 12

4.2 Change of Consignee (not the MS of Destination) ......................................................... 12

4.2.1 Overview ................................................................................................................... 13

4.2.2 Description ................................................................................................................ 13

4.3 Change of Place of Delivery (Same MS of Destination, same consignee) ..................... 14

4.3.1 Overview ................................................................................................................... 14

4.3.2 Description ................................................................................................................ 14

5 Change of Destination after the reception of RoR ................................................. 15

5.1 Change of MS Destination ............................................................................................. 15

5.1.1 Overview ................................................................................................................... 15

5.1.2 Description ................................................................................................................ 16

5.2 Change only Consignee (Same MS of destination) ........................................................ 17

5.2.1 Overview ................................................................................................................... 17

5.2.2 Description ................................................................................................................ 17

5.3 Change only Place of Delivery ....................................................................................... 18

5.3.1 Overview ................................................................................................................... 18

5.3.2 Description ................................................................................................................ 19

5.4 Reminder at expiry time for change of Destination ......................................................... 19

5.4.1 Overview ................................................................................................................... 20

5.4.2 Description ................................................................................................................ 20

6 Other Valid Scenarios ............................................................................................... 21

6.1 General query to retrieve an e-AAD ............................................................................... 21

6.1.1 Overview ................................................................................................................... 21



6.1.2 Description ................................................................................................................ 21

7 Exception Handling ................................................................................................... 22

7.1 Manual Status Request/Response ................................................................................ 22

7.1.1 Overview ................................................................................................................... 22

7.1.2 Description ................................................................................................................ 22

7.2 Manual Status Synchronization Request ....................................................................... 23

7.2.1 Submission of RoR and the e-AAD is under the „Accepted‟ state at the MSA of Dispatch ................................................................................................................................. 23

7.2.1.1 Overview ........................................................................................................................... 24 7.2.1.2 Description ........................................................................................................................ 24

7.2.2 Change of MSA of Destination and the e-AAD is under the „Accepted‟, or „Partially Refused‟ or „Refused‟ state at the MSA of Destination ........................................................... 25


7.2.3 Cancellation and the e-AAD is under the „Accepted‟ state at the MSA of Destination 26


7.3 Automatic Status Synchronization Request ................................................................... 28

7.3.1 Missed e-AAD ............................................................................................................ 28


7.3.2 Delay RoR - Reminder at expiry of time limit for report of receipt ............................... 30


7.4 Manual Closing of the movement .................................................................................. 32

7.4.1 Overview ................................................................................................................... 32

7.4.2 Description ................................................................................................................ 32

Annexes ............................................................................................................................ 33

A.1 General architecture ...................................................................................................... 33

A.2 XML messages .............................................................................................................. 34

A.3 Communication Specifications ....................................................................................... 34

A.3.6.1 Security overview .............................................................................................................. 35 A.3.6.1.1. AS2 security concepts ..................................................................................................... 35 A.3.6.1.2. AS2 security in the edOUANE B2G scenario ................................................................. 35 A.3.6.2 SSL server/client authentication ........................................................................................ 36 A.3.6.3 IP address restriction......................................................................................................... 36 A.3.6.4 Message Encryption .......................................................................................................... 36 A.3.6.5 Message Signature ........................................................................................................... 37 A.3.6.6 Trading partner S/MIME certificate ................................................................................... 38

A.4 Contact persons ............................................................................................................ 38

A.5 Procedure ...................................................................................................................... 39

A.6 Technical information .................................................................................................... 40

A.6.1.1 Definition ........................................................................................................................... 40 A.6.1.2 Technical overview ............................................................................................................ 40 A.6.1.3 Advantages ....................................................................................................................... 40 A.6.2.1 Introduction ........................................................................................................................ 41 A.6.2.2 File location ....................................................................................................................... 41 A.6.3.1 Local REFERENCE NUMBER (LRN) ............................................................................... 41 A.6.3.2 LRN Structure .................................................................................................................... 41

A.7 Important information ..................................................................................................... 41



1 Introduction

The purpose of this document is to specify the messages workflow specifications between Luxembourg Customs and the economic operators systems within the context of EMCS project Phase 2.

The document will start with the EMCS messages workflow specifications by detailing the scenarios presented in the EMCS Workshop.

For each chapter, a reference to the document DDNEAv3.00 is given in order to have the extended details of the scenarios.

The annexes describe technical specifications related to the data communication and security, general information, technical definitions and specific related technical explanations.



2 Reference documents

Reference Document Name Version

DDNEA for EMCS Phase 2 ECP2-FITSDEV2-DDNEA-v3.00-EN.doc 3.0

Conformance Test Protocol For EMCS Phase 2

CTP-v2.08.pdf 2.08

EMCS Traders’ interface – XML messages

eDouane_EMCS_B2G_TradersInterface_XML Messages_V1.1.pdf

1.1

http://www.do.etat.lu/edouanes/eDouane_EMCS/Documents/ECP2-FITSDEV2-DDNEA-v3.00-EN.doc

http://www.do.etat.lu/edouanes/eDouane_EMCS/Documents/CTP-v2.08.pdf

http://www.do.etat.lu/edouanes/eDouane_EMCS/Documents/eDouane_EMCS_B2G_TradersInterface_XMLMessages_V1.1.pdf

http://www.do.etat.lu/edouanes/eDouane_EMCS/Documents/eDouane_EMCS_B2G_TradersInterface_XMLMessages_V1.1.pdf



3 Basic Scenarios

3.1 Submission & registration of e-AAD

Reference SECTION PAGE

ECP2-FITSDEV2-DDNEA-v3.00-EN.doc

III.I.1.1.1 65

3.1.1 Overview

3.1.2 Description

It should be noted that although the submission occurs before the actual dispatch of goods, if the e-AAD is submitted in deferred mode, then the actual dispatch of goods would have preceded the draft e-AAD submission.

The Consignor submits a draft e-AAD (Message IE815) to the MSA Dispatch application

The MSA Dispatch application disseminates the validated e-AAD (Message IE801) to the MSA Destination application and to the Consignor

The MSA Destination application forwards the e-AAD (Message IE801) to its Consignee

The state of the movement is set to “Accepted”, The timer is initiated

From To Message Operation State

Consignor MSA-DISP IE815 CheckAndValidateDraftEaadRequestIntercept

MSA-DISP Consignor IE801 CheckAndValidateDraftEaadResponse Accepted

ARC Added

MSA-DISP MSA-DEST IE801 ReceiveEaadRequest Accepted

ARC Added

MSA-DEST Consignee IE801 ReceiveEaadRequest Accepted

ARC Added



3.2 Submission of Report of Receipt



III.I.1.1.1.1 65

3.2.1 Overview

3.2.2 Description

When the goods arrive at their destination, the Consignee acknowledges the receipt of goods by submitting the draft Report of Receipt (RoR) to the MSA Destination application for validation. This RoR will indicate the acceptance of delivery (with or without shortages) or the refusal of delivery.

The Consignee acknowledges the receipt of goods by submitting the draft Report of Receipt (RoR) (Message IE818) to the MSA Destination application for validation


Consignee MSA-DEST IE818

Acceptance

Or

Refusal

Or

Partially

Refusal

CheckAndValidateDraftRoRRequestIntercept Delivred

Or

Refused

Or

Partially Refused



3.2.2.1 Delivery Accepted



III.I.1.1.1.2 65

The delivery is accepted (Acceptance) by the Consignee:

The MSA Destination changes the state of the e-AAD to “Delivered”

The MSA Destination forwards the validated Report of Receipt (Message IE818) to the MSA Dispatch application

The MSA Destination sends back the validated RoR to the Consignee as a confirmation (Message IE818)

The MSA Dispatch application changes the state of the e-AAD to “Delivered”

If the timer has not expired, the MSA dispatch application stops it otherwise it resets the flag raised locally at its expiration

The MSA Dispatch application forwards the delivery notification (Message IE818) to the Consignor to inform him/her for the acceptance of delivery and in series the discharge of the movement


MSA-DEST Consignee IE818 CheckAndValidateDraftRoRResponse Delivered

MSA-DEST MSA-DISP IE818 ReceiveRorRequest Delivered

MSA-DISP Consignor IE818 ReceiveRorRequest Delivered

3.2.2.2 Delivery Refused



III.I.1.1.1.3 67

The delivery is refused (refusal of delivery) by the Consignee:

The MSA Destination changes the state of the e-AAD to “Refused”



The MSA Dispatch application changes the state of the e-AAD to “Refused”

The MSA Dispatch application forwards the delivery notification (Message IE818) to the Consignor to inform him/her for the non acceptance of delivery

The MSA Dispatch application starts the timer waiting for the change of Destination from the Consignor


MSA-DEST MSA-DISP IE818 ReceiveRorRequest Refused

MSA-DEST Consignee IE818 CheckAndValidateDraftRoRResponse Refused

MSA-DISP Consignor IE818 ReceiveRorRequest Refused



3.2.2.3 Delivery partially Refused



III.I.1.1.1.4 69

The delivery is partially refused (Partial refusal of delivery) by the Consignee:

The MSA Destination changes the state of the e-AAD to “Partially Refused”



The MSA Dispatch application changes the state of the e-AAD to “Partially Refused”

The MSA Dispatch application forwards the delivery notification (Message IE818) to the Consignor to inform him/her for the partially acceptance of delivery

The MSA Dispatch application starts at timer to expire at the limit date for submission of a change of Destination


MSA-DEST Consignee IE818 CheckAndValidateDraftRoRResponse Partially Refused

MSA-DEST MSA-DISP IE818 ReceiveRorRequest Partially Refused

MSA-DISP Consignor IE818 ReceiveRorRequest Partially Refused

3.3 Cancellation of an e-AAD by the consignor



III.I.1.2.2 79

The purpose of this scenario is to describe the communication protocol when the Consignor requests the cancellation of a recently submitted and validated e-AAD. The scenario prerequisites that a draft e-AAD has been previously submitted and the goods have NOT left the place of Dispatch.



3.3.1 Overview

3.3.2 Description

Before the actual Dispatch of goods, the Consignor may send a cancellation message (Message IE810) to the MSA Dispatch application concerning the “Accepted” or “Exporting” or “Accepted for Export” e-AAD

The MSA Dispatch application updates the state of the e-AAD from “Accepted” or “Exporting” or “Accepted for Export” to “Cancelled” and forwards the cancellation notification (Message IE810 - Cancelled) to the MSA Destination application and back to the Consignor

If the timer associated with the cancelled e-AAD has already expired at the limit date, the MSA Dispatch application resets the flag that has been raised locally at expiration time. In the opposite case, if the timer associated with the cancelled e-AAD is still running, the MSA of Dispatch application stops it

the MSA Destination application sends the cancellation notification (Message IE810 – State=‟Cancelled‟) to the Consignee.


Consignor MSA-DISP IE810 CheckAndValidateDraftCancellationRequestExtended

Accepted or Exporting

or

Accepted for Export

MSA-DISP Consignor IE810 CheckAndValidateDraftCancellationResponse Cancelled

MSA-DISP MSA-DEST IE810 ReceiveCancellationRequest Cancelled

MSA-DEST Consignee

IE810 ReceiveCancellationRequest Cancelled



4 Change of Destination before the reception of RoR



II.I.1.2.1 71

The Consignor may change the Destination of an “Accepted” or “Exporting” e-AAD at any time after the Dispatch of goods but before the reception of the RoR from the Consignee. The new Destination can be a tax warehouse or the premises of a registered Consignee or of a temporary registered Consignee or a place of direct delivery or export. There are three possible change of Destination scenarios, either:

The MS of Destination changes: this implies that both Consignee and Place of Delivery change; or

The MS of Destination does not change but the Consignee (hence the place of delivery) changes; or

Neither the MS of Destination nor the Consignee change, but only the Place of Delivery changes.

4.1 Change MS of Destination



III.I.1.2.1.1 72

The assumption for this scenario is that the Consignor has initiated an excise movement and the e-AAD is already “Accepted” or “Exporting”.

4.1.1 Overview



4.1.2 Description

After the Dispatch of goods, the Consignor sends a message (IE813) to the MSA Dispatch application, to change the MS of Destination

The MSA Dispatch application, after validation, sends the update message (IE813) back to the Consignor as an acknowledgement and to the former MSA Destination application as a notification of the change of Destination

The MSA Dispatch application sends to the new MSA of Destination an e-AAD (Message IE801) with the information about the new Consignee and Place of Delivery

In case the journey time has changed, the MSA Dispatch application updates the timer if the expected end of the movement is still in the future or restarts the timer if the expected end of the movement is in the past

The former MSA Destination application sends a notification message (IE803 - State=‟Diverted‟) to former Consignee to inform him that the movement has changed Destination

The new MSA Destination application sends the e-AAD (IE801: State=‟Accepted‟) to the new Consignee to inform him that he is the new Consignee of the movement

the new MSA Destination application sets the state of the movement to “Accepted”


Consignor MSA-DISP IE813 CheckAndValidateDraftUpdateRequest Accepted or Exporting

MSA-DISP Consignor IE813 CheckAndValidateDraftUpdateResponse Accepted

MSA-DISP Former MSA-DEST

IE813 ReceiveUpdateRequest Accepted

MSA-DISP New MSA-DEST

IE801 ReceiveEaadRequest Accepted

Former MSA-DEST

Former Consignee

IE803 ReceiveDiversionRequest Diverted

New MSA-DEST

New consignee


4.2 Change of Consignee (not the MS of Destination)



III.I.1.2.1.2 74

The assumption for this scenario is that the Consignor has initiated an excise movement and the e-AAD is already in the “Accepted” state or “Exporting”.



4.2.1 Overview

4.2.2 Description

After the Dispatch of goods, the Consignor sends a message (IE813) to the MSA Dispatch application, to change the Consignee and the place of delivery

The MSA Dispatch application, after validation, sends the update message (IE813) back to the Consignor as an acknowledgement

The MSA Dispatch application sends to the unchanged MSA of Destination an e-AAD (Message IE801- State=‟Accepted‟) which includes the change of the consignee and the Place of delivery


The MSA Destination application sends a notification message (IE803 - State=‟Accepted‟) to the former Consignee to inform him that the consignment has changed Destination

The MSA Destination application sends the e-AAD (IE801: State=‟Accepted‟) to the new Consignee to inform him that he is the new Consignee of the movement




MSA-DEST Former Consignee


New MSA-DEST

New consignee




4.3 Change of Place of Delivery (Same MS of Destination, same consignee)



II.I.1.2.1.3 77

The assumption for this scenario is that the Consignor has initiated an excise movement and the e-AAD is already in the “Accepted” state or “Exporting”.

4.3.1 Overview

4.3.2 Description

After the Dispatch of goods, the Consignor sends a message (IE813) to the MSA Dispatch application, to change the place of delivery

The MSA Dispatch application, after validation, sends the update message (IE813) back to the Consignor as an acknowledgement and to the MSA Destination application


The MSA Destination application sends to the consignee the update message (IE813 – State=‟Accepted‟)




MSA-DISP MSA-DEST IE813 ReceiveUpdateRequest Accepted

MSA-DEST Consignee IE813 ReceiveUpdateRequest Accepted



5 Change of Destination after the reception of RoR



III.I.1.3 81

After the refusal or partial refusal of delivery from the Consignee through the RoR (Message IE818) the Consignor shall change the destination. The following scenarios describe the three options the Consignor has to change:

the MS of Destination,

the Consignee (hence, also the Place of Delivery)

the Place of Delivery. A precondition for these scenarios is that a change of Destination takes place for a movement that is either in the “Refused” state or in the “Partially Refused” state both at the MSA of Destination as well as at the MSA of Dispatch. It is also possible for the old Destination to be export.

5.1 Change of MS Destination



III.I.1.3.1.1 82

5.1.1 Overview



5.1.2 Description

This scenario describes the case where the Consignee refuses or partially refuses the delivery and the Consignor changes the MS of Destination.

The Consignor sends the update message (IE813) for the refused or partially refused delivery to the MSA Dispatch application

The MSA Dispatch application, after validation, sends the update message (IE813) back to the Consignor as an acknowledgement and to the former MSA Destination application as a notification of the change of Destination

The MSA Dispatch application sends to the new MSA of Destination an e-AAD (Message IE801 - State=‟Accepted‟) with the information about the new Consignee and Place of Delivery

o In case of change of destination for a “Partially Refused” movement, the refused quantity declared by the former Consignee in the partially refused report of receipt. Otherwise, the quantity is the same as the one in the original e-AAD (Message IE801).

The MSA Dispatch application stops the timer and updates the timer based on the new expected end of the movement, the state of the e-AAD at the MSA of Dispatch is updated by the MSA dispatch application from “Refused” or “Partially Refused” to “Accepted”.

The former MSA Destination application sends a notification message (IE803) to former Consignee to inform him that the whole consignment (in case of refusal – Message IE803 - state=‟Diverted‟) or the refused part of the consignment (in case of partial refusal – Message IE803 - state=‟Delivered‟) has changed Destination

The new MSA Destination application sends the e-AAD (Message IE801: state=‟Accepted‟) to the new Consignee to inform him that he is the new Consignee of the consignment


Consignor MSA-DISP IE813 CheckAndValidateDraftUpdateRequest Refused

Or

Partially Refused

MSA-DISP Consignor IE813 CheckAndValidateDraftUpdateResponse Refused

Or

Partially Refused

MSA-DISP Former MSA-DEST

IE813 ReceiveUpdateRequest Refused

Or

Partially Refused

MSA-DISP New MSA-DEST


Former MSA-DEST

Former Consignee


OR

Delivered

New MSA-DEST

New consignee




5.2 Change only Consignee (Same MS of destination)



III.I.1.3.1.2 84

5.2.1 Overview

5.2.2 Description

Another option of the Consignor in case of refused or partially refused delivery message (IE818) is to change the Consignee (hence, the Place of Delivery as well) without changing the MS of Destination. The e-AAD is already “Refused” or “Partially Refused”.

The Consignor sends the draft update (Message IE813) for validation to the MSA Dispatch application

The MSA Dispatch application, after validation, sends the update message (IE813) back to the Consignor as an acknowledgement

The MSA Dispatch application sends to the unchanged MSA of Destination an e-AAD (Message IE801) which includes the change of the consignee and the Place of delivery

o In case of change of destination for a “Partially Refused” movement, the refused quantity declared by the former Consignee in the partially refused report of receipt. Otherwise, the quantity is the same as the one in the original e-AAD (Message IE801)

The MSA Dispatch application stops timer and updates the timer based on the new expected end of the movement, the state of the e-AAD at the MSA of Dispatch is updated by the MSA dispatch application from “Refused” or “Partially Refused” to “Accepted”

The MSA Destination application sends a notification message (IE803 - State=‟Accepted‟) to the former Consignee to inform him that the whole consignment (in case of refusal) or the refused part of the consignment (in case of partial refusal) has changed destination



The MSA Destination application sends the e-AAD (Message IE801: State=‟Accepted‟) to the new Consignee to notify him that he is the new Consignee of the whole consignment (in case of refusal by the former Consignee) or of the refused part of the consignment (in case of partial refusal by the former Consignee)



Or

Partially Refused



IE803 ReceiveDiversionRequest Accepted

MSA-DEST New consignee


5.3 Change only Place of Delivery



II.I.1.3.1.3 87

5.3.1 Overview



5.3.2 Description

The Consignor may initiate the change of destination procedure to change the place of delivery of the consignment as a result of refusal or partial refusal of delivery through RoR (Message IE818). The e-AAD is already “Refused” or “Partially Refused”.

The Consignor sends the draft update (Message IE813) containing the new place of delivery for validation to the MSA Dispatch application

The MSA Dispatch application, after validation, sends the update message (IE813) back to the Consignor as an acknowledgement and to the MSA Destination application

The MSA Dispatch application stops the timer and updates the timer based on the new expected end of the movement, the state of the e-AAD at the MSA of dispatch is set by the MSA dispatch application to “Accepted”.

The MSA Destination application sends to the consignee the update message (IE813 – State=‟Accepted‟)



Or

Partially Refused


MSA-DISP MSA-DEST IE813 ReceiveUpdateRequest Accepted

MSA-DEST Consignee

IE813 ReceiveUpdateRequest Accepted

5.4 Reminder at expiry time for change of Destination



III.I.1.3.2 89



5.4.1 Overview

5.4.2 Description

The Consignor has initiated an excise movement, which has been refused or partially refused by the Consignee and the Consignor has not sent an updated message (IE813) within the time limits, which leads to the expiration of the timer. In that case, the MSA dispatch application sends a reminder to the Consignor. The e-AAD is already “Refused” or “Partially Refused”.

Upon the expiration, of the timer, the MSA Dispatch application sends a reminder (Message IE802) to the Consignor with

o The ARC of the movement o The identity of the declared Consignee o The limit date for the submission of the change of Destination

After the reception of this reminder, the Consignor initiates the change of destination process by selecting one of the options described in Chapter 5.


MSA-DISP Consignor IE802 ReceiveReminderRequest



6 Other Valid Scenarios

6.1 General query to retrieve an e-AAD



III.I.1.4.2 93

6.1.1 Overview

6.1.2 Description

This scenario describes the message exchange protocol between a MSA application and an initiator MSA application (which has initiated the e-AAD) when a MSA Official wants to retrieve an e-AAD, which has been initiated by a MSA application located in a different MSA from that of request.

The national MSA application (e-AAD requestor) sends a query (Message IE701) to the supposed MSA initiator of the requested e-AAD

If one or more e-AADs are retrieved: o The Initiator MSA application responds with either a list of e-AADs (Message IE821)

to the national MSA application

If no e-AADs are retrieved OR the maximum limit of retrieved e-AADs has been reached: o The Initiator MSA application responds with a refusal message (IE702) to the

national MSA application

From To Message Comment State

National MSA application

MSA initiator IE701

MSA initiator National MSA application

IE821

List of e-AADs

MSA initiator National MSA application

IE702 no e- OR the maximum limit of e-AADs



7 Exception Handling

7.1 Manual Status Request/Response



III.I.2.1.2 143

7.1.1 Overview

7.1.2 Description

Several information exchanges of an excise operation (identified by a unique ARC) require a timely response. This response is in the form of another information exchange. The Status Request/Response mechanism could be used at any time by the MSA Dispatch application/MSA Destination application to request the status of a particular e-AAD at the MSA Destination application/MSA Dispatch application. Case 1:

The MSA official (MSA Dispatch application) sends the message (IE904) to the MSA Destination application with:

o the request about the status of a particular e-AAD o the sequence number of the last business (event) message

The MSA Destination application sends the message (IE905) to the MSA Dispatch application with:

o the status of a particular e-AAD o the last sequence number of the specific ARC (AAD Reference Code)



From To Message Comment

MSA-DISP MSA-DEST IE904 Request about the status of a particular e-AAD

+ the sequence number of the last business (event) message

MSA-DEST MSA-DISP IE905 Status of a particular e-AAD

+ the last sequence number of the specific ARC

Case 2:


o The request about the status of a particular e-AAD o the last sequence number of the specific ARC

The MSA Dispatch application sends the message (IE905) to the MSA Destination application with:

o the status of a particular e-AAD o the sequence number of the last business (event) message

From To Message Operation

MSA DEST MSA-DISP IE904 Request about the status of a particular e-AAD

+ the last sequence number of the specific ARC

MSA-DISP MSA-DEST IE905 Status of a particular e-AAD

+ the sequence number of the last business (event) message

7.2 Manual Status Synchronization Request

The “Manual Status Synchronization Request” could be used at anytime by the MSA Officials to request movement status synchronization by receiving in reply of a status request not only the status of the movement but also any missing/delayed messages.

7.2.1 Submission of RoR and the e-AAD is under the ‘Accepted’ state at the MSA of Dispatch



III.I.2.1.3.1 145



7.2.1.1 Overview

7.2.1.2 Description

According to the following scenario, the RoR (Message IE818) has been submitted by the MSA of Destination. However, the message (IE818) has not been received by the MSA of Dispatch and the e-AAD is still in the “Accepted” state.

The MSA Dispatch application(official) sends the message (IE904) to the MSA Destination application with:

o the sequence number of the last business (event) message for the specific ARC o the last business (event) message o the state of the movement (Accepted) o eventually, the wish to synchronize the movement state in case a detected state de-

synchronization


o the status = „Delivered‟ or „Partially Refused‟ or ‟Refused‟ o the information that the last message received is IE801 o the last known sequence number of the specific ARC

The MSA Destination application sends the message (IE818) to the MSA Dispatch (only in case of de-synchronization of the movement)

o Upon the reception of a valid RoR (Message IE818), the MSA Dispatch application validates successfully its structure, stores its data and changes the state of the e-AAD from “Accepted” to “Delivered” or to “Partially Refused” or to “Refused”

o Finally, it is recommended that the MSA Dispatch application forwards the RoR (Message IE818) to the Consignor




MSA-DISP MSA-DEST IE904 Accepted

MSA-DEST MSA-DISP IE905 Delivered

Or

„Partially Refused‟ Or ‟Refused‟

MSA-DEST MSA-DISP IE818 Only in case of de-synchronisation of the movement

MSA-DISP Consignor IE818 ReceiveRorRequest

7.2.2 Change of MSA of Destination and the e-AAD is under the ‘Accepted’, or ‘Partially Refused’ or ‘Refused’ state at the MSA of Destination



III.I.2.1.3.2 148

7.2.2.1 Overview

7.2.2.2 Description

According to the following scenario, a change of MSA of Destination has occurred. However, the message (IE813) has not been received by the former MSA of Destination and the e-AAD is still in the “Accepted” or “Partially Refused” or “Refused” state.

The MSA Destination application(official) sends the message (IE904) to the MSA Dispatch application with:

o the last known sequence of the specific ARC o the state of the movement = „Accepted or „Partially Refused‟ or ‟Refused‟ o the last business (event) message received from MSA-Dispatch application o eventually, the wish to synchronize the movement state in case a detected state de-

synchronization




o the sequence number set to that of the last business (event) message sent to the MSA of Destination

o the status = „Accepted‟ or „Delivered‟ or „Partially Refused‟ or ‟Refused‟ o when the state in the MSA Dispatch application is „Accepted‟

the information that the last received message from the MSA Destination application is “None”,

o when the state is “Delivered”, “Refused” or “Partially Refused” the last received message from the MSA Destination application is RoR

(Message IE818)

The MSA Dispatch application sends the message (IE813) to the MSA Destination (only in case of de-synchronization of the movement)

o Upon the reception of a valid RoR (Message IE813), the MSA Destination application validates successfully its structure, updates its data and changes the state of the e-AAD from „Accepted‟ or „Refused‟ to „Diverted‟ or to “Partially Refused” to “Delivered”

o Finally, it is recommended that the MSA Destination application forwards the notification message (IE803) to the former Consignee


MSA-DEST MSA-DISP IE904 „Accepted‟ or

„Partially „Refused‟ or ‟Refused‟

MSA-DISP MSA-DEST IE905 „Accepted‟ or „Delivered‟ or

„Partially Refused‟

or ‟Refused‟

MSA-DISP MSA-DEST IE813 Only in case of de-synchronization of the movement



Or

Delivered

7.2.3 Cancellation and the e-AAD is under the ‘Accepted’ state at the MSA of Destination



III.I.2.1.3.3 150



7.2.3.1 Overview

7.2.3.2 Description

According to the following scenario, a movement has been cancelled at the MSA of Dispatch (e-AAD state at the MSA of Dispatch = “Cancelled”). However, the cancellation notification (Message IE810) has not been properly received by the MSA of Destination and the e-AAD is still in the “Accepted” state.

The MSA Destination application(official) sends the message (IE904) to the MSA Dispatch application with:

o the last known sequence of the specific ARC o the state of the movement = „Accepted‟ o the last business (event) message received from MSA-Dispatch application o eventually, the wish to synchronize the movement state in case a detected state de-

synchronization



o the status = „‟Cancelled‟ o the information that the last received message from the MSA Destination application

is “None”,

The MSA Dispatch application sends the cancellation message (IE810) to the MSA Destination (only in case of de-synchronization of the movement)

o Upon the reception of a valid Cancellation (Message IE810), the MSA Destination application validates successfully its structure, updates its data and changes the state of the e-AAD from „Accepted‟‟ to „Cancelled‟ which is a final state

o Finally, it is recommended that the MSA Destination application forwards the cancellation notification (Message IE810) to the Consignee




MSA-DEST MSA-DISP IE904 Accepted

MSA-DISP MSA-DEST IE905 Cancelled

MSA-DISP MSA-DEST IE810 Only in case of de-synchronization of the movement

MSA-DEST Consignee IE810 ReceiveCancellationRequest

7.3 Automatic Status Synchronization Request

A MSA shall use the IE904/IE905 mechanism to handle exceptions. In particular, the IE904/IE905 mechanism shall be automatically triggered in order to identify whether an e-AAD/RoR is missing due to a technical failure or due to a business discrepancy.

7.3.1 Missed e-AAD



III.I.2.1.4.1.1 155

7.3.1.1 Overview



7.3.1.2 Description

The Consignee sends the RoR (Message IE818) for a specific ARC, which is unknown at the MSA of Destination application.

The MSA Destination application automatically generates and sends to the MSA Dispatch application a Status Request (Message IE904)

o For the ARC and sequence number included in the received RoR including also the information that the status is “None” and no message has been received from the MSA dispatch application.

o In addition, the indication of a Status Synchronization Request in the message IE904 will be automatically set by the application

The MSA Dispatch application detects that the requested ARC is known and that it is in the “Accepted” state. It also detects that the IE904 message was submitted for state synchronization purposes.



o the status set to “Accepted” o the information that the last message received from the MSA Destination application

is “None”

The MSA Dispatch application sends the missing e-AAD (Message IE801) to the MSA Destination application

o The received e-AAD is stored by the MSA Destination application and the movement state is set to “Accepted”

The MSA Destination application applies the scenario described in chapter 0. If the MSA of Destination application received the delayed e-AAD (Message IE801), either before or after the reception of the re-submitted e-AAD Response (Message IE801), it should process the first message received and ignore the second, instead of sending an IE906 to reject it


Consignee MSA-DEST IE818 CheckAndValidateDraftRoRRequestIntercept



MSA-DISP MSA-DEST IE801 ReceiveEaadRequest



7.3.2 Delay RoR - Reminder at expiry of time limit for report of receipt



III.I.2.1.4.2.2 161

7.3.2.1 Overview

7.3.2.2 Description

The purpose of this scenario is to describe the message exchange protocol when the Consignee fails to submit the RoR within the allocated timer. The scenario prerequisites that a draft e-AAD has been previously submitted, as described in Chapter Error! Reference source not found., and has been made available to all concerned direct partners in “Accepted” state. It is also assumed that all validations of the incoming messages pass successfully.


o the sequence number of the last business (event) message for the specific ARC o the information that the e-AAD at MSA of Dispatch is found on the “Accepted” state

and no message has been received from the MSA Destination application


o the last known sequence number of the movement o the information that the MSA Destination application is found on the „Accepted‟ state

and the last received message from the MSA Dispatch application is the e-AAD information (Message IE801)



The MSA Dispatch automatically flags the concerned e-AAD (to allow further retrieval) and sends the message (IE802) to the Consignor and to the MSA Destination Application as a notification of the RoR delay.

The MSA Destination application automatically flags the concerned e-AAD (to allow further retrieval) and forwards the message (IE802 optionally), if relevant, to the Consignee to provide his/her own explanations on the delay

The Consignor is committed to enquire and, if relevant, provide explanations on the detected delay by sending to the MSA Dispatch application an explanation message (IE837)

The MSA Dispatch application forwards the message (IE837) to the MSA Destination application

If relevant, the Consignee sends to the MSA Destination application an explanation message (IE837) on the actual situation. It is to be noted, though, that the provision of explanations does not relieve the Consignee from his/her obligation to submit the RoR as soon as possible.

o The MSA Destination application validates it successfully and forwards it to the MSA Dispatch application to notify it of the reasons for the delay




MSA-DISP Consignor IE802 ReceiveReminderRequest

MSA-DISP MSA-DEST IE802 ReceiveReminderRequest

MSA-DEST Consignee IE802 Optionally ReceiveReminderRequest

Consignor MSA-DISP IE837 ForwardExplanationOnDelay

MSA-DISP MSA-DEST IE837 ReceiveExplanationOnDelayRequest

Consignee MSA-DEST IE837 ForwardExplanationOnDelay

MSA-DEST MSA-DISP IE837 ReceiveExplanationOnDelayRequest



7.4 Manual Closing of the movement



III.I.2.1.5 163

7.4.1 Overview

7.4.2 Description

The manual closing of the movement functionality is intended to be used as an exception handling mechanism only for movements that is not possible to close in the system because the procedure to be followed is not supported electronically. For any other reason, such as goods stolen on route, a MSA is entitled to interrupt the movement. Interruption of the movement is notified to all MSAs concerned by the movement, to the Consignor, to the Consignee, etc.

The MSA Dispatch application (official) sets the e-AAD „Manually Closed‟ state (Message IE801)

The MSA Dispatch application sends the status of the movement (Message IE905 with the sequence number of the last business message sent to the MSA of Destination) to the MSA Destination application as a notification that the movement has been closed manually at Dispatch.

The MSA Destination application sets the state of the corresponding e-AAD to “e-AAD Manually Closed”.


MSA-DISP MSA-DEST IE905 „Manually Closed



Annexes

A.1 GENERAL ARCHITECTURE

The „Business to Government‟ (B2G) approach of the eDouane project will use only:

Messages in XML format and the AS2 communication protocol

AS2 (standing for „Applicability Statement 2‟) is a specification about how to transport data securely and reliably over the Internet. It is described in detail in RFC4130 (http://www.ietf.org/rfc/rfc4130.txt)

AS2 specifies how to connect, deliver, validate and acknowledge data. AS2 creates an envelope for a message which is then sent securely over the Internet. Security is achieved by using digital certificates and encryption.

An implementation of AS2 involves two machines, a client and a server, communicating with each other over the Internet. On the operating system level, the AS2 client may be a server, too, offering its communication services to application software. The client sends data to the server, e.g. a trading partner. On receipt of the message the receiving application sends an acknowledgement or MDN (Message Disposition Notification) back to the sender.

Through the use of AS2, efficient and secure machine-to-machine communication of XML data is achieved.

The general approach can be illustrated by the goods declaration of the Transit process:

Translator

ERP system

Translator

ERP system

AS2

compliant

server

AS2

compliant

server

Translator

ERP system

Translator

ERP system

AS2

compliant

server

AS2

compliant

server

Trading Partner PLDA

1

2

3

4

5

6

78

HTTP HTTP

http://www.ietf.org/rfc/rfc4130.txt



1. Trading Partner‟s application generates the Declaration Data message that is mapped to XML data (IE15) and is sent to AS2 compliant server.

2. Trading Partner‟s AS2 server encrypts, signs IE15 XML message and sends to eDouane via HTTP.

3. eDouane AS2 server sends MDN (Message Disposition Notification) to inform the Trading Partner that „IE15‟ message has been received.

4. AS2 server uploads „IE15‟ into eDouane ERP system.

5. The eDouane system generates a Movement Reference Number (MRN) for identification of the Transit operation that is mapped to XML data (IE28) and sends it to the eDouane AS2 server.

6. AS2 server encrypts, signs and forwards „IE28‟ document to Trading Partner via HTTP.

7. The AS2 server of the Trading Partner decrypts „IE28‟ and uploads the file to the Translator.

8. The AS2 server of the Trading Partner sends a MDN to eDouane to inform that „IE28‟ message has been well received.

A.2 XML MESSAGES

The XML submitted to eDouane application must be compliant with the Luxembourg Customs standards.

The next part of this document will detail the different messages necessary for the different flows. All the „XSD‟ schemas required for the XML messages are described in the appendix 3 and 5.

A.3 COMMUNICATION SPECIFICATIONS

A.3.1 PROTOCOL

AS2 provides an „envelope‟ for the data, which is sent over the Internet using the standard HTTP protocol. Data is sent using a HTTP post (over TCP/IP) request to a static IP address.

The description of the security aspect of the communication will be details in the paragraph 4.6.

A.3.2 AS2 IDENTIFIER

The „Administration des Douanes et Accises‟ is identified by its AS2 identifier: „ADALUPLDA‟

Each XML message that will be exchanged contains an Interchange Header, which identifies - besides other data types - the sender and recipient of the message:

* Transit: MesSenMES3 (sender), MesRecMES6 (receiver)

* Non-transit : messageSender (sender), messageRecipient (receiver)

* ICS: MesSenMES3 (sender), MesRecMES6 (receiver)

* EMCS: MessageSender (sender), MessageRecipient (receiver)

The sender and receiver in this header must be identified by means of the AS2 identifier.



A.3.3 IP ADDRESS

All information regarding IP address and URL for connecting the test and production environments can be found inside the “AS2 Exchange Settings Document” received after successful registration as an “Economic Operator” with the Administration des Douanes & Accises.

A.3.4 CONNECTION INFO

Outgoing Message Security Outgoing data needs to be signed and encrypted

Incoming Message Security Incoming data requires signature and encryption

Compression Data can be compressed

A.3.5 MDN RECEIPTS

Security MDN receipts require a signature

Delivery MDN receipts are exchanged preferably in an asynchronous way

A.3.6 SECURITY

A.3.6.1 SECURITY OVERVIEW

A.3.6.1.1. AS2 SECURITY CONCEPTS

The AS2 protocol provides two different levels of security for the exchange of messages.

The first level provides security at connection and data transport level. This means that the connection is secure and the communication protocol data is encrypted and authenticated. Technically, this is achieved by using SSL over HTTP (HTTPS).

An additional level of security offered by AS2 is the usage of S/MIME mechanisms to achieve end-to-end-security rather than transport layer security. S/MIME stands for “Secure Multipurpose Internet Mail Extensions” and is a standard for public key encryption and signing of electronic messages encapsulated in MIME. End-to-end-security means that the authenticity, integrity, confidentiality and non-repudiation of the message contents (IE messages in XML representation) are ensured at the application level rather than those of the “raw” data streams that are exchanged “on the wire” between the server and client . Technically, this is achieved by the usage of Public-Key-Infrastructure-mechanisms based on X.509 certificates at the level of the AS2 payload.

A.3.6.1.2. AS2 SECURITY IN THE EDOUANE B2G SCENARIO

For AS2 communication between Trading Partners and the eDouane system, the HTTP protocol will be used. The usage of HTTPS is not necessary.

The payload of AS2 messages exchanged between Trading Partners and the eDouane system will be secured using S/MIME. Every message sent to and received from eDouane will be encrypted and signed. To this end, Trading Partners will have to purchase (a) S/MIME certificate(s) from one of the Certification Authorities accredited by eDouane. For more details about S/MIME message specification and certificate handling, please refer to RFC3850 and RFC3851.

Access to eDouane B2G functionality is restricted to authorized IP addresses. Trading Partners will have to register their IP address when applying for access to eDouane in order to be able to establish a B2G connection with eDouane.

http://en.wikipedia.org/wiki/Public_key

http://en.wikipedia.org/wiki/Encryption

http://en.wikipedia.org/wiki/Digital_signature

http://en.wikipedia.org/wiki/MIME



A.3.6.2 SSL SERVER/CLIENT AUTHENTICATION

This is the AS2 standard mechanism to ensure transport layer security. It is not used for eDouane B2G, which uses the standard HTTP protocol for data exchange.

A.3.6.3 IP ADDRESS RESTRICTION

The eDouane B2G server will only accept and respond to HTTP requests coming from authorized IP addresses. Trading Partners will have to register their IP address in order to establish a B2G connection with eDouane.

A.3.6.4 MESSAGE ENCRYPTION

Every XML message sent or received by the eDouane B2G server will be encrypted to ensure the confidentiality of the message. The eDouane B2G server will not accept messages that are not encrypted.

Technically, this means that the payload of the AS2 HTTP-requests will be encrypted using S/MIME.

RFC 4130 “MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)” explains how S/MIME mechanisms are incorporated into the AS2 protocol.

The details about security formatting, encryption algorithm support and S/MIME message structure are set forth in RFC‟s 3851/3852 "S/MIME Version 3.1 Message Specification; Cryptographic Message Syntax".

A trading partner encrypting a message to be sent to the eDouane B2G server will have to use the eDouane B2G public key. This key is contained in the eDouane B2G X.509 certificate of the Luxembourg Customs Administration. This is a S/MIME compliant certificate conforming to the provisions made in RFC 3850 “S/MIME Version 3.1 Certificate Handling”. Trading partners will receive this certificate as part of their registration process for eDouane B2G access and before any subsequent certificate change due to the expiration of the current certificate.

In order to be able to encrypt messages to be sent to the trading partner, eDouane will have to use the trading partner‟s public key. For this reason, trading partners will transmit their S/MIME certificate to eDouane B2G authority, the Luxembourg Customs Administration, in advance, as part of the registration process for eDouane B2G access and before any subsequent expiration of the current certificate.

The trading partner‟s certificate will ideally be a S/MIME compliant certificate which can be used for data encryption conforming to the provisions made in RFC 3850 “S/MIME Version 3.1 Certificate Handling”. It will be issued by a Certificate Authority (CA) that has previously been accredited for use with eDouane. Trading partners will use certificates issued by the Luxtrust CA.

Mandatory encryption does not apply to MDN receipts, which will be transmitted without encryption, but digitally signed. AS2 specifications do not provide for encrypted MDN exchange.



A.3.6.5 MESSAGE SIGNATURE

Every XML message sent or received by the eDouane B2G server will be digitally signed to ensure the integrity and authenticity of the message exchange. The eDouane B2G server will not accept messages that are not digitally signed.

Technically, this means that a digital signature of the payload of the AS2 HTTP-requests will be computed in compliance with S/MIME specifications.

RFC 4130 “MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)” explains how S/MIME mechanisms are incorporated into the AS2 protocol.

The details about security formatting, digest and signature algorithm support and S/MIME message structure are set forth in RFCs 3851/3852 "S/MIME Version 3.1 Message Specification; Cryptographic Message Syntax".

A trading partner verifying the digital signature of a message originating from the eDouane B2G server will have to use the eDouane B2G public key. This key is contained in the eDouane B2G X.509 certificate of the Luxembourg Customs Administration. This is a S/MIME compliant certificate conform to the provisions made in RFC 3850 “S/MIME Version 3.1 Certificate Handling”. Trading partners will receive this certificate as part of their registration process for eDouane B2G access and before any subsequent certificate change due to the expiration of the current certificate.

In order to be able to verify the digital signature of messages received from the trading partner by eDouane, eDouane will have to use the trading partner‟s public key. For this reason, trading partners will transmit their S/MIME certificate to eDouane B2G authority, the Luxembourg Customs Administration, in advance, as part of the registration process for eDouane B2G access and before any subsequent expiration of the current certificate.

The trading partner‟s certificate will ideally be a S/MIME compliant certificate which can be used for digital signatures conforming to the provisions made in RFC 3850 “S/MIME Version 3.1 Certificate Handling”. It will be issued by a Certificate Authority (CA) that has previously been accredited for use with eDouane. Trading partners will use certificates issued by the Luxtrust CA.

Mandatory digital signature applies to MDN receipts as well, which will always have to be digitally signed.



A.3.6.6 TRADING PARTNER S/MIME CERTIFICATE

Since the S/MIME security mechanisms used in the AS2 protocol are based on X.509 certificates for public key management, trading partners will have to acquire such a certificate in order to access eDouane B2G functionality. This is a summary of the most important features regarding the certificate, some of which were already mentioned above:

1. The certificate must be issued by a Certification Authority that is accepted for use with eDouane. Ideally, the certificate is issued by the Luxtrust CA.

2. The certificate must be compliant to the provisions made in RFC 3850 “S/MIME Version 3.1 Certificate Handling”.

3. Trading partners must provide in advance the eDouane B2G authority, the Luxembourg Customs Administration, with their certificates. This applies to the registration process for eDouane B2G access as well as any subsequent change of the certificate due to expiration of the current one.

4. The certificate for message encryption can be the same as the one for message signature, since S/MIME provides certificates used for more than one purpose. (e.g. keyUsage extension with values digitalSignature and keyEncipherment set). Trading partners do not need to get two different certificates.

A.4 CONTACT PERSONS

Contact Role Email Tel

Helpdesk eDouane Helpdesk [email protected] 290 191 345

Laurent Sabre Technical and functional support for B2G

[email protected] 26 89 73 20 28

Oliver Bluhm Technical and functional support for B2G

[email protected]

André-Louis Jadot Functional support [email protected]

26 89 73 20 28

Marc Peltier Functional support [email protected] 290 191 274

mailto:[email protected]








A.5 PROCEDURE

The following procedure describes the main steps to be accomplished so that an economic

operator or a service provider for economic operators may establish an electronic

Communication via the AS21 protocol with the Customs Office.

For ICS use the access request http://www.do.etat.lu/edouanes/eDouane_ICS/Documents/Form_Demande_Acces_eDouaneB2G_Operateur.doc.

For EMCS use the access request http://www.do.etat.lu/edouanes/eDouane_EMCS/Documents/Form_eDouaneEMCS_Demande_Acces_Utilisateurs.xls

For Import/export/transit use the access request http://www.do.etat.lu/edouanes/eDouane_Import-Export/Documents/Form_Demande_Acces_eDouaneB2G_Operateur.doc

Sending of the filled in form to the "Direction des Douanes & Accises".

Acceptance of the request form and notification by the customs office. Creation of an SAP identifier on the Customs Office servers.

Choice of an AS2 protocol software for establishing the B2G communication. The Customs Office may help in choosing the appropriate software.

Sending of the technical document called "AS2 Settings Exchange Document" by the Customs Office. This document contains all necessary parameters required for implementing the electronic communication. The economic operator needs to fill in this document and the return to the Customs Office implies an acceptance of the document.

The Business Partner needs to provide a proof that his communicated IP addresses through the previous document are indeed owned by him. Commonly, this is achieved by a written declaration from his "Internet Service Provider".

Configuration of the Business Partner on the customs office servers as well as all other required configuration for activating the B2G communication.

Purchase by the Business Partner of two SSL certificates (Test & Live) from “Luxtrust S.A.”. The purchase is realized throughout the following steps:

- Sending of the written certificate order form.

- Payment of the certificates.

- Generation of a pair of SSL keys.

- Execution of the electronic Certificate Signing Request (CSR).

- Retrieval of the signed certificates.

1 Applicability Statement 2

http://www.do.etat.lu/edouanes/eDouane_ICS/Documents/Form_Demande_Acces_eDouaneB2G_Operateur.doc

http://www.do.etat.lu/edouanes/eDouane_ICS/Documents/Form_Demande_Acces_eDouaneB2G_Operateur.doc

http://www.do.etat.lu/edouanes/eDouane_EMCS/Documents/Form_eDouaneEMCS_Demande_Acces_Utilisateurs.xls

http://www.do.etat.lu/edouanes/eDouane_EMCS/Documents/Form_eDouaneEMCS_Demande_Acces_Utilisateurs.xls

http://www.do.etat.lu/edouanes/eDouane_Import-Export/Documents/Form_Demande_Acces_eDouaneB2G_Operateur.doc

http://www.do.etat.lu/edouanes/eDouane_Import-Export/Documents/Form_Demande_Acces_eDouaneB2G_Operateur.doc



A.6 TECHNICAL INFORMATION

A.6.1 AS2

A.6.1.1 DEFINITION

AS2 (Applicability Statement 2) is a specification about how to transport data securely and reliably over the Internet. It is described in detail in RFC4130 (http://www.ietf.org/rfc/rfc4130.txt)

AS2 specifies how to connect, deliver, validate and acknowledge data. AS2 creates an envelope for a message which is then sent securely over the Internet. Security is achieved by using digital certificates and encryption.

An implementation of AS2 involves two machines, a client and a server, communicating with each other over the Internet. On the operating system level, the AS2 client may be a server, too, offering its communication services to application software. The client sends data to the server, e.g. a trading partner. On receipt of the message the receiving application sends an acknowledgement or MDN (Message Disposition Notification) back to the sender.

A.6.1.2 TECHNICAL OVERVIEW

AS2 provides an „envelope‟ for the data, which is sent over the Internet using standard protocols (HTTP for AS2, FTP pour AS3, SMTP for AS1).

Data are sent using HTTP POST requests.

Data transmission is over TCP/IP (with or without SSL) to a static IP address.

Data can be transmitted signed and encrypted.

“Non-Repudiation”2

A.6.1.3 ADVANTAGES

Removal of Value-added network (VAN) costs

Designed to push data securely and reliably over the Internet

Fast and reliable connectivity

Encryption ensures that only the sender and receiver can view the data

Digital signatures ensure authentication: only messages from authorized senders are accepted

Hash algorithm insures integrity by detecting whether the document was altered during transmission

2 Non-repudiation is the concept of ensuring that a contract, especially one agreed to via the internet, cannot later be denied by one of the parties involved.

In regard to digital security, non-repudiation means that it can be verified that the sender and the recipient were, in fact, the parties who claimed to send or receive the message, respectively. In other words, non-repudiation of origin proves that data has been sent, and non-repudiation of delivery proves it has been received.

http://www.ietf.org/rfc/rfc4130.txt



A.6.2 CODES LISTS

A.6.2.1 INTRODUCTION

For the different messages required for the B2G there will be technical and functional validations. Technical validation means verification compared to format. For the functional validation, the eDouane project has included code lists and validation rules that are checked against specific values in the XML message.

A.6.2.2 FILE LOCATION

The codes lists are stored in the „zip‟ file : PLDA Codes list.zip.

A.6.3 XML MESSAGES

A.6.3.1 LOCAL REFERENCE NUMBER (LRN)

Import and export messages are sent in by a « declarant » into the eDouane system of the Customs Office. These messages first go into a SAP system which then transfers it to the back-end system where identification of the « declarant » as being a « Representative » takes place. In order for a « Representative » to be recognized properly, he must already exist as « Business Partner (BP) » inside the SAP system. The precise identification of a message and its sender becomes a critical task.

The « LocalReferenceNumber » allows for univocal identification of the « Representative » which contains the SAP identifier (Business PartnerID). Each « declarant » having a unique Business PartnerID, the objective of the LRN is to insure that it is unique by « declarant » and by year.

A.6.3.2 LRN STRUCTURE

Following is an example of a LRN: 0700LUXYZ1230000000001

07 : year (2 digits)

00LUXYZ123 : SAP identifier (Business Partner), 10 alphanumerical

characters

0000000001 : counter (10 digits)

The maximum length of the LRN is 22 characters. As stated beforehand, it needs to be unique inside the eDouane application to avoid that it is being refused with a message IE917.

A.7 IMPORTANT INFORMATION

Please note that a named user LuxTrust Card is mandatory to use the B2G protocol. Each economic operator which wants to use this communication protocol has to request a certified card to LuxTrust for each user who has to deal with.