Conversion Guidelines
between
Cargo-XML and CARGO-IMP
Developed by: IATA Cargo-XML Task Force (CXMLTF)
Date: 7th May 2014
www.iata.org
A. Overview
CARGO-IMP standards are widely used in the air cargo industry. Since industry is
migrating to Cargo-XML standards, there are situations when one party is using a
messaging standard different than its partner. In this situation, there was a requirement
from the industry to define the messaging conversion guidelines from one format to
other.
The IATA CXMLTF developed this document to facilitate the industry implementation of
Cargo-XML Messages. This document was further reviewed by other industry bodies and
endorsed by the IATA Cargo Business Processes Panel (CBPP)
This document provides the guidelines to the industry for converting CARGO-IMP to
Cargo-XML messages and vice versa. The guidelines are based on the character set, data
length, field occurrence, structure, semantics, and data types for both standards.
For any further information please contact Cargoxml@iata.org
B. Introduction
1. CARGO-IMP to Cargo-XML conversion is simple and straight forward as all commonly
used information in the CARGO-IMP messages is also available in the equivalent
Cargo-XML messages.
2. Cargo-XML messages, however, contain additional information that is not part of the
CARGO-IMP messages.
3. This additional information in Cargo-XML messages is either optional or mandatory
however all mandatory elements have default values so it provides the flexibility for
converting a CARGO-IMP to Cargo-XML message.
4. It is recommended that parties involved in Cargo-XML messages exchange, upgrade
their Cargo Management and/or Messaging Systems to include these additional
fields of the Cargo-XML messages otherwise; there is a risk of data/information loss.
5. The CXMLTF reviewed the different characteristics (character set, data length, field
occurrence, structure, semantics, and data types) of both standards while converting
CARGO-IMP to Cargo-XML and vice versa.
C. CARGO-IMP to Cargo-XML Conversion Guidelines
6. CARGO-IMP supports sub-set of ASCII characters that includes:
 the letters A to Z (upper case only)
 the numerals 0 to 9
www.iata.org
 the special characters / -. Space < =
7. Since Cargo-XML has larger character set than CARGO-IMP message, therefore there
is no conversion issue from CARGO-IMP to Cargo-XML messages.
Note: Cargo Service Conference (CSC) airline members have agreed to upgrade the
CARGO-IMP character set to ASCII 7 bit and this will be applicable from 01 January
2014.
8. CARGO-IMP messages, data field length and occurrences are limited and there is no
issue when converting into equivalent Cargo-XML message.
9. CARGO-IMP messages structure is different than the Cargo-XML messages therefore
conversion solution should be developed in accordance with the specification and
schemas in Cargo-XML Manual and Toolkit latest edition.
10. CARGO-IMP message semantics are different from the Cargo-XML message
semantics and conversion solution should consider these semantics. Below table
relates CARGO-IMP message standards with their equivalent Cargo-XML messages:
CARGO-IMP & Cargo-XML Messages Relationship
CARGO-IMP Messages
Cargo-XML Messages
FWB
FFM
FZB
FHL (type-II)
Contains shipper and consignee
FHL (type-I)
Checklist
FMA
FNA
FFR
FFA
CSN
FSU
FSA
FBL
FBR
FSR
FWR
FZA
FZC
STR
www.iata.org
XFWB
XFFM
XFZB
XFZB
XFHL
XFNM
XFNM
XFFR
XFFR
XCSN
XFSU
XFSU
XFBL
XGRQ
XGRQ
XGRQ
XGRQ
XGRQ
XGRQ
11. The CXMLTF noted that CARGO-IMP fields data types are not replicated in CargoXML e.g. NVC is char(3) in CARGO-IMP however, its equivalent Cargo-XML field is
Boolean (i.e. NoValueForCustoms = true). It is therefore recommended that
conversion solution resolves this mismatch.
12. Date format used in CARGO-IMP messages is DDMMM (e.g. 25APR) however CargoXML dates follow the ISO 8601:2004 (e.g.YYYYMMDDTHH:MM:SS).
13. FWB conversion to XFWB
14. FWB line reference 22 (Commission Information) and 23 (Sales Incentive
Information) are not included in the XFWB message. These line references in FWB
messages were intended for CASS functions and are not used by the industry.
15. FWB line reference 28 (Other Participant Information (OPI)) cannot be built in CargoXML (not enough information for Cargo-XML to fill the mandatory fields).
16. FWB line References 9 (Also Notify), 28 (Other Participant Information) and 26
(Nominated Handling Party) are represented by the XFWB “List of Other Party
Details” (by repeating the same data element) and the individual party is identified
by the “Unique Party Type Code” value.
a. NI (Notify Party) value for line ref 9 (Also Notify),
b. OJ (Third party) value for line ref 28 (Other Participant Information),
c. FB (Nominated Freight Company) value for line ref 26 (Nominated Handling
Party).
D. Cargo-XML to CARGO-IMP Conversion Guidelines
17. The Cargo-XML messages are multi-purpose. It means one message could be used
for creation, deletion and update function. The CXMLTF recommends consulting
Cargo-XML Manual and Toolkit (Business Rules Table) that highlight the functionality
associated with each Cargo-XML Message.
18. The Cargo-XML messages are based on UTF-8 character set that contains many
special characters including Latin and other characters.
19. The CXMLTF believes that at present ASCII 7 bit character set serve the industry
requirement and recommend using the ASCII 7 bit character set for Cargo-XML
Messages.
20. The CXMLTF decided to review the Data Length and Occurrence of Cargo-XML
standards on message/document basis.
21. The Air Waybill Analysis (FWB and XFWB)
22. The Air Waybill is the key document and has combined interest from Airlines, Freight
Forwarders, Ground handlers, Customs and IT Service Providers therefore the
CXMLTF decided to review Air Waybill/XFWB/FWB first and then others
messages/documents subsequently.
www.iata.org
23. The CXMLTF conducted an analysis for the Air Waybill layout and reviewed the data
length and data type in CARGO-IMP and Cargo-XML messages.
24. The Air Waybill layout, information is split into 76 boxes where each box may
represent one or more data elements in the FWB/XFWB.
25. There are five air waybill boxes that could result in potential data length issues and
there is no issue in regards to data type.
26. The remaining 71 air waybills boxes are either based on the code list or limited to
numeric values e.g. charges, rates etc. that couldn’t result in data length issue.
27. Complete Analysis sheet is attached.
Data Length and
Type v01.xlsx
28. The five boxes that could result into potential data length issues are:
A. Box 2: Shipper Name and Address
B. Box 4: Consignee Name and Address
C. Box 10: Accounting Information
D. Box 21: Handling Information
E. Box 22I Nature and Quantity of Goods (including Dimensions or Volume)
www.iata.org
29. The CXMLTF reviewed each of the above data field in detail in FWB(CARGO-IMP) and
XFWB (Cargo-XML) standards.
30. It is recommended considering the CARGO-IMP character representation associated
with the Cargo-XML fields in the Cargo-XML Manual and Toolkit specification when
converting XFWB to FWB.
31. The CXMLTF decided to add a new field “Rec. Length” associated with the each data
element definition in message specification in the Cargo-XML Manual and Toolkit.
32. This “Rec. Length” will be a generic field and where not harmonized with CARGOIMP data length, a Note will be added in the Cargo-XML specification to highlight the
difference.
33. The FWB routing element (Line reference 4) supports maximum three occurrences
however, XFWB is unlimited.
34. Action Item: A note will be added in the XFWB equivalent data element that FWB
supports max three occurrences of routing.
35. Box 2: Shipper Name and Address
www.iata.org
36. The Shipper Name and Address in XFWB messages are currently constraints to
CARGO-IMP Char representation text (35) as per FWB ver 16 however, these should
be extended to support text (70) in accordance with FWB ver 17.
37. Action Item: IATA Secretariat will upgrade the text in XFWB Shipper Name and
Address field to indicate 70 characters each. The new field “Rec. length”, will have
the value 70 characters. A note will be added in the Cargo-XML Manual and Toolkit
highlighting that FWB Shipper Name and Address supports text 70 characters and it
is recommended to use this limitation to avoid any conversion issues. Failure to
adopt this may result in data loss, truncation or rejection.
38. Box 4: Consignee Name and Address
39. The Consignee Name and Address in XFWB are constraints to CARGO-IMP Char
representation text (35) as per FWB ver 16 however; these should be referring to
text (70) in accordance with FWB 17.
40. Action Item: IATA Secretariat will upgrade the text in XFWB Consignee Name and
Address field to indicate 70 characters each. The new field “Rec. length” will have
the value 70 characters. A note will be added in the Cargo-XML Manual and Toolkit
highlighting that FWB Consignee Name and Address supports text 70 characters and
it is recommended to use this limitation to avoid any conversion issues. Failure to
adopt this may result in data loss, truncation or rejection.
41. Box 10: Accounting Information
42. It was noted that Accounting Information is comprised of two information sets i.e.
Also Notify and Shipper Reference Number.
43. Also Notify
44. FWB data element “Also Notify” is covered by the “List of Other Party Details” in
XFWB and the “List of Other Party Details” has the same structure as Shipper and
Consignee data elements.
45. The CXMLTF decided that the solution advised for Shipper & Consignee in AWB Box
2 and 4 is also applicable here.
46. Action Item: IATA Secretariat will upgrade the CARGO-IMP Char Representation in
XFWB “List of Other Party Details” Name and Address field to indicate 70 characters
each. The new field “Rec. length” will have the value 70 characters. A note will be
added in the Cargo-XML Manual and Toolkit highlighting that FWB Notify Party
Name and Address support text 70 characters.
47. It was noted that “List of Other Party Details” is a generic element and it is also used
for Other Participant Information (OPI) and Nominated Party (NOM).
48. Shipper Reference Number
49. The CXMLTF noted that there is no conversion issue with the shipper reference
number.
www.iata.org
50. Box 21: Handling Information
51. Handling Information is comprised of five information sets i.e. Special Handling
Instructions, Special Services Requests, Other Service Information, OCI and Product
Name.
52. Special Handling Instructions
53. The FWB supports max nine special handling codes however, XFWB supports
unlimited.
54. The CXMLTF recommends adding a note in XFWB specification that FWB supports
nine special handling codes.
55. Action Item: IATA Secretariat will add a note in XFWB specification “Special Handling
Instructions” indicating that FWB supports nine special handling codes.
56. Special Services Requests
57. FWB data element “Special Services Requests” supports 195 characters.
58. The CXMLTF recommends adding a note to XFWB specification that FWB supports
195 characters in Special Services Request.
59. Action item: Add a note in XFWB specification “Special Services Requests” indicating
that FWB processes first 195 characters. Also CARGO-IMP character representation
need to be changed to t[…195]. The new field “Rec. length”, will have the value 195
characters.
60. Other Service Information
61. The CXMLTF reviewed the “Other Service Information” data element in FWB and
XFWB messages. It was noted that FWB supports 195 characters in this elements.
62. It was decided that a note will be included in XFWB that FWB supports 195
characters in Special Services Request.
63. Action item: Add a note in XFWB specification “Other Service Information”
indicating that FWB processes first 195 characters. Also CARGO-IMP character
representation needs to be changed to t[…195]. The new field “Rec. length”, will
have the value 195 characters.
64. OCI
65. The CXMLTF noted that FWB and XFWB are aligned for this data element.
66. Product Name
67. The Product Name is additional optional field in the XFWB message and doesn’t exist
in FWB message. Parties wishing to support this field should upgrade their Cargo
Management and Messaging Systems.
68. The CXMLTF noted that FWB is limited and using data elements: Special Services
Request, Also Notify, Other Shipment Information and Custom Origin all together
could contain maximum 216 characters.
www.iata.org
69. The CXMLTF decided that same limitation should be highlighted in the XFWB
message to make the users aware of this limitation.
70. Action: A note should be added in the XFWB that FWB could only process max of 216
characters from the combination of Special Services Request, Also Notify, Other
Shipment Information and Custom Origin.
71. Box 22I Nature and Quantity of Goods (including Dimensions or Volume)
72. The Box 22I “Nature and Quantity of Goods (including Dimensions or Volume)” is
comprised of eight information sets i.e. Items Description, SLAC, Dimensions/NDA,
Pieces, Volume, ULD Numbers and details, HCC and Country of Origin of Goods.
73. Since the Box 22I is part of the rating line, the CXMLTF noted that FWB supports only
one rating that is face value of the Air Waybill however; XFWB supports multiple
ratings i.e. face, actual and published.
74. The FWB rating lines are limited to max 12 occurrences where the 12th line is the
total of 11 lines.
75. The CXMLTF recommends adding a note in the XFWB specification in the rating line
to highlight that FWB supports single rating with maximum 12 rate lines.
76. Action Item: A note will be added in the Cargo-XML Rating line to make the users
aware that XFWB support multiple ratings that include Face, Actual and Published
however FWB supports only the Face value rating.
77. Action Item: A note will be added in the XFWB specification in manual and toolkitRating line that FWB only supports max 12 rating line.
78. The CXMLTF recommends that XFWB Items Description, SLAC, Dimensions/NDA,
Pieces, Volume, ULD Numbers, HCC and Country of Origin of Goods fields need to be
compliant with FWB Specification section 12 in terms of data length and
occurrences. Please refer to CARGO-IMP Manual 32 edition or above for details.
79. The CXMLTF noted that other than the 5 boxes described above, the remaining 71
boxes are either values for Charges Amount or Code List.
80. The CXMLTF recommends that for a smooth conversion of XFWB to FWB, the values
fields should have format n[...12]p i.e. the value can be comprise of max 12 numeric
include a floating decimal point
81. Action Item: IATA Secretariat will set the new “Rec. Length” field value to n[…12[p
for all the numeric values.
82. The CXMLTF noted some exceptions in the value/charges fields when converting
XFWB to FWB. Following charges/value fields in FWB are not using format n[…12] .
i.
ii.
iii.
iv.
RateOrCharge format is n[…8]p
insurance amount format is n[…11]p
Exchange Rate format is n[…11]p
Discount format is n[…8]p
www.iata.org
83. The CXMLTF recommends that applicable Weight format should have format n[…7]p
and Unit of measurement will be Kilos(K) and Pounds(L).
84. The CXMLTF recommends that applicable Volume format should have format n[…9]p
and Unit of measurement will be CC, CF, CI or MC.
85. The CXMLTF reviewed that Cargo-XML message semantics may differ from the
Cargo-IMP messages and Cargo-XML messages provide additional functionalities e.g.
XGRQ message could be used to request a Flight Manifest (XFFM).
86. The CXMLTF noted that unlike CARGO-IMP messages, One Cargo-XML Message need
not to be split.
87. The CXMLTF will advise the next messages/documents to work on.
www.iata.org