CSV Ocean Transport Schedule From INTTRA To Customers

User Guide Version 1.0

Table of Contents
I. II. III.
A. B. C.

BUSINESS CONTEXT ...................................................................................................4 AUDIENCE ....................................................................................................................4 OVERVIEW: OCEAN SCHEDULES ..............................................................................4

Service Schedules .................................................................................................................................... 4 Website ..................................................................................................................................................... 4 Data Feed and Web Services ................................................................................................................... 5

IV.
A. B. C. D.

MESSAGE PROCESSING ............................................................................................6

Message Content ...................................................................................................................................... 6 Message Flow ........................................................................................................................................... 7 Data Supplemented by INTTRA................................................................................................................ 7 Exceptions ................................................................................................................................................. 7

V.
A. B. C.

STANDARDS CODE LISTS AND MASTER DATA CATALOGUES ............................9

Location Code ........................................................................................................................................... 9 Lloyds Code .............................................................................................................................................. 9 Party Code ................................................................................................................................................ 9

VI.
A. B. C. D. E. F. A. B. A. B.

SCHEDULES USAGE SUMMARY ..............................................................................10

Location Qualification .............................................................................................................................. 10 Schedule ID ............................................................................................................................................. 10 Schedule Booking Relationship .............................................................................................................. 10 Data Feed Customization ........................................................................................................................ 11 Message Function Type: Reissue or Delta Schedules ........................................................................... 11 Delta Action Indicators ............................................................................................................................ 11 Character Set Support ............................................................................................................................ 12 Date Format Conventions ....................................................................................................................... 12 Message Structure .................................................................................................................................. 13 Message Specification ............................................................................................................................ 13

VII. GENERAL DATA FORMAT CONVENTIONS .............................................................12 VIII. CSV MESSAGE SPECIFICATION ..............................................................................13 IX.
A. B. C. D. E. F.

APPENDIX 1 SCHEDULES USE CASES ................................................................16

Direct Services Main Haul Vessel Loads & Discharges ...................................................................... 16 Indirect Services Transshipments ........................................................................................................ 17 Indirect Services Feeders .................................................................................................................... 17 Indirect Services Inland Locations ....................................................................................................... 17 Full Reissue Schedules ........................................................................................................................... 18 Delta Schedules ...................................................................................................................................... 18

X. XI.
A. B. C. D. E. F. G. A. B. C. D. E.

APPENDIX 2 SCHEDULES DATA FEED CUSTOMIZATION ..................................20 APPENDIX 3 DELTA SCHEDULES .........................................................................21
Schedules Snapshots ............................................................................................................................. 21 Schedules Comparison ........................................................................................................................... 21 Delta Feed Composition .......................................................................................................................... 22 Use Case 1: New Schedules .................................................................................................................. 22 Use Case 2: Unchanged Schedules ....................................................................................................... 23 Use Case 3: Updated Schedules ............................................................................................................ 23 Use Case 4: Not Present Schedules ...................................................................................................... 23 Duplicate Schedules ............................................................................................................................... 25 Duplicate Schedules except Departure Date .......................................................................................... 25 Duplicate Schedules except Arrival Date ................................................................................................ 25 Duplicate Schedules except Voyage Number......................................................................................... 26 Schedules with Transit Time Greater than 90 Days ............................................................................... 26

XII. APPENDIX 5 SCHEDULES BUSINESS RULES OVERVIEW .................................25

F. G.

Schedules with Identical Origin and Destination ..................................................................................... 26 Ambiguous Schedules ............................................................................................................................ 26

I.

Business Context
This Implementation Guide describes the CSV message implemented by INTTRA to send schedules to customers.

II.

Audience
This Implementation Guide is intended for business and technical personnel engaged in establishing an electronic connection with INTTRA for the purpose of receiving schedules in a CSV format. The following sections provide detailed information regarding General Conventions, Message Processing, Message Specifications and Use Cases to facilitate effective use of the CSV message.

III.

Overview: Ocean Schedules

INTTRA receives schedules from multiple ocean carriers via EDIFACT, X12, and XML messages. INTTRA integrates schedules from different carriers and makes them available on Ocean Schedules website including several white label sites and also makes them available for customers to receive via the Data Feed. This document describes the functionality of the Data Feed product. A. Service Schedules INTTRA creates Service Schedules for each combination of Origin and Destination locations on the same Vessel and Voyage in which the Departure Date at the Origin is earlier than the Arrival Date at the Destination. Service Schedule shows that a carrier provides service from an Origin location to a Destination location in any given time frame. A Service Schedule comprises of Schedules ID (Unique ID assigned by INTTRA), Carrier, Vessel Name, Voyage Number, Origin, Departure Date, Destination, & Arrival Date. Origin may be a port or an inland location at which the carrier accepts the cargo and Destination may be a port or an inland location at which the carrier delivers the cargo. If a service involves multiple legs, then the Service Schedule does not show all legs for the service. Either the first Main Haul Vessel/Voyage or the Vessel/Voyage used on the Booking is used for the service. INTTRA displays Service Schedules on the website and also sends these in the Data Feed to Customers. B. Website Ocean Schedules (www.oceanschedules.com) is a website aimed to enable shippers, freight forwarders and logistics providers to search ocean schedules to facilitate bookings at INTTRA. Schedules can also be downloaded from the website. Ocean Schedules provides the following types of searches: 1. Location Search 2. Vessel Search Location Search allows users to obtain service schedules from specified Origin to Destination within a given date range. It provides a list of carriers with service between the selected Origin and Destination locations, providing Dates and Transit Times associated with the service. Ocean Schedules does not show all the legs involved in a service from Origin to Destination, including Pre Carriage, Main Carriage Transshipments and On Carriage. By convention, either the first Main Haul Vessel/Voyage involved in the service or the Vessel/Voyage used on the Booking is displayed for the service. Vessel Search allows users to obtain a list of ports directly served by a particular Vessel within a date range. Information like Ports of Call, Arrival Date, and Departure Date are available on the site.

Version 1.0 Copyright 2012 INTTRA

Page 4 of 26 July 20, 2012

Data Access. Schedule data from the website is available for download provided that users register with the site. C. Data Feed and Web Services INTTRA sends Service Schedules to shippers, freight forwarders, alliance partners, and other portals via the following methods: EDIFACT (IFTSAI), XML, CSV and Web Services. Data Access. Schedules data is available to customers provided that they subscribe to OS Data Feed service. Note that all past and present schedules sent by carriers are displayed on Ocean Schedules website, but customers have the option to receive a subset of schedules present at INTTRA by applying certain constraints on their own schedules data feed. See Appendix 2 Schedules Data Feed Customization for these constraint details.

Version 1.0 Copyright 2012 INTTRA

Page 5 of 26 July 20, 2012

IV.

Message Processing
A. Message Content INTTRA CSV message set contains schedules information provided by carriers and integrated by INTTRA. Identified below are the key data fields in the Schedules Data Feed. Additional field information is described in the Message Specification section. # 1 2 3 4 5 6 7 8 9 Field Name Carrier ID Vessel Name Lloyds Code Valid Lloyds Code Voyage Number Service Name Schedule ID Schedule Status Origin Location Type Description Carrier providing the schedule expressed as either a Carrier SCAC code or customer-assigned alias. Vessel Name Lloyds Code Indicates if the Lloyds Code is Valid (VD) or Invalid (IV). Reference number assigned by the carrier to a voyage for a particular vessel. Carrier-provided service description INTTRA Unique Schedule Identification. Used as primary key identifier for a schedule. Identifies the status of schedule as either one of: New (C), Updated (U) or Deleted (D). Location type of the origin,either one of Place of Receipt (PLOR) or Port of Load (POL) UN Location code of the origin Departure Date at the Place of Receipt or Port of Load Indicates if departure date is estimated (ESTM) or actual (ACTL) Location type of the destination, either one of: Place of Delivery (PLOD) or Port of Discharge (POD) Arrival Date at the Port of Discharge or Place of Delivery Indicates if arrival date is estimated (ESTM) or actual (ACTL)

10 Origin UN Location Code 11 Departure Date 12 Departure Date Type 13 Destination Location Type

14 Destination UN Location Code UN Location code of the destination 15 Arrival Date 16 Arrival Date Type

Version 1.0 Copyright 2012 INTTRA

Page 6 of 26 July 20, 2012

B. Message Flow

1.

Carriers send schedules to INTTRA per INTTRA Message Specification via communication methods described in the INTTRA Connectivity Guide. INTTRA validates carrier schedules, creates Service Schedules from carrier data and cleanse the data for invalid Service Schedules. INTTRA displays these schedules on OceanSchedules.com website including several White Label sites. INTTRA sends these schedules to subscribed OS Data Feed customers via EDIFACT, XML, CSV and Web Services as described in the INTTRA Connectivity Guide.

2.

3. 4.

C. Data Supplemented by INTTRA INTTRA supplements the following information in the message: # Field Name Processing 1 2 Schedules ID Unique ID assigned for every Service Schedule transmitted via the Data Feed. See Schedules ID for details.

Lloyds Code INTTRA validates Lloyds Code provided by the carrier via the algorithm Valid/Invalid Indicator described in the Lloyds Code section. It assigns a code to indicate that a Lloyds Code is valid or not. INTTRA only determines the validity of the Lloyds Code per abovementioned algorithm but does not verify that Lloyds Code is the actual Lloyds Code assigned to the vessel by IHS Fairplay.

Vessel Name

INTTRA defaults the Vessel Name value to TO BE DECIDED if this is not provided by the carrier.

D. Exceptions INTTRA relays schedules to customers with few exceptions noted in this section. INTTRA does not send the following information: 1. Invalid/Incorrect Schedules: There is a significant variation in the schedules information sent by carriers to INTTRA. Diverse schedules organization by carriers and subsequent creation of Service Schedules by INTTRA results in the creation of the following: o Duplicate schedules
Page 7 of 26 July 20, 2012

Version 1.0 Copyright 2012 INTTRA

o o o o o

Duplicate schedules with arrival and departure date ambiguities Duplicate schedules except voyage number Schedules with transit time greater than 90 days Schedules with identical origin & destination Ambiguous schedules

INTTRA has implemented Schedules Business Rules to mitigate these issues to ensure good data quality of schedules from INTTRA. See Appendix 5 Schedules Business Rules Overview for details. 2. Location Names: Some carriers convey the actual port names and terminal names in the location name field. Currently, INTTRA is unable to process this information and pass on to customers. INTTRA only sends UN Location Codes in the schedules to customers. ISO Country code of Ship's Registry: INTTRA does not support this information from its carriers.. Conveyance Reference Number: This is a unique reference number provided by carriers to manage their schedules transmitted to INTTRA.

3. 4.

Version 1.0 Copyright 2012 INTTRA

Page 8 of 26 July 20, 2012

V.

Standards Code Lists and Master Data Catalogues

A. Location Code Definition. UN Location Code, maintained by UNECE, identifies the worldwide trade and transport locations. INTTRA uses standard UN Location Codes for locations in Ocean Schedules. Processing. INTTRA fails carrier schedules with invalid location codes as per the INTTRA geography master database. INTTRA does not make any attempt to resolve location names to UN Location codes or to reconcile coded information with information supplied in the location name. INTTRA only sends UN Location Codes in the schedules data feed to customers. INTTRA does not send location names in the data feed to customers. B. Lloyds Code Definition. Lloyds Code or IMO (International Maritime Organization) Number identifies a commercial passenger or cargo ship. This number is assigned by IHS Fairplay. This number is comprised of letters IMO and seven decimal digits, which are identical with the ship's Lloyd's Register number (LRF). This number remains the same throughout the ship's lifetime, regardless of changes in the ship's name, structure or ownership. Once given, a number is never reused by assigning it to another ship. Availability. INTTRA accepts schedules from carriers with or without Lloyds Code. Algorithm. INTTRA determines validity of Lloyds Code using the following logic: 1. The digits to be checked are weighted from left to right by 7, 6, 5, 4, 3, and 2. 2. Products are added up. 3. The sum is divided by 10. The remainder (the last digit of the sum) is the check digit. Example: 9074729 (Pacific Frontier, Hong Kong) 9 0 7 4 7 2 9 7 6 5 4 3 2 63 0 35 16 21 4 = 139 ? 9 In this example, the remainder 9 is same as the last digit and hence, the Lloyds Code is valid. Valid Indicator. Valid Lloyds code is indicated as VD while Invalid Lloyds Code is indicated as IV. Exception. INTTRA only determines the validity of the Lloyds Code per above-mentioned algorithm but does not verify that Lloyds Code is the actual Lloyds Code assigned to the vessel by IHS Fairplay. C. Party Code INTTRA sends customers code or alias for carrier if the customer configured an alias at INTTRA. If the customers code or alias is not configured, INTTRA sends the SCAC maintained by INTTRA for the carrier.

Version 1.0 Copyright 2012 INTTRA

Page 9 of 26 July 20, 2012

VI.

Schedules Usage Summary

A. Location Qualification INTTRA recommends that carriers qualify Origin and Destination locations in schedules to allow customers to distinguish between Direct and Indirect services. See Appendix 1 Schedules Use Cases section for details on Direct and Indirect services. 1. Place of Acceptance/Receipt locations at which cargo is accepted for a given vessel/voyage named in the TDT but at which the vessel does not actually call. These locations can be inland locations or even be ports at which the named vessel does not call to load cargo. Cargo is usually transported via Pre-Carriage leg(s) (Truck, Rail, Feeder, or Barge) to the port where the cargo is loaded on the named vessel. Port of Load locations at which vessel/voyage named in the Transport Plan directly calls to load cargo. Port of Discharge locations at which vessel/voyage named in the Transport Plan directly calls to discharge cargo. Place of Delivery locations at which cargo is delivered but at which the vessel/voyage does not actually call. Cargo delivery might be transshipped through a connecting service (another Main Haul Vessel) or by feeder, barge, rail, or truck.

2. 3.

4.

INTTRA processes schedules data even if carriers incorrectly qualify locations as origin and destination. INTTRA sends location qualifiers provided by carriers to customers and attempts to correct location qualifiers in case carriers do not adhere to the above recommendation. For example, if carriers qualify locations indirectly served (via feeders, barges, rail, truck, etc) by the vessel as Load & Discharge Ports, then INTTRA includes those locations as directly called ports in the vessel sailing schedule despite failure of those vessels to call at those locations. See Appendix 1 Schedules Use Cases section for Direct & Indirect service examples. B. Schedule ID Definition. Every Service Schedule is assigned a unique Identifier referred to as Schedule ID by INTTRA. INTTRA uses Carrier, Vessel Name, Voyage Number, Origin, and Destination information of a schedule to determine its ID as these attributes uniquely identify a schedule. INTTRA uses MD5 Hash Algorithm to generate unique ID for schedules. Processing. INTTRA always transmits the same ID for schedules having the same Carrier, Vessel Name, Voyage Number, Origin, and Destination. Since INTTRA cannot distinguish when carriers are updating a previously transmitted schedule versus when carriers are reusing the voyage number for a different schedule, INTTRA assigns the same ID to these schedules in both cases. Note: Carriers have conveyed to INTTRA that their intent is not to reuse voyage numbers especially for the main haul vessels for different schedules within a certain time frame. INTTRA has detected some cases of voyage number being reused within a week in the case of Feeder vessels. INTTRA closely monitors the Voyage Number Reuse cases to resolve this problem. Shoud this issue arise, it is recommended that INTTRA is notified. C. Schedule Booking Relationship Customers use schedules information to create bookings. Some customers also use schedules for filing Manifests. 1. Use Case 1: Lifetime Schedules-Booking Relationship

Version 1.0 Copyright 2012 INTTRA

Page 10 of 26 July 20, 2012

In this case, a schedule remains linked to a booking during the lifetime of that booking. So any updates made to schedules automatically update related bookings. Customers are expected to use unique Schedules ID and Action Indicators indicating schedules status to process schedules. 2. Use Case 2: Transient Schedules-Booking Relationship In this case, schedule and booking relationship ceases to exist after the booking is created. So any changes in schedules do not update corresponding bookings. Customers expect carriers to update the transportation details in the booking via the booking confirmation message. D. Data Feed Customization Customers can customize the schedules Data Feed received from INTTRA. Customers can choose to receive schedules with constraints on departure & arrival dates, carriers, etc. In addition, customers can choose to receive either Full Reissue or Delta schedules from INTTRA. See Appendix 2 Schedules Customization and Appendix 3 Delta Schedules for details. E. Message Function Type: Reissue or Delta Schedules Message Type Reissue Definition A message identified as REISSUE indicates that the full schedule data is sent. INTTRA Processing INTTRA sends a full reissue of all carrier schedules per customers Data Feed customization when customers choose to receive full reissued schedules. INTTRA recommends customers receiving full reissue to replace all their existing schedules with the latest full reissued schedules sent by INTTRA. Delta A message identified as DELTA indicates that customers prefer to receive schedules in full the first time, then subsequently, receive schedule additions, changes and deletions in the data feed. INTTRA sends schedules that have been added, changed or deleted provided that customers configured this option in their outbound data feed preference. Additionally, INTTRA conveys the status of each delta schedule in Schedule Status field (also known as Delta Action Indicator) as New, Updated or Not Present. INTTRA determines these statuses, instead of the originating carrier; it indicates the status of the schedule relative to its previous status. See Appendix 3 Delta Schedules for details. F. Delta Action Indicators When a schedules message function is DELTA, INTTRA further determines the status of the delta schedule relative to its previous status. INTTRA determines these action indicators; carriers do not not explicitly declare them. INTTRA sends the following action indicators: Delta Action Indicator C (New) U (Updated)
Version 1.0 Copyright 2012 INTTRA

Description

indicates that the schedule has been added in the current snapshot when compared to the previous snapshot. indicates that the schedule is present in both the snapshots and there is a change in
Page 11 of 26 July 20, 2012

Delta Action Indicator

Description either Departure Date or Arrival Date or both

D (Deleted)

indicates that the schedule was present in the previous snapshot, but missing or removed from the current snapshot.

VII. General Data Format Conventions

A. Character Set Support INTTRA supports the UNOC UN/ECE level C character set, as defined in ISO-8859-1character set (Hex 0x01 to 0xFF). INTTRA may delete the following subset of control characters from the inbound message to allow accurate processing at INTTRA and at customer systems: 1. Hex 0x00 2. Hex 0x01 through Hex 0x1F, excluding Hex 0x0A (line feed) and 0x0D (carriage return). 3. Hex 0x7F 4. Hex 0x80 through Hex 0x9F INTTRA does not include above-mentioned characters in the outbound message. B. Date Format Conventions INTTRAs implementation includes date fields using the following format: - Date accompanied by time, in the format CCYYMMDDHH:MM The time component is in the 24 hour format. The Departure and Arrival date/time values are considered to be local at the point of activity. Message date/time values are expressed in GMT timezone.

Version 1.0 Copyright 2012 INTTRA

Page 12 of 26 July 20, 2012

VIII. CSV Message Specification

A. Message Structure The CSV message is comprised of a header and detail. The header contains information about the sender, receiver, message version and message generation date. It also contains the total number of schedules. The detail contains the schedules for every vessel of every carrier. The CSV fields are generated in the order identified in the Message Specification section. B. Message Specification Legend: M/O/C Indicates if field is mandatory, optional or conditional. Mandatory indicates that field always exist in the file; Optional indicates that field may be null in the file. Conditional indicates that presence of field is dependent on another field or condition. AN Alpha numeric N Number Date/Time Format: All date fields are expressed in this format: CCYYMMDDHH:MM. The time is also expressed in 24-hour format. Message date/time is in GMT while the departure and arrival date/time are considered to be local at the point of activity. Header Fields: # Field Name 1 Sender ID

Description Sender identification: Trading Partners sender ID Value is always INTTRA

M/O/C M

Data Type AN(35)

2 3

Receiver ID Message Version

Receiver identification: Trading Partners EDI ID Version of the CSV message structure Value: 1.0

M M

AN(35) AN(3)

4 5 6 7

Message Function Indicates the type of the message, either one of: REISSUE or DELTA Type Message ID Message Date Total Number of Records Unique reference ID assigned to the message by the sender Date and time of file creation expressed in GMT timezone Total number of transactions (schedule data) being sent to the receiver

M M M M

AN(10) AN(35) AN(13) N(35)

Detail Fields: # Field Name 1 Carrier ID

Description Carrier providing the schedule expressed as either a Carrier SCAC code or customer-assigned alias. If the customer has an alias for a carrier stored at INTTRA then alias will be sent in the message; otherwise, the INTTRA-maintained SCAC code will be sent.

Supplied Values

M/O/C M

Data Type AN(17)

Version 1.0 Copyright 2012 INTTRA

Page 13 of 26 July 20, 2012

# 2 3 4

Field Name Vessel Name Lloyds Code Valid Lloyds Code Voyage Number Vessel Name. Lloyds Code.

Description

Supplied Values

M/O/C M O

Data Type AN(35) AN(9) AN(3)

Indicates if the Lloyds Code is Valid (VD) or Invalid (IV). Reference number assigned by the carrier to a voyage for a particular vessel. When carrier provides two or more identical schedules except voyage number, INTTRA combines these schedules into a single schedule and comma-delimits the voyage numbers. For example, given the following two schedules: Carrier: ABC Vessel: ALABAMA Voyage Number: 76N Carrier: ABC Vessel: ALABAMA Voyage Number: 76S These two schedules will be combined as follows: Carrier: ABC Vessel: ALABAMA Voyage Number: 76N, 76S

Values are: IV VD

AN(255)

6 7 8

Service Name Schedule ID Schedule Status

Carrier-provided service description INTTRA Unique Schedule Identification. Used as primary key identifier for a schedule. Identifies the status of schedule as either one of: New (C), Updated (U) or Deleted (D). Values are: C U D Values are: PLOR POL

O M C

AN(60) AN(35) AN(3)

Origin Location Type

Location type of the origin,either one of Place of Receipt (PLOR) or Port of Load (POL) UN Location code of the origin Departure Date at the Place of Receipt or Port of Load Indicates if departure date is estimated (ESTM) or actual (ACTL)

AN(5)

10 Origin UN Location Code 11 Departure Date 12 Departure Date Type 13 Destination Location Type 14 Destination UN Location Code

M M Values are: ESTM ACTL M

AN(25) AN(13) AN(5)

Location type of the destination, either one of: Place Values are: of Delivery (PLOD) or Port of Discharge (POD) POD PLOD UN Location code of the destination

AN(5)

AN(25)

Version 1.0 Copyright 2012 INTTRA

Page 14 of 26 July 20, 2012

Field Name

Description Arrival Date at the Port of Discharge or Place of Delivery

Supplied Values

M/O/C M

Data Type AN(13) AN(5)

15 Arrival Date

16 Arrival Date Type Indicates if arrival date is estimated (ESTM) or actual (ACTL)

Values are: ESTM ACTL

C. Message Sample Illustrated below is a basic example of a CSV:

"Sender_ID","Receiver_ID","Message_Version","Message_Function_Type","Message_ID","Message_Date","Tota l_Number_of_Records" "INTTRA","CUSTOMER COMPANY","1.0","REISSUE","365430684","2012061209:15","2" "Carrier_ID","Vessel_Name","Lloyds_Code","Valid_Lloyds_Code","Voyage_Number","Service_Name","Schedule _ID","Schedule_Status","Origin_Location_Type","Origin_UNLocation_Code","Departure_Date","Departure_Da te_Type","Destination_Location_Type","Destination_UNLocation_Code","Arrival_Date","Arrival_Date_Type" "CARRIER_A","JAKARTA EXPRESS","9301794","VD","2111A","EAX","8d8d365a6c3884d123a5cf37db229eeb",,"POL","NLRTM","2012061513:3 0","ESTM","POD","FRLEH","2012061522:30","ESTM" "CARRIER_A","MARE ATLANTICUM","9213272","VD","2214S,2214N","IMX","6faacd614e710b4704983b38561aa023",,"POL","INNSA","201 2061509:30","ESTM","PLOD","INTUT","2012061614:30","ESTM"

This is an illustration of multiple voyage numbers delimited by a comma. This section identifies the header fields. It is comprised of the field labels in the first row followed by the values in the second row.

This section identifies the detail fields. It always begins at row number 3. Third row defines the field labels followed by the values in the fourth row.

Version 1.0 Copyright 2012 INTTRA

Page 15 of 26 July 20, 2012

IX.

Appendix 1 Schedules Use Cases

Note: INTTRA sends carrier-provided location qualifiers to customers. INTTRA does not fail carrier schedules if carriers do not follow INTTRA recommendations to appropriately qualify locations. A. Direct Services Main Haul Vessel Loads & Discharges INTTRA sends direct services from Main Vessel Load Port to Main Vessel Discharge as shown in the example below. Since the main vessel named in the schedule directly calls the origin port to load cargo and destination port to discharge cargo, their location qualifiers should be POL and POD respectively. "SCAC","VESSELNAME","9450375","VD","07E50","WSA","d8de192d557516ea9651aa2d4sse1u",,"POL", "SGSIN","2012050413:15","ES M","POD","CAVAN","2012060200:00","ES M" The Vessel Sailing Schedules shows the VESSEL NAME on voyage 07E50 calls at Singapore (SGSIN), Shanghai (CNSHA), Busan (KRPUS), Vancouver (CAVAN) & Seattle (USSEA). INTTRA creates Service Schedules for all ports called by the vessel from carriers Vessel Sailing Schedules provided the Departure Date at Origin is earlier than the Arrival Date at Destination. INTTRA sends the following service schedules to customers: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Singapore (SGSIN) to Shanghai (CNSHA) Singapore (SGSIN) to Busan (KRPUS) Singapore (SGSIN) to Vancouver (CAVAN) Singapore (SGSIN) to Seattle (USSEA) Shanghai (CNSHA) to Busan (KRPUS) Shanghai (CNSHA) to Vancouver (CAVAN) Shanghai (CNSHA) to Seattle (USSEA) Busan (KRPUS) to Vancouver (CAVAN) Busan (KRPUS) to Seattle (USSEA) Vancouver (CAVAN) to Seattle (USSEA)

"SCAC","VESSELNAME","9450375","VD","07E50","ESA","d8de192d557516ea9651aa2d6!!e7"",,"#$L", "SGSIN","2012060413:15","ES M","#$D","CNSHA","2012061507:45","ES M" "SCAC","VESSELNAME","9450375","VD","07E50","ESA","d8de192d557516ea9651aa2d6!!e8"",,"#$L", "SGSIN","2012060413:15","ES M","#$D"," KRPUS","2012062211:00","ES M" "SCAC","VESSELNAME","9450375","VD","07E50","ESA","d8de192d557516ea9651aa2d6!!e7"",,"#$L", "SGSIN","2012050413:15","ES M","#$D","CAVAN","2012060201:00","ES M" "SCAC","VESSELNAME","9450375","VD","07E50","ESA","d8de192%557516ea9651aa9d6!!e9&",,"#$L", "SGSIN","2012050413:15","ES M","#$D","USSEA","2012060416:30","ES M" "SCAC","VESSELNAME","9450375","VD","07E50","ESA","'2(u815"452616d)4211*+2s2ee,5)",,"#$L", "CNSHA","2012061621:00","ES M","#$D","KRPUS","2012062211:00","ES M" "SCAC","VESSELNAME","9450375","VD","07E50","ESA","'2(u815&452618du3211*+2s2ee,6)",,"#$L", "CNSHA","2012051621:00","ES M","#$D","CAVAN","2012060201:00","ES M" "SCAC","VESSELNAME","9450375","VD","07E50","ESA","'2(u815&452618du3211*+2s2ee,7)",,"#$L", "CNSHA","2012051621:00","ES M","#$D","USSEA","2012060416:30","ES M" "SCAC","VESSELNAME","9450375","VD","07E50","ESA","-6u.200e232816/e2817'08+112.3d",,"#$L", "KRPUS","2012052301:00","ES M","#$D","CAVAN","2012060201:00","ES M"
Version 1.0 Copyright 2012 INTTRA Page 16 of 26 July 20, 2012

"SCAC","VESSELNAME","9450375","VD","07E50","ESA","-6u.200e232816/e2817'08+112.3d ",,"#$L", "KRPUS","2012052301:00","ES M","#$D","USSEA","2012060416:30","ES M" "SCAC","VESSELNAME","9450375","VD","07E50","ESA","!3d36671889016a*324144801'5u3, ",,"#$L", "CAVAN","2012060301:00","ES M","#$D","USSEA","2012060416:30","ES M"

B. Indirect Services Transshipments Indirect Service via Transshipment(s) is a service between origin and destination involving more than one leg in which containers are delivered to their final destination via one or more connecting services. INTTRA recommends to carriers to provide the vessel to be listed on the Booking as the vessel for service involving Transshipments. In case the vessel on the booking is the 1st main haul vessel, then the initial port where the cargo is loaded should be qualified as Load Port (POL) and the final Discharge Port where the cargo will be delivered from a connecting service vessel should be qualified as Place of Delivery (PLOD). In the example below, two sets of cargo are loaded on the 1st main haul vessel on Aug 5, 2011 at Rotterdam. 1st cargo is transshipped at Singapore on a different connecting service to be discharged at Sydney on Sep 18, 2011 and the 2nd cargo is also transshipped at Singapore to be discharged at Auckland on Sep 17, 2011. In the example below, if Sydney and Auckland are qualified as Port of Discharge (POD), then it would seem that the 1st Main Haul Vessel discharges at Auckland on Sep 17, 2011 and Sydney on Sep 18, 2011, which is not correct as different vessels discharge cargo at these ports and the 1st Main Haul Vessel does not call these locations. "SCAC","VESSELNAME","9450375","VD","07E50","WSA","d8de192d557516ea9651aa2d4sse1u",,"POL", "NL6 M","2012050513:15","ES M"," PLOD ","A7S8D","2012061801:00","ES M" "SCAC","VESSELNAME","9450375","VD","07E50","WSA","d8de192d557516ea9651aa2d4sse1u",,"POL", "NL6 M","2012050513:15","ES M"," PLOD ","N9A:L","2012061703:00","ES M" C. Indirect Services Feeders Indirect Service is a service between origin and destination involving more than one transportation leg. Schedules involving one or more named/unnamed feeder or barge services fall under the category of indirect services. The Helsinki, Finland to Chittagong, Bangladesh service example below demonstrates the cargo is transported via Feeder Vessel to the nearest port (Bremerhaven) to be loaded on the Main Vessel and then the cargo is transported to Chittagong via another Feeder vessel from the port (Colombo) at which the Main Vessel discharges cargo. Since INTTRA service schedule does not show legs, there is no mention of Bremerhaven and Colombo in the service schedule and Helsinki and Chittagong are qualified as Place of Acceptance (PLOR) and Place of Delivery (PLOD) respectively.

"SCAC","VESSELNAME","9450375","VD","07E50","WSA","d8de192d557516ea9651aa2d4sse1u ",," PLOR ", ";I<EL","2012052313:15","ES M","PLOD","=DCG#","2012063001:00","ES M" D. Indirect Services Inland Locations Indirect Service using multiple transportation modes is a service between origin and destination involving more than one leg with multiple modes of transportation. Indirect service between two inland locations will be sent by INTTRA as shown in the example below. Since the main vessel named in the transaction does not call the inland locations at which the cargo is accepted or delivered by the carrier, those locations should be qualified as the Place of Receipt/Acceptance (PLOR) and Place of Delivery (PLOD). In the Detroit to Johannesburg service example below the cargo is transported via Rail to the nearest port (Norfolk) to be loaded on the Main Vessel and then the
Version 1.0 Copyright 2012 INTTRA Page 17 of 26 July 20, 2012

cargo is transported to the final delivery inland location via truck from the port (Durban) at which the Main Vessel discharges cargo. "SCAC","VESSELNAME","9450375","VD","07E50","WSA","d8de192d557516ea9651aa2d4sse1u",,"PLOR", "7SDE ","2012052813:15","ES M","PLOD","9A>N=","2012060101:00","ES M" E. Full Reissue Schedules INTTRA sends full reissue of schedules as shown in the sample below. The Message Function Type REISSUE indicates that all schedules within the transaction have been reissued by INTTRA per Customers Data Feed customizations. See Appendix 2 Schedules Customization for details. "IN 6A"," # EDI ID","1?0","REISSUE","2012052409:30","328" "SCAC"," VESSEL NAME A","9317971","IV","101N","WSA","d8de192d557516ea9651aa2d4sse1u",,"#$L", "SA>ED","2012051004:10","AC L"," #$D ","># 8$","2012062600:00","AC L" "SCAC"," VESSEL NAME A","9317971","IV","101N","WSA",")2de342d557516ea9651aa2d6!!e2s",,"#$L", "SA>ED","2012051004:10","ES M","#L$D ","CN<7A","2012061200:00","ES M" "SCAC"," VESSEL NAME A","9317971","IV","101N","WSA",",552392d557516ea9651aa2d6!!e2)",,"#$L", "SA>ED","2012051004:10","ES M"," #$D ","CNS<A","2012060201:00","ES M" "SCAC"," VESSEL NAME =","8703397","VD","06W23",,"@0*e777u557516ea9631!!2d6-Ae5u",,"#$L", "I G$A","2012061121:00","AC L","#$D","7SSAV","2012062715:00","ES M" "SCAC"," VESSEL NAME =","8703397","VD","06W23",,"d8de192d557516ea9651aa2d4sse1u",,"#$L", " ES=CN ","2012061313:00","ES M","#$D","7SSAV","2012062715:00","ES M" "SCAC"," VESSEL NAME =","8703397","VD","06W23",,"d8de192d557516ea9651aa2d4sse1u",,"#$L", " ES=CN ","2012051313:00","ES M","#$D","7S<$7","2012060712:01","ES M" "SCAC"," VESSEL NAME C","9317975","VD","10E ","ESA","d8de192d557516ea9651aa2d4sse1u",,"#$L", " 7SN8C","2012052804:10","AC L","#$D","IN=$M","2012060815:00","AC L" "SCAC"," VESSEL NAME D",,,"35E",,"d8de192d557516ea9651aa2d6!!e8&",,"#L$6", " 7SDE ","2012052804:10","ES M","#L$D","9A>N=","2012060815:00","ES M" "SCAC"," VESSEL NAME E","9999999","IV","31W ",,"d8de192d557516ea9651aa2d6!!e6A",,"#L$6", " <=::","2012050404:10","ES M","#$D","9A>N=","2012060215:00","ES M" F. Delta Schedules INTTRA sends Delta schedules as shown in the sample below. The Message Function Type DELTA indicates that schedules within the transaction are Delta schedules i.e. schedules that are New, Updated, or Removed/Not Present in INTTRA. See Appendix 3 Delta Schedules for details. "IN 6A"," # EDI ID","1?0","DELTA","2012052409:30","328" "SCAC"," VESSEL NAME A","9317971","IV","101N","WSA","d8de192d557516ea9651aa2d4sse1u","U","#$L", "SA>ED","2012051004:10","AC L","#$D","># 8$","2012062600:00","AC L" "SCAC"," VESSEL NAME A","9317971","IV","101N","WSA",")2de342d557516ea9651aa2d6!!e0s","D","#$L",
Version 1.0 Copyright 2012 INTTRA Page 18 of 26 July 20, 2012

"SA>ED","2012051004:10","ES M","#$D",":6#7S","2012062400:00","ES M" "SCAC"," VESSEL NAME A","9317971","IV","101N","WSA",")2de342d557516ea9651aa2d6!!e2s","C","#$L", "SA>ED","2012051004:10","ES M","#L$D","CN<7A","2012061200:00","ES M" "SCAC","VESSEL NAME A","9317971","IV","101N","WSA",",552392d557516ea9651aa2d6!!e2)","C","#$L", "SA>ED","2012051004:10","ES M","#$D","CNS<A","2012060201:00","ES M" "SCAC"," VESSEL NAME =","8703397","VD","06W23",,"@0*e777u557516ea9631!!2d6-Ae5u","C","#$L", " I G$A ","2012061121:00","AC L","#$D","7SSAV","2012062715:00","ES M" "SCAC"," VESSEL NAME =","8703397","VD","06W23",,"d8de192d557516ea9651aa2d4sse1u","C","#$L", " ES=CN","2012061313:00","ES M","#$D","7SSAV","2012062715:00","ES M" "SCAC"," VESSEL NAME =","8703397","VD","06W23",,"d8de192d557516ea9651aa2d4sse1u","U","#$L", " ES=CN","2012051313:00","ES M","#$D","7S<$7,"2012060712:01","ES M"

Version 1.0 Copyright 2012 INTTRA

Page 19 of 26 July 20, 2012

X.

Appendix 2 Schedules Data Feed Customization

Data Feed customers can customize the schedules received from INTTRA, defined as follows: 1. Carriers Selectivity: Customers can choose to receive schedules from all carriers offering schedules on INTTRA or only a subset of those carriers. Depending upon the carriers schedules volume and the maximum transaction per file preference selected by the customer, INTTRA will send one or more schedules files per carrier. Each INTTRA schedule file will have schedules from only one carrier. Full or Delta Schedules: Customers can choose to receive either Full or Delta schedules. Customers cannot choose to receive Full schedules from some carriers and Delta schedules from other carriers. If customers choose to receive Full or Delta schedules, then INTTRA will send Full or Delta schedules for all carriers. Future Departure Date Range: Full Reissue subscribers can choose to select the future Departure Date Range (2, 4, 6, or 8 weeks) of the Schedules that they receive from INTTRA. By default INTTRA will send schedules with departures within 6 weeks in the future. Note customers receiving Delta Schedules from INTTRA will only receive schedules with departures within 6 weeks in the future. Departures Only in Future: Customers can choose to receive schedules with departures only in the future. If this option is selected, then INTTRA will send schedules with departures only in the future. Arrivals Only in Future: Customers can choose to receive schedules with arrivals only in the future. Carrier Code: Customers can choose to receive their own code for the carrier in the schedules message provided their carrier code is configured as an Alias at INTTRA. Transactions per File: Customers can choose the maximum number of transactions that should be included in a file by INTTRA. Note each transaction can have up to 999 service schedules. This preference helps customers manage the size of schedule files from INTTRA for optimal processing at their end. By default, it will be 100 transactions per file. (Minimum=10, Maximum=100) Compressed files: Customers can choose to receive compressed (*.zip) schedules files from INTTRA. File Naming Convention: Customers can choose to receive CSV file names in the following format: a. TPPrefix_1000651347_20110810100836.csv/zip b. TPPrefix_CSV_20090410215111_102650861_164540251.csv/zip Along with the date time stamp, other numbers in the file name are unique identifiers. TPPrefix is the Trading Partner Prefix configured in INTTRA.

2.

3.

4.

5. 6.

7.

8. 9.

Version 1.0 Copyright 2012 INTTRA

Page 20 of 26 July 20, 2012

XI.

Appendix 3 Delta Schedules

Customers have an option to first process full set of schedules from carriers and then subsequently process daily schedules additions, changes, and deletions. Delta Data Feed from INTTRA includes a small percentage of all schedules in INTTRA as the daily changes are substantially smaller than the full set of schedules. A. Schedules Snapshots INTTRA maintains snapshots of schedules to compute Delta. A schedule snapshot is a copy of carrier schedules successfully processed in INTTRA between 00:00 and 23:59 GMT on any particular day and is intended only for internal Delta processing and not available for external distribution. INTTRA computes Delta daily for carriers who send daily schedules updates and weekly for carriers who send weekly schedules updates to INTTRA. If carriers send daily schedules updates to INTTRA, then schedules snapshots to determine Delta on Current Date (example: Jun 6, 2012) will be as follows: a. b. Previous Snapshot Schedules processed on Current Date minus 2 (example: Jun 4, 2012) with departures within the next 42 days (Jul 15, 2012) Current Snapshot Schedules processed on Current Date minus 1 (example: Jun 5, 2012) with departures within the next 42 days (Jul 16, 2012)

If carriers send weekly schedules updates (example: Aug 5, 2011 and Aug 12, 2011) to INTTRA, then schedules snapshots to determine Delta on Current Date (example: Aug 13, 2011) will be as follows: c. d. Previous Snapshot Schedules processed in the previous week (example: Aug 5, 2011) with departures within the next 42 days (Sep 16, 2011) Current Snapshot Schedules processed in the current week (example: Aug 12, 2011) with departures within the next 42 days (Sep 23, 2011)

Schedules with departures after 6 weeks in future will not be considered for Delta determination and hence not included in the snapshots for comparison. INTTRA computes Delta Schedules by comparing the current and the previous schedules snapshots. Delta schedules are generated after 00:00 GMT daily. Customers receiving Delta schedules from INTTRA must receive daily feed in order to ensure that their schedules are in synch with INTTRA schedules. B. Schedules Comparison Schedules are compared on the basis of Carrier, Vessel Name, Voyage Number, Origin, and Destination. Changes in Departure Date, Arrival Date, or both dates are considered to be changes in schedules. INTTRA will not identify a schedule to be changed if Carrier, Vessel Name, Voyage Number, Origin, Destination, Arrival & Departure Dates are the same, but Lloyds Code or Service Name is changed. The following table summarizes the various use cases related to Delta processing: Use Case # 1 2 3 4 Schedule Present in Previous Snapshot Not Present Present Present Present Schedule Present in Current Snapshot Present Present Present Not Present Change? N/A No Yes N/A Action Indicator in Delta Feed C (Created or New) Not Included in Delta U (Updated) D (Deleted or Not Present)

Version 1.0 Copyright 2012 INTTRA

Page 21 of 26 July 20, 2012

C. Delta Feed Composition Delta Feed from INTTRA will always include schedules with departures within 6 weeks in future. Following customer customizations will be used to determine schedules to be included in the Delta Feed to a customer: 1. 2. 3. Carrier Selectivity Departures Only in Future Arrivals Only in Future

See Appendix 2 Schedules Customization for details. D. Use Case 1: New Schedules INTTRA includes schedules present in the current snapshot, but absent from the previous snapshot as NEW in the Delta Feed. Use Case 1A: It is possible that some schedules identified as NEW were previously sent to the customer as they were present in older snapshots and then later on not present in some of the recent schedules snapshot. Since INTTRA only compares schedules between any two days, INTTRA is unable to detect a schedule that was present in any of the older snapshots but missing from the current snapshot. So INTTRA sends these schedules as NEW. Carrier: Carrier1 Vessel: CAP STEPHENS Delta Date 5-Aug 8-Aug 10-Aug Origin: Rotterdam Voyage #: 17W20 Arrival Date 29-Sep 29-Sep 29-Sep Destination: New York Future Departure Date Range: 6 weeks Carrier/Application Functionality Carrier added the schedule on Aug 4. Included as NEW in Delta on Aug 5. Carrier removed the schedule on Aug 7. Included as NOT PRESENT in Delta on Aug 8. Carrier added the schedule on Aug 9. Included as NEW in Delta on Aug 10.

Previous Current Departure Snapshot Snapshot Date 3-Aug 6-Aug 8-Aug 4-Aug 7-Aug 9-Aug 16-Sep 16-Sep 16-Sep

Customer Processing Recommendation: Customers should use Schedules ID to see if the schedule being added as New already exists in their system. If the ID exists in their system, then the customer should replace the existing schedule with the new schedule transmitted in the current Delta Feed. If the ID does not exist in the customer system, then the customer should save the schedule as a new schedule. Use Case 1B: New schedules get added to the current snapshot every day to be included in the Delta Feed. Carrier: Carrier1 Vessel: CAP STEPHENS Delta Date 5-Aug Origin: Rotterdam Voyage #: 17W20 Arrival Date 3-Oct Destination: New York Future Departure Date Range: 6 weeks Carrier/Application Functionality Carrier added the schedule on Aug 4. Not Included in Delta on Aug 5 as the departure is more than 6 weeks in future Schedule with departure on Sep 20 becomes eligible to be included in the Delta Feed and is present in the current snapshot. Included as NEW in Delta on Aug 9.
Page 22 of 26 July 20, 2012

Previous Current Departure Snapshot Snapshot Date 3-Aug 4-Aug 20-Sep

9-Aug

7-Aug

8-Aug

20-Sep

3-Oct

Version 1.0 Copyright 2012 INTTRA

E. Use Case 2: Unchanged Schedules INTTRA detects that the same schedule is present in both schedules snapshots with same Departure and Arrival Dates. Since there is no change in these schedules, INTTRA will not include these schedules in the Delta Feed to the customer. Carrier: Carrier1 Vessel: CAP STEPHENS Delta Date 5-Aug Origin: Rotterdam Voyage #: 17W20 Arrival Date 29-Sep Destination: New York Future Departure Date Range: 6 weeks Carrier/Application Functionality Schedule present in Aug 3 & 4 snapshots and is unchanged. Not included in Delta on Aug 5.

Previous Current Departure Snapshot Snapshot Date 3-Aug 4-Aug 16-Sep

F. Use Case 3: Updated Schedules INTTRA detects that a schedule is present in both schedules snapshots, but it has different departure or arrival or both departure and arrival. INTTRA will include such schedules in the Delta Feed and the action indicator of these schedules will be UPDATE. Carrier: Carrier1 Vessel: CAP STEPHENS Delta Date 5-Aug 8-Aug Origin: Rotterdam Voyage #: 17W20 Arrival Date 26-Sep 27-Sep Destination: New York Future Departure Date Range: 6 weeks Carrier/Application Functionality Carrier added the schedule on Aug 4. Included as NEW in Delta on Aug 5. Carrier changed arrival date in the schedule on Aug 7. Included as UPDATE in Delta on Aug 8.

Previous Current Departure Snapshot Snapshot Date 3-Aug 6-Aug 4-Aug 7-Aug 13-Sep 13-Sep

Customer Processing Recommendation: Customers should use Schedules ID to verify if the schedule being updated exists in their system. If the ID exists in their system, then the customer should replace the existing schedule with the new schedule transmitted in the latest Delta Feed. If the ID does not exist in their system, then the customer should save updated schedule as a new schedule. G. Use Case 4: Not Present Schedules INTTRA detects that a schedule is present the previous snapshot, but not present in the current snapshot. INTTRA will include these schedules in the Delta Feed with action indicator NOT PRESENT as INTTRA cannot accurately determine why a schedule is present or missing on any given day. Some of the reasons for schedules to be present in the previous snapshot, but missing from the current snapshot are as follows: 1. Schedules Age Out: These are schedules with arrivals in the past. As schedules age out, carriers stop sending them to INTTRA or INTTRA stops sending them out. Schedules Cancellations: Carriers explicitly cancel some schedules due to local weather conditions or due to changes in business arrangements. All carriers do not explicitly convey schedules cancellations to INTTRA and absence of a schedule in a snapshot cannot be assumed as a cancellation. Hence INTTRA is unable to let customers know that a schedule has been cancelled.
Page 23 of 26 July 20, 2012

2.

Version 1.0 Copyright 2012 INTTRA

3.

INTTRA or Carrier Processing Errors: Due to INTTRA or Carrier processing errors, some schedules might be missing on any one day. After the errors are corrected, these schedules are usually available on the next day. Incomplete Schedules Set from Carriers: INTTRA has no way to determine if all carriers have transmitted all their schedules on any given day. So absence of some schedules on any given day might simply imply that the schedules transmission is not complete for that day. Origin: Rotterdam Voyage #: 17W20 Arrival Date 28-Sep 28-Sep Destination: New York Future Departure Date Range: 6 weeks Carrier/Application Functionality Carrier added the schedule on Aug 4. Included as NEW in Delta on Aug 5. Carrier cancelled the schedule on Aug 7. Included as NOT PRESENT in Delta on Aug 8.

4.

Carrier: Carrier1 Vessel: CAP STEPHENS Delta Date 5-Aug 8-Aug

Previous Current Departure Snapshot Snapshot Date 3-Aug 6-Aug 4-Aug 7-Aug 15-Sep 15-Sep

Customer Processing Recommendation: Customers should use Schedules ID to see if these schedules are present in their system. If these schedules are present in their system, then they can delete these schedules so that these schedules are not used to create new bookings. If these schedules are not present in their system, then the NOT PRESENT schedules sent by INTTRA should be ignored. Booking Schedule Relationship: 1. If customers have systems in which bookings remain linked to their corresponding schedule that are no longer present in INTTRA system, then customers should not delete these schedules as bookings might get impacted. In this case, it is best for customers to directly get in touch with carriers for latest update on these schedules or let carriers directly convey schedules updates to them. 2. If customers have systems in which the booking schedule relationship ceases to exist after the booking is created, the expectation is that carriers would update transportation details in the booking via the confirmation. The schedules identified as NOT PRESENT in INTTRA system should be removed to ensure that new bookings are not created from schedules that no longer exist.

Version 1.0 Copyright 2012 INTTRA

Page 24 of 26 July 20, 2012

XII. Appendix 5 Schedules Business Rules Overview

There is significant variation in which schedules are organized by different carriers. INTTRA has determined that following conditions exist in carrier schedules and hence has implemented rules to mitigate these conditions. A. Duplicate Schedules Some Carriers provide two or more schedules with the same Vessel Name, Voyage Number, Origin, Departure Date, Destination, and Arrival Date. INTTRA will only preserve one occurrence of these schedules and delete the rest. This duplicate issue occurs in the following cases: 1. 2. Vessel stops at multiple ports at a location and all ports are identified via the same UN Location Code. Vessel loads and discharges at different terminals in a Port on the same date and time. Some carriers send same date and time information for arrivals and departures from different terminals at a port. Although carriers provide terminal and location names in the schedules EDI, currently INTTRA drops these names during processing. These names are also not displayed on Ocean Schedules website. In future INTTRA plans to accept Terminal and Port Names in schedules and convey the same to customers. INTTRA recommends that carriers continue to send Terminal and Port Names in schedules. INTTRA also recommends to carriers that they provide different arrival and departure dates for different terminals at a port as a vessel cannot actually call different terminals at a port on the same date and time. 3. Carriers send the same schedules twice with different conveyance reference numbers. Since INTTRA creates service schedules within a Conveyance Reference Number, two sets of identical schedules are created.

B. Duplicate Schedules except Departure Date Some Carriers provide two or more schedules with the same Vessel Name, Voyage Number, Origin, Destination, Arrival Date, but different Departure Dates. INTTRA will preserve the schedule with the shortest transit time and delete others. This duplicate issue occurs in the following cases: 1. Carriers sometimes combine schedules from subsequent legs into one leg INTTRA has recommended to carriers to send only the ports called by a vessel on a voyage. Carriers should not send all ports called by a vessel on outbound and return legs of a voyage with one voyage number (of outbound or return leg). Typically directional indicators (East/West or North/South) are used to distinguish the outbound and return legs of a voyage. 2. Vessel has multiple stops at a Port on a leg. The vessel stops twice at the same port; however the stops are separated from each other by stops at other ports. The first call to the port is to discharge cargo and the second call is to load cargo. Vessel calls multiple terminals in a Port

3.

C. Duplicate Schedules except Arrival Date Some Carriers provide two or more schedules with the same Vessel Name, Voyage Number, Origin, Destination, Departure Date, but different Arrival Dates. INTTRA will preserve the schedule with the shortest transit time and delete others. This duplicate issue occurs in the following cases: 1. Carriers combine subsequent legs into one leg.

Version 1.0 Copyright 2012 INTTRA

Page 25 of 26 July 20, 2012

2.

Vessel has multiple stops at a Port on a leg. The stops at the same port in a leg are separated by calls at other ports in the same area. Vessel calls multiple terminals at a Port

3.

D. Duplicate Schedules except Voyage Number Some carriers provide two or more schedules with the same Vessel Name, Origin, Departure Date, Destination, Arrival Date but different Voyage Number. INTTRA will combine these schedules into one schedule and concatenate all the voyage numbers using comma as a delimiter. Typically this issue occurs when carriers are supplying Commercial schedules that show service between regions in a rotation. In these cases carriers provide directional indicators for rotation Legs, but sometimes overlap Service Pairs in both legs of a rotation. INTTRA recommends to customers that a booking can be made on either Voyage Number as the expectation is that carriers will apply the correct voyage number when confirming the booking. E. Schedules with Transit Time Greater than 90 Days Some carriers provide schedules with Transit Time greater than 90 days. INTTRA will delete these schedules as they are considered invalid schedules. F. Schedules with Identical Origin and Destination Carrier schedules data and subsequent INTTRA processing can at times result in the creation of Service Schedules with identical Origin and Destination locations. INTTRA deletes these Service Schedules. G. Ambiguous Schedules Some carriers provide multiple schedules with the same Vessel Name, Voyage Number, Origin, and Destination. INTTRA will process the latest schedule provided by the carrier and delete others. If multiple schedules are provided on the same date, then INTTRA will select a schedule with the shortest transit time. If multiple schedules are detected with the same transit time, then INTTRA will select a schedule with the earliest Arrival Date. Ambiguous schedules result in the following cases: 1. Carriers reuse voyage numbers For Feeders, carriers sometimes reuse the same voyage number within a week. INTTRA recommendation to carriers is to send unique voyage numbers for different voyages. 2. Carriers send the same schedules twice with different conveyance reference numbers with different arrival and departure dates.

Version 1.0 Copyright 2012 INTTRA

Page 26 of 26 July 20, 2012