Electronic Shipper’s Declaration for

Dangerous Goods (e-DGD)

Implementation Guide
Version control
Version Date Status Author Summary of changes
0.1 07JUN2017 initial Dr. Philipp Billion Initial
0.2 09AUG2017 extended “ Extensions
0.3 14AUG2017 extended “ As template for e-DGD Working Group
0.4 04SEP2017 extended “ Extensions
0.5 11SEP2017 extended Sarah Idir, Beverly Added content sent in via Email
Seebach, Ying Lu
0.6 27SEP2017 extended e-DGD PoC WG Input from working Group Meeting
processed
0.7 13OCT2017 extended Dr. Philipp Billion Further completion
0.8 01NOV2017 extended Dr. Philipp Billion / e- Further additions / corrections based
DGD PoC WG on the results of the F2F-Meeting in BSL
0.99 05DEC2017 extended e-DGD PoC WG Further additions / corrections (not
completed yet)
0.99RC2 27DEC2017 extended Dr. Philipp Billion / e- Adjustments to the use of XFSU-DIS
DGD PoC WG
1.0 29JAN2018 extended e-DGD PoC WG
1.1 06FEB2018 extended Dr. Philipp Billion / e- Adjustments to the use of XFSU-DIS –
DGD PoC WG use of errors after alignment with DG
experts
2.2 06JUN2018 extended e-DGD PoC WG
2.3 13AUG2018 extended Dr. Philipp Billion Change to XFSU DIS data elements
according to feedback from IATA
CMWG
2.4 13AUG2018 Extended e-DGD PoC WG Input from e-DGD F2F-Meeting #14
2.5 13AUG2018 extended Dr. Philipp Billion
2.6 08NOV2018 extended Dr. Philipp Billion Principles for the PoC included
2.7, 2.8 22NOV2018 extended e-DGD PoC WG Minor adjustments
3.0 11DEC2018 extended e-DGD PoC WG Final adjustments based on feedback of
IATA DG experts
3.0.1 11DEC2018 extended e-DGD PoC WG Formatting change
3.0.2 12DEC2018 extended Jacinthe De Oliveira Added table of correspondence with
Appendix B

2
Table of Contents

1. Introduction ................................................................................................................................................................................................ 4
1.1. General Introduction.......................................................................................................................................................................... 4
1.2. Background .......................................................................................................................................................................................... 4
1.3. Objectives ............................................................................................................................................................................................. 4
2. e-DGD principles ...................................................................................................................................................................................... 4
2.1. Business process ............................................................................................................................................................................... 4
2.2. e-DGD Data platform ......................................................................................................................................................................... 4
2.3. Identification and data exchange practice ................................................................................................................................ 5
3. Business Process Requirements ....................................................................................................................................................... 5
3.1. Standard Process ............................................................................................................................................................................... 5
3.2. Process variations .............................................................................................................................................................................. 6
3.3. Additional requirements................................................................................................................................................................... 6
4. Technical specification of message and data fields ................................................................................................................... 7
4.1. Shipper´s Reference ID ................................................................................................................................................................... 7
4.2. XSDG ....................................................................................................................................................................................................... 8
4.3. XFNM ....................................................................................................................................................................................................... 9
4.4. FSU/XFSU-FOH (Freight on Hand at airline) .............................................................................................................................. 9
4.5. FSU/XFSU-RCS (Ready for Carriage at airline) ...................................................................................................................... 10
4.6. FSU/XFSU-DIS (Airline Dangerous Goods acceptance check failed)........................................................................... 10
4.7. Digital accompanying documents ............................................................................................................................................. 12
5. Airline´s requirements to platform ................................................................................................................................................. 14
5.1. Station configuration list ............................................................................................................................................................... 14
6. Irregularities process ........................................................................................................................................................................... 14
6.1. Change of AWB Number by forwarder in the “directly assign”-process ..................................................................... 14
7. Improvement potential........................................................................................................................................................................ 14
7.1. Communication of reopening of update channel ................................................................................................................ 14
7.2. Using the IATA matchmaker infrastructure for carrier capabilities ............................................................................... 14

3
 1. Introduction
1.1. General Introduction
Digitization currently is a focus topic for the air transport
supply chain. There is a strong momentum of major
stakeholders heading for digitizing the supply chain partially
or holistically. The implementation of the digital processes
for dangerous goods (DG) is considered to be promising in
terms of benefits.
The current approach to digitize the Shipper's Declaration
for Dangerous Goods (DGD) is community-driven – it is not
based on airlines, forwarders or shippers engagement
solely. As this can only be successful when all stakeholders
participate, this starting point seems most fitting for an
effective implementation. The goal of these activities by the
stakeholders of the supply chain is to provide a digital
environment for DG shipments, where DG data is created
once and then shared throughout the supply chain. In
addition to many other bene-fits, this solution will prevent
re-capturing of DG data at any stage and raise data quality
with extensive quality checks.
The airline industry´s task is to support the community
approaches with in-depth know-how about airline´s
processes and experience gathered in digitization of the
cargo documents.
1.2. Background
The IATA e-DGD initiative began at the end of 2016 with the
establishment of the Electronic Shipper’s Declaration for
Dangerous Goods (e-DGD) Proof of Concept Focus Group
including three airlines and one ground handling agent (Air
France Cargo, Lufthansa Cargo, SWISS World Cargo and
Cargologic), who had recognized the momentum of the
industry to move forward. These actors see the need for the
paperless process among various stakeholders in the air
cargo supply chain and are contributing to three non-
related DG-community driven projects:
- e-DGD by Cargo Information Network (CIN) in CDG;
- INFr8-DGD by Dakosy / Fraport in FRA;
- e-DG App by IGAC Switzerland in ZRH.
1.3. Objectives
The goal of this document is to define requirements and
provide a guide for data sharing platforms, airlines,
shippers, freight forwarders, ground handling agents (GHA)
and other stakeholders that want to integrate an e-DGD
functionality. The document is based on the learnings from
the e-DGD pilot projects during their runtime in 2018. The
standard will be updated continuously to adopt new
requirements and integrate further improvements.
In terms of standardization, this implementation guide will
ensure the consistency of the business processes, define
the data flow and validate the XML e-DGD (XSDG) message.
The content of this e-DGD implementation guide is
intended to be used as guidance material for stakeholders
who wish to implement the use of the e-DGD. This
document complements Resolution 618, IATA Dangerous
Goods Regulations (DGR) Manual and all of the existing
regulations therein remain applicable.
2. e-DGD principles
The e-DGD principles are intended to provide a guideline to
the basic approach of e-DGD.
2.1. Business process
The set of the business process rules aims to clarify the e-
DGD process and enforce a compliant process.
2.1.1. Strictly paperless process
If a shipment uses the electronic transmission for
submitting the DGD (based on the existence of an
electronic e-DGD message), a paper version of the DGD
shall not be accepted or considered.
2.1.2. Single process
Should the routing (transit, destination) require a paper
version of the DGD, the airline or the GHA on behalf of the
airline shall print the document (Single Process). The format
of the printed document shall comply with the IATA
standard set out in DGR Section 8.
2.1.3. No mixed consolidated shipments
When consolidating dangerous goods shipments, the
forwarder shall not mix shipments with paper DGD and e-
DGD. It shall be either a consolidation of shipments with
paper DGD only or shipments with e-DGD only.
2.2. e-DGD Data platform
The digitization of the DGD requires collaboration of the
supply chain stakeholders through participation on a data
platform, whether local, national, regional or international.
4
 2.2.1. Roles and responsibilities 2.2.7. Transparency on shipment status

e-DGD creation, modification, cancellation and use shall be Any e-DGD rejected during the DG acceptance check shall
restricted to parties according to permissions (shipper / be reported back to the data platform with the shipper´s
freight forwarder / airline / GHA / 3rd party). The data reference number of the affected e-DGD and a reason for
platform should validate the training expiration of the users rejection.
for all parties acting with it and shall be administered by
each party.
2.3. Identification and data
2.2.2. Print of e-DGD Data
exchange practice
For full traceability, each e-DGD shall be identifiable and
An electronic copy of the e-DGD (non-editable pdf) should
authenticated. Industry communication standard should be
be made available based on the latest version of the data.
favored in order to ensure that the data platforms and
The signature(s) may be electronic signature(s) or may be
systems are compatible and interoperable.
re-placed by the name(s) (in capitals) of the person
authorized to sign, unless facsimile signature is required by
the local applicable laws and regulations. 2.3.1. 2.3.1 Unique identifier

The shipper´s reference number shall be unique and used

2.2.3. Data freeze
to identify an e-DGD. It should be set up according to the
agreed definition (see 4.1 below).
The shipper will be able to modify the signed/finalized e-
DGD data until the point where the next party has started to
work with the data. After this point, a recall mechanism can 2.3.2. Use of standard message formats
only be carried out outside of the portal by other means of
communication. The preferred means for communication should be IATA
Cargo XML messaging standards (XSDG, XFSU, XFNM).
All the mandatory e-DGD data supplied on the data platform
must be frozen prior to the dangerous goods acceptance
check. The XFSU-FOH message (Freight On Hand status)
triggers automatically a data freeze on the e-DGD data
platform. In case of shipment rejection, data shall be made 3. Business Process
editable again. After goods acceptance (RCS status), the
data shall be definitely frozen. Requirements
2.2.4. e-DGD update or marking data as void 3.1. Standard Process
If an e-DGD cannot be modified if necessary, the e-DGD
The data should be made available to any authorized
needs to be recalled (marked as void) and a new e-DGD shall
stakeholder in the supply chain, preferably directly from the
be issued with the corrected data. Whenever an e-DGD has
platform. As a scope, the role of the three major
been cancelled by the shipper, the corresponding data is
stakeholders will be considered in detail here: shipper,
flagged as “recalled” and considered as void (the data still
forwarder and airline. The role of one or more of the involved
exists in the system).
parties might be fulfilled by a subcontractor (GHA, trucking
company, packing companies, third party providers, etc.),
2.2.5. Data quality who might also need access to the data.

e-DGD data must achieve highest data quality with

3.1.1. Shipper: prepare DG shipment and data
automated checks at data entry or data import.
for export

2.2.6. Legal agreement The shipper provides the data, either with web based data
capture, or via an interface connected to their in-house
Terms and conditions of e-DGD data platform shall cover system. The shipper then assigns the shipment to a
legal agreement between stake-holders (according to IATA forwarder. In assigning the shipment to a forwarder, the
DGR Section 8). shipper´s active part of the process in the plat-form is
finished. In addition to the required marks and labels on

5
packages and overpacks, the shipper shall print and affix a
QR code giving access to the direct link (i.e. no need to login
or register) to the e-DGD lookalike in PDF format. This QR
code will be provided by the platform (see chapter 3.3.2).
After the shipment has been prepared, the shipper can have
full transparency on the acceptance process status and
send updates in case of irregularities.
3.1.2. Forwarder: assign shipment to airline for
transport
The forwarder is informed by the platform that a DG
shipment has been attributed to them. The forwarder
assigns the shipment to an airline for transportation by
adding an AWB number. That can either be done with web
based data capture, or via an interface connected to their
in-house system. The assignment of the shipment to the
airline triggers the data transmission to the airline´s system
based on the AWB number prefix. The forwarder should also
add the airport of departure as mentioned in the AWB.
Requirement: It is essential that the platform prevents the
forwarder from changing the e-DGD data other than AWB
number, airport of departure and air-port of destination.
3.1.3. Airline: perform acceptance check based
on e-DGD data and transport shipment
The airline receives the data from the platform and
performs the dangerous goods acceptance check based
on that data. No paper will be accepted. The result of the
acceptance check will be reported back to the platform.
Requirement: It is essential that the platform prevents the
airline from changing e-DGD data other than AWB number,
airport of departure and airport of destination.
Requirement: When applicable, the airline needs to make
sure that the e-DGD data is made available to the GHA at a
given station.
3.1.4. Import agent role
For the import process a paper DGD copy might be needed
to be provided to the consignee or their agent. To replace
the paper DGD and digitize the import process, various
solutions can be implemented to provide the relevant
information. For example:
• the platform could provide an option to access the e-
DGD lookalike in PDF format via a short URL link and/or
through a QR code, or
• the forwarder hands over the DG data to the
subcontractor. This can be made in many ways, e.g.
with sending an e-DGD lookalike in PDF format via
email, or giving the agent access to the forwarder´s
document management system.
Only as a workaround, the airline might provide an option for
getting a paper copy of the e-DGD lookalike, either by the
staff or with a self-service terminal. This solution should
only be a last fallback solution, and not be used on a regular
basis. If the airline provides a paper copy, it will always be a
black and white paper copy.
3.2. Process variations
3.2.1. Shipper working in the platform but not
forwarder (”directly assign”-process)
If a shipper works in an e-DGD platform and has an AWB
number for the shipment, but their forwarder is not working
in the e-DGD platform, the platform must provide an option
for the shipper to directly assign the e-DGD to an airline. On
using this option, the XSDG of each consignment must be
sent to the airline according to the AWB prefix.
The shipper will then use the paper process with their
forwarder. The shipper will print the paper DGD based on
the latest data in the platform and provide the paper DGD to
the for-warder. The forwarder will then deliver the shipment
with the paper DGD to the airline. The airline will find the e-
DGD data in the system based on the AWB number and
reject the pa-per DGD, according to the rule that no paper
is taken into account if the e-DGD data has been submitted
by the shipper on the platform.
Requirement: it is essential that any changes to the DG data
by the shipper is done in the platform in the “directly
assign“-process.
If the AWB number is not known to the shipper, and the
forwarder doesn´t work in the plat-form, the shipment will
be handled completely based on a paper DGD. It will not be
an e-DGD shipment.
3.3. Additional requirements
3.3.1. Airport of departure should be entered
and should be station of freight delivery
The platform will need a mechanism for each airline to
configure each station as enabled or not enabled for e-
DGD. If an airline, the authorities or other major
stakeholders at the origin of a shipment are not capable of
handling e-DGD shipments, this must be made transparent
to the shipper and / or the forwarder.
6
As a precondition for this, the airport of departure should be
inserted in the e-DGD data and should be the
station/airport, where the goods will be delivered and
accepted by the airline. For example if Johannesburg is
open for e-DGD by Air France Cargo and Cape Town is not,
there will be a problem if an e-DGD shipment with an origin
Johannesburg is delivered by the forwarder at Cape Town,
which doesn´t support e-DGD.
3.3.2. Platform function to provide short URL
link and QR code to e-DGD lookalike in
PDF format without login
The platform is expected to provide a short URL link to have
direct access to the e-DGD lookalike in PDF format. Along
with the link, the platform is also expected to provide the
corresponding QR code that will be on a shipment label. The
mention “e-DGD shipment” should appear on the QR code
label. The link will always point to the latest version of the e-
DGD lookalike.
3.3.3. DG Data freeze
In terms of e-DGD, there must be a preliminary and a
permanent data freeze. Data freeze requirements of the
forwarder are not in the scope of this guide, only airline
requirement is covered.
• 3.3.3.1 Preliminary data freeze
Preliminary data freeze in a platform should be performed
as soon as another party further down in the supply chain
starts to work on the shipment or the data (e. g. dangerous
goods acceptance checks by airlines or DG checks by the
forwarder). As soon as one of these conditions is met, the
platform must prevent the shipper from updating / signing
an updated version of the e-DGD. Until that point, any
change in the DG data will automatically update the e-DGD
lookalike in PDF format to the latest version.
Preliminary data freeze by the airline side is triggered by the
airline with the FOH status message or a message rejection
on an XSDG update. There is no option for the shipper or the
forwarder to send updates during the DG acceptance
check process.
Preliminary data freeze can be released in many ways: e.g.
bilateral communication, a failed DG acceptance check or
stop work on the shipment. This communication is not yet
covered electronically, and this option is taken up in the
chapter “Improvement potential” below.
• 3.3.3.2 Permanent data freeze in platform
Permanent data freeze is performed once the shipment has
been successfully accepted (RCS status) by the airline. The
data then should switch to freeze and no modification
should be possible anymore.
3.3.4. Display feedback / updates / status
changes for supply chain stakeholder
Platforms must inform the users (shipper / forwarder) about
updates / status changes / rejections when they are logged
in the platform or working with an integrated in-house sys-
tem. For example if an update message is rejected by the
airline, all stakeholders must be informed according to their
self-administration in the platform (e.g. notification).
3.3.5. e-DGD information must be completely in
English
For e-DGD shipments the English version of the DGD must
be transmitted and used. In case a local language is also
required due to regulations / deviations, a local solution
must be adopted to be compliant.
4. Technical
specification of
message and data
fields
4.1. Shipper´s Reference ID
The Shipper´s Reference ID is unique and used to identify
an e-DGD globally. It is mandatory for the e-DGD process.
It consists of a:
• Platform identifier: it reflects the entity, that
guarantees the fulfillment of the underlying business
rules; this is a combination of 3 characters
(alphanumeric);
• Digital / Paper - process indicator: this informs
whether the message originates from a digital process
(D) or a paper process (P). These letters are identical
with the <ram:ProcessType> in the XSDG message;
• Shipper´s Reference component: this is a
combination of alphanumeric characters to ensure
uniqueness within a platform; the Shipper´s Reference
component shouldn´t be longer than 15 characters.
The structure of the Shipper´s Reference ID is:
7
“Platform identifier”-“Digital / Paper - process indicator”- between DGR units and code used in the XSDG XML
Schema.
“Shipper´s Reference component”

The components are separated with the character MINUS “-

“.

Example: “CIN-D-COCO55562378”, where:

• “CIN” is the platform identifier;

• “D” is the Digital / Paper - process indicator;

• “COCO55562378” is the Shipper´s Reference

component.

In the specific case where the shipment is tendered with a

paper DGD and as a non e-DGD shipment, the airline may
want to capture the DGD data for their own use.

In that case the airline will capture the DG data in his system
and assign a Shipper´s Reference ID as follow:

• Platform identifier: as the data has not been initiated

through a platform but captured by the airline, the
platform identifier will consist of the AWB prefix of the
airline (3 digits);

• Digital / Paper - process indicator: The letter P will be

used to identify the data has been capture from the
paper DGD;

• Shipper´s Reference component: This will be the

shipper’s reference number of the paper DGD if
available, or any other unique identifier within the airline
otherwise.

But in that case, the shipment will still need to fly with the
original paper DGD tendered with the shipment.

4.2. XSDG
If used for data transmission, the XSDG should be used as
per the Cargo XML standard.

4.2.1. DGR Requirements vs Cargo XML code

The units of measurement to be used in the transport of

dangerous goods by air are those specified by the
International System (SI) as modified for international civil
aviation by Annex 5 to the Chicago Convention on
International Aviation. This units of measurement are
described in the appendix B of the Dangerous Goods
Regulations. The table below provide the correspondence

8
Translation table: UNECE annex 20 kiloelectronvolt B29 keV

Common Codes / Technical ohm per metre H26 Ω/m

ampere per
Abbreviations - DGR Appendix B metre
AE A/m
joule per
J2 J/kg
kilogram
Technical gigabecquerel
UNECE annex GBQ GBq
Abbreviations
Name 20 Common becquerel BQL Bq
- DGR
Codes
Appendix B CUR Ci
curie
metre MTR m
millicurie MCU mCi
centimetre CMT cm
microcurie M5 µCi
millimetre MMT mm
sievert D13 Sv
micrometre 4H µm
millisievert C28 mSv
inch INH in microsievert per
P72 µSv/h
KGM kg hour
kilogram
gray A95 Gy
gram GRM g
watt per square
MGM mg D54 W/m²
milligram metre
hour HUR h

second SEC s
hertz HTZ Hz 4.3. XFNM
kelvin KEL K
The XFNM should be used as per the Cargo XML standard
degree Celsius CEL °C
to confirm the XSDG message has been received
degree
FAH °F (acknowledgement), processed or rejected. In case an
Fahrenheit
electronic DGD is rejected by the receiving system due to
square metre MTK m²
failure of one or more system validation, an XFNM message
square
CMK cm² should be triggered, containing the applicable rejection
centimetre
millimetre code/s as per the MIP Error Code list.
squared per C17 mm²/s
second Additionally the following content should be added into the
litre LTR L following fields:

millilitre MLT mL
<rsm:BusinessHeaderDocument> <ram:ID>: This field
gallon (US) GLL gal
should be filled identical with the same field in the XSDG.
kilopascal KPA kPa

pascal PAL Pa 4.4. FSU/XFSU-FOH (Freight on

kilogram per
square metre
28 kg/m² Hand at airline)
gram per square
GM g/m² An FSU-FOH or XFSU-FOH must be issued for all e-DGD
metre
BAR bar shipments at the time of cargo delivery, and prior to DG
bar
acceptance check. The FOH status is sent to and used by
newton NEW N
the platform to prevent changes to the DGD data while the
kilogram-force B37 kgf acceptance check is being performed.
newton per
C56 N/mm²
square millimetre
megaelectronvolt B71 MeV

9
 4.5. FSU/XFSU-RCS (Ready for
Carriage at airline)
Once the DG acceptance check and all other ready for
carriage checks have been successfully completed, the
accepting party must issue a formal FSU/XFSU-RCS
containing the AWB number. The RCS status is sent to and
used by the platform to freeze the DGD data.
4.6. FSU/XFSU-DIS (Airline
Dangerous Goods
acceptance check failed)
4.6.1. Data transmission format
Manual rejections due to a failed DG Acceptance check will
be transmitted via XFSU with a new shipment status code
“Shipment rejected”. This message will be transmitted
directly to the platform from the airline.
4.6.2. General fields
Generally, the use of most data fields should be according
to the standard requirements. Additionally the following
content should be added into the following fields:
<rsm:BusinessHeaderDocument><ram:ID
This field should be filled with the AWB number.
<rsm:MasterConsignment><ram:ReportedStatus><ram:As
sociatedStatusConsignment><ram:DiscrepancyDescripti
onCode>
It should be “ACCF” for Acceptance Check Failed; this
Discrepancy Description Code “ACCF” is not endorsed by
IATA yet, but still should be implemented in the first version.
4.6.3. Rejection information
The free text information, the rejection reason code, and the
effected Shipper´s Reference ID(s) should be transmitted
in the OSI-part of the XFSU-DIS according to the following
schema:
First repetition of
<rsm:MasterConsignment><ram:ReportedStatus><ram:As
sociatedStatus
Consignment><ram:HandlingOSIInstructions><ram:Descr
iption>
Block should contain the free text rejection information
as entered by the DG checker describing the reason why
the shipment was rejected plus any additional relevant
information for all stakeholder.
Second repetition of
<rsm:MasterConsignment><ram:ReportedStatus><ram:As
sociatedStatus
Consignment><ram:HandlingOSIInstructions><ram:Descr
iption>
Block should contain the rejection reason code
according from the “Discrepancy Code list” as described
in the next section. Also this code should be entered /
selected by the checker.
Third and any further repetition of
<rsm:MasterConsignment><ram:ReportedStatus>
<ram:AssociatedStatusConsignment><ram:HandlingOSIIn
structions><ram:Description>
Block should contain the shipper reference number as
entered / selected by the DG Checker.
The use of hard coded
<ram:DescriptionCode>OSI</ram:DescriptionCode> in the
<rsm:MasterConsignment><ram:ReportedStatus><ram:As
sociatedStatusConsignment><ram:HandlingOSIInstructio
ns>
Block is required here.
10
One example for the content of the OSI-fields:
<rsm:MasterConsignment>
<…>
<ram:ReportedStatus>
<ram:AssociatedStatusConsignment>
<ram:HandlingOSIInstructions>
<ram:Description>The flammable liquid labels on pieces #1 and #15 are missing</ram:Description>
<ram:DescriptionCode>OSI</ram:DescriptionCode>
</ram:HandlingOSIInstructions>
<ram:HandlingOSIInstructions>
<ram:Description>2019DG13.00</ram:Description>
<ram:DescriptionCode>OSI</ram:DescriptionCode>
</ram:HandlingOSIInstructions>
<ram:HandlingOSIInstructions>
<ram:Description>InF-D-1203912</ram:Description>
<ram:DescriptionCode>OSI</ram:DescriptionCode>
</ram:HandlingOSIInstructions>
<ram:HandlingOSIInstructions>
<ram:Description>InF-D-1203913</ram:Description>
<ram:DescriptionCode>OSI</ram:DescriptionCode>
</ram:HandlingOSIInstructions>
<ram:HandlingOSIInstructions>
<ram:Description> ……</ram:Description>
<ram:DescriptionCode>OSI</ram:DescriptionCode>
</ram:HandlingOSIInstructions>
</ram:AssociatedStatusConsignment>
</ram:ReportedStatus>
</rsm:MasterConsignment>

11
 4.6.4. Discrepancy Code list
The discrepancy code list is set up following the logic of the
IATA standard DG - / RA-acceptance check sheet. As a
schema for the code list, the following wording should be
used:
YYYYTyQQ.QQ
Where:
• “YYYY” is the version of the checklist used (e.g. 2018)
• “Ty” is the type of checklist (“DG” for dangerous goods
checklist for a non-radioactive shipment; “RA” for
dangerous goods checklist for a radioactive shipment)
• “QQ.QQ” are the question and sub-question numbers.
Example 1:
“2019DG13.00” would refer to question 13 on the 2019 for
dangerous goods checklist for a non-radioactive shipment.
Example 2:
“2019DG16.01” would refer to question 16, first sub
question (“Compatible according to Table 9.3.A”) on the
2019 for dangerous goods checklist for a non-radioactive
shipment.
4.7. Digital accompanying
documents
4.7.1. Types of accompanying documents
For each XSDG message, there can be one or more
additional accompanying documents shared from the DG
platforms. There will always be an e-DGD lookalike in PDF
format (that may include a facsimile signature if required by
the local applicable laws and regulations), but an unlimited
number of additional documents can be attached as well. All
digital accompanying documents are expected in PDF
format.
In addition to the e-DGD lookalike, the following
accompanying documents types can be attached:
• Packaging Certificate
• State Approval
• Operator Approval
• Exemption
• Template Airline Acceptance Check Sheet
• Completed Airline Acceptance Check Sheet
• Other
The contribution to the type is transmitted in the meta-file
accompanying each PDF document (see below).
4.7.2. Data transmission
• 4.7.2.1. Setup and file name convention
The transmission standard for accompanying digital
documents is based on the simultaneous transmission of
two files: The PDF file and an XML metadata file. The
filenames of both files should be identical with
“Shipper´sReferenceID_AWBNo_CounterID”, as used in
the message header of the XSDG (Example: CIN-D-
COCO55562378_020-25864658_01); so the filenames
would be InF-D-1203912_020-25864658.pdf and InF-D-
1203912_020-25864658_01.xml).
12
• 4.7.2.2. XML meta data file

Element Description Purpose Example

ShipmentPrefix Shipment Prefix of AWB To identify AWB No. 020
AWBSerialNumber AWB Serial Number To identify AWB No. 77077011
ShipperReferenceNumber shipper reference Number optional, mandatory in
digital process
DocumentType Constant. Always DGRDOC To clear correlation to DG- DGRDOC
process
DocumentSubType
Type of DG Associated document. As described in the list Operator Approval
above

ConversationID
ConversationID passed from DG To correlate with XSDG 2
Portal. Should be matching with the message
conversationID in XSDG.
TotalFileCount
Total count of Documents to be
expected in this conversation ID.

13
 5. Airline´s requirements 6.1.2. Shipper or forwarder have triggered a
transmission with a wrong / incomplete
to platform data

If a shipper or a forwarder has triggered a transmission to

5.1. Station configuration list the airline with wrong / incomplete data, it is the sender´s
responsibility to either:
The airline must be able to configure for each station the e-
DGD status (station-whitelist). This will provide • update their data, or
transparency for all stakeholders on the capability of the
airline at that station to handle e-DGD shipments at export. • trigger a cancellation request.
If a shipper or a forwarder attributes a shipment to a station
that is not on the station-whitelist, the shipper or the
forwarder will receive a warning so that they need to print
the e-DGD lookalike. It should be possible for airlines to
upload or download the station configuration list to/from
7. Improvement
the data platform. The file should be in XLS format and
contain basic information such as: IATA three letter airport potential
code, IATA two letter airline code and e-DGD capability.

This configuration option should be taken as minimal

7.1. Communication of
requirement by the carrier to the plat-form. reopening of update
channel

6. Irregularities process
Currently there is no electronic communication to the
platform by the airline in case a shipment has achieved FOH
status or was rejected, but the update channel was opened
again on the airline side. As FOH already triggered a
6.1. Change of AWB Number by temporary freeze of data in the platform, the required
forwarder in the “directly unfreezing is not communicated electronically. This
communication could be de-fined and added to increase
assign”-process transparency.

The “directly assign”-process is only used when the

forwarder doesn´t use the platform, and the AWB number
has been provided to the shipper (see 3.2.1 above). If the
forwarder changes the AWB number on the paper DGD, the
e-DGD data will not be updated. At the acceptance check,
the data will not be available under the new AWB number.
Two solutions are available:
• update of e-DGD data by shipper with new AWB
number;
• paper process is used, based on the paper DGD print
presented by the forwarder and this shipment will not
be considered as an e-DGD shipment (the paper DGD
tendered by the forwarder will fly with the shipment)
7.2. Using the IATA
matchmaker infrastructure
for carrier capabilities
The IATA matchmaker infrastructure is a shared repository
for station and airline specific capabilities at export. It would
connect an airline specific station-whitelist of capable
stations at export, maintained by airlines, with the
transparency requirements of all stakeholders. For
platforms, this is the single source of information on the
airline´s capabilities.

6.1.1. Possibility for cancelling DG data (mark as

void)

The shipper must have the option to cancel e-DGD data

already transmitted to the platform. The platform still should
keep a history of the recalled data.
14