Conversion Guidelines - IATA

1 Conversion Guidelines between Cargo-XML and CARGO-IMP Developed by: iata Cargo-XML Task Force (CXMLTF) Date: 7th May 2014 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.

2 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 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.

3 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 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.

4 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 XFWB FFM XFFM FZB XFZB FHL (type-II) Contains shipper and consignee XFZB FHL (type-I) Checklist XFHL FMA XFNM FNA XFNM FFR XFFR FFA XFFR CSN XCSN FSU XFSU FSA XFSU FBL XFBL FBR XGRQ FSR XGRQ FWR XGRQ FZA XGRQ FZC XGRQ STR XGRQ 11.

5 The CXMLTF noted that CARGO-IMP fields data types are not replicated in Cargo-XML NVC is char(3) in CARGO-IMP however, its equivalent Cargo-XML field is Boolean ( NoValueForCustoms = true). It is therefore recommended that Conversion solution resolves this mismatch. 12. Date format used in CARGO-IMP messages is DDMMM ( 25 APR) however Cargo-XML dates follow the ISO 8601:2004 ( :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 Cargo-XML (not enough information for Cargo-XML to fill the mandatory fields).

6 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.

7 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.

8 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 charges, rates etc. that couldn t result in data length issue. 27. Complete Analysis sheet is attached. Data Length and Type 28. The five boxes that could result into potential data length issues are: A.

9 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) 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 CARGO-IMP data length, a Note will be added in the Cargo-XML specification to highlight the difference.

10 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 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.