Conversion Guidelines between Cargo-XML and CARGO-IMP

Transcription

1 Conversion Guidelines between Cargo-XML and CARGO-IMP Developed by: IATA Cargo-XML Task Force (CXMLTF) Date: 7 th May 2014

2 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

3 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 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) XFZB Contains shipper and consignee FHL (type-i) XFHL Checklist FMA XFNM FNA XFNM FFR XFFR FFA XFFR CSN XCSN FSU XFSU FSA XFSU FBL XFBL FBR FSR FWR FZA FZC STR

4 11. The CXMLTF noted that CARGO-IMP fields data types are not replicated in Cargo- XML 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 Cargo- XML 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 Cargo- XML (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.

5 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)

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

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

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

9 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 12 th 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 toolkit- Rating 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. RateOrCharge format is n[ 8]p ii. insurance amount format is n[ 11]p iii. Exchange Rate format is n[ 11]p iv. Discount format is n[ 8]p

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