csv out oceanschedules_v10.pdf

CSV Ocean Transport Schedule From INTTRA To Customers

User Guide Version 1.0

Table of Contents I. BUSINESS CONTEXT ...................................................................................................4

II. AUDIENCE ....................................................................................................................4

III. OVERVIEW: OCEAN SCHEDULES ......................... .....................................................4

A. Service Schedules .................................................................................................................................... 4 B. Website ..................................................................................................................................................... 4 C. Data Feed and Web Services ................................................................................................................... 5

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

A. Message Content ...................................................................................................................................... 6 B. Message Flow ........................................................................................................................................... 7 C. Data Supplemented by INTTRA................................................................................................................ 7 D. Exceptions ................................................................................................................................................. 7

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

A. Location Code ........................................................................................................................................... 9 B. Lloyds Code .............................................................................................................................................. 9 C. Party Code ................................................................................................................................................ 9

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

A. Location Qualification .............................................................................................................................. 10 B. Schedule ID ............................................................................................................................................. 10 C. Schedule Booking Relationship .............................................................................................................. 10 D. Data Feed Customization ........................................................................................................................ 11 E. Message Function Type: Reissue or Delta Schedules ........................................................................... 11 F. Delta Action Indicators ............................................................................................................................ 11

VII. GENERAL DATA FORMAT CONVENTIONS ................... .......................................... 12

A. Character Set Support ............................................................................................................................ 12 B. Date Format Conventions ....................................................................................................................... 12

VIII. CSV MESSAGE SPECIFICATION ......................... ..................................................... 13

A. Message Structure .................................................................................................................................. 13 B. Message Specification ............................................................................................................................ 13

IX. APPENDIX 1 – SCHEDULES USE CASES .................. .............................................. 16

A. Direct Services – Main Haul Vessel Loads & Discharges ...................................................................... 16 B. Indirect Services – Transshipments ........................................................................................................ 17 C. Indirect Services – Feeders .................................................................................................................... 17 D. Indirect Services – Inland Locations ....................................................................................................... 17 E. Full Reissue Schedules ........................................................................................................................... 18 F. Delta Schedules ...................................................................................................................................... 18

X. APPENDIX 2 – SCHEDULES DATA FEED CUSTOMIZATION .... .............................. 20

XI. APPENDIX 3 – DELTA SCHEDULES ...................... ................................................... 21

A. Schedules Snapshots ............................................................................................................................. 21 B. Schedules Comparison ........................................................................................................................... 21 C. Delta Feed Composition .......................................................................................................................... 22 D. Use Case 1: New Schedules .................................................................................................................. 22 E. Use Case 2: Unchanged Schedules ....................................................................................................... 23 F. Use Case 3: Updated Schedules ............................................................................................................ 23 G. Use Case 4: Not Present Schedules ...................................................................................................... 23

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

A. Duplicate Schedules ............................................................................................................................... 25 B. Duplicate Schedules except Departure Date .......................................................................................... 25 C. Duplicate Schedules except Arrival Date ................................................................................................ 25 D. Duplicate Schedules except Voyage Number ......................................................................................... 26 E. Schedules with Transit Time Greater than 90 Days ............................................................................... 26

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

Version 1.0 of 26 Copyright 2012 INTTRA July 20, 2012

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.


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.


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.

# Field Name Description

1 Carrier ID Carrier providing the schedule – expressed as either a Carrier SCAC code or customer-assigned alias.

2 Vessel Name Vessel Name

3 Lloyds Code Lloyds Code

4 Valid Lloyds Code Indicates if the Lloyds Code is Valid (VD) or Invalid (IV).

5 Voyage Number Reference number assigned by the carrier to a voyage for a particular vessel.

6 Service Name Carrier-provided service description

7 Schedule ID INTTRA Unique Schedule Identification. Used as primary key identifier for a schedule.

8 Schedule Status Identifies the status of schedule as either one of: New (C), Updated (U) or Deleted (D).

9 Origin Location Type Location type of the origin,either one of Place of Receipt (PLOR) or Port of Load (POL)

10 Origin UN Location Code UN Location code of the origin

11 Departure Date Departure Date at the Place of Receipt or Port of Load

12 Departure Date Type Indicates if departure date is estimated (ESTM) or actual (ACTL)

13 Destination Location Type Location type of the destination, either one of: Place of Delivery (PLOD) or Port of Discharge (POD)

14 Destination UN Location Code UN Location code of the destination

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

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


B. Message Flow

1. Carriers send schedules to INTTRA per INTTRA Message Specification via communication methods described in the INTTRA Connectivity Guide.

2. INTTRA validates carrier schedules, creates Service Schedules from carrier data and cleanse the data for invalid

Service Schedules.

3. INTTRA displays these schedules on OceanSchedules.com website including several White Label sites.

4. INTTRA sends these schedules to subscribed OS Data Feed customers via EDIFACT, XML, CSV and Web

Services as described in the INTTRA Connectivity Guide.

C. Data Supplemented by INTTRA

INTTRA supplements the following information in the message:

# Field Name Processing

1 Schedules ID Unique ID assigned for every Service Schedule transmitted via the Data Feed. See Schedules ID for details.

2 Lloyds Code Valid/Invalid Indicator

INTTRA validates Lloyds Code provided by the carrier via the algorithm 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 above-mentioned algorithm but does not verify that Lloyds Code is the actual Lloyds Code assigned to the vessel by IHS Fairplay.

3 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


o Duplicate schedules with arrival and departure date ambiguities o Duplicate schedules except voyage number o Schedules with transit time greater than 90 days o Schedules with identical origin & destination o 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.

3. ISO Country code of Ship's Registry: INTTRA does not support this information from its carriers..

4. Conveyance Reference Number: This is a unique reference number provided by carriers to manage their

schedules transmitted to INTTRA.


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 customer’s code or alias for carrier if the customer configured an alias at INTTRA. If the customer’s code or alias is not configured, INTTRA sends the SCAC maintained by INTTRA for the carrier.


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.

2. Port of Load – locations at which vessel/voyage named in the Transport Plan directly calls to load cargo.

3. Port of Discharge – locations at which vessel/voyage named in the Transport Plan directly calls to discharge

cargo.

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

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


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 Schedule s

Message Type

Definition INTTRA Processing

Reissue A message identified as “REISSUE” indicates that the full schedule data is sent.

INTTRA sends a full reissue of all carrier schedules per customer’s 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 schedule’s 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 Indicat or Description

C (New) indicates that the schedule has been added in the current snapshot when compared to the previous snapshot.

U (Updated) indicates that the schedule is present in both the snapshots and there is a change in


Delta Action Indicat or 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

INTTRA’s 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.


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 Description M/O/C Data Type

1 Sender ID Sender identification: Trading Partner’s sender ID Value is always “INTTRA”

M AN(35)

2 Receiver ID Receiver identification: Trading Partner’s EDI ID M AN(35)

3 Message Version Version of the CSV message structure Value: “1.0”

M AN(3)

4 Message Function Type

Indicates the type of the message, either one of: REISSUE or DELTA M AN(10)

5 Message ID Unique reference ID assigned to the message by the sender M AN(35)

6 Message Date Date and time of file creation expressed in GMT timezone M AN(13)

7 Total Number of Records

Total number of transactions (schedule data) being sent to the receiver M N(35)

Detail Fields:

# Field Name Description Supplied Values

M/O/C Data Type

1 Carrier ID 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.

M AN(17)



M/O/C Data Type

2 Vessel Name Vessel Name. M AN(35)

3 Lloyds Code Lloyds Code. O AN(9)

4 Valid Lloyds Code

Indicates if the Lloyds Code is Valid (VD) or Invalid (IV).

Values are: IV VD

C AN(3)

5 Voyage Number 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

M AN(255)

6 Service Name Carrier-provided service description O AN(60)

7 Schedule ID INTTRA Unique Schedule Identification. Used as primary key identifier for a schedule.

M AN(35)

8 Schedule Status Identifies the status of schedule as either one of: New (C), Updated (U) or Deleted (D).

Values are: C U D

C AN(3)

9 Origin Location Type

Location type of the origin,either one of Place of Receipt (PLOR) or Port of Load (POL)

Values are: PLOR POL

M AN(5)

10 Origin UN Location Code

UN Location code of the origin M AN(25)

11 Departure Date Departure Date at the Place of Receipt or Port of Load

M AN(13)

12 Departure Date Type

Indicates if departure date is estimated (ESTM) or actual (ACTL)

Values are: ESTM ACTL

M AN(5)

13 Destination Location Type

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

Values are: POD PLOD

M AN(5)

14 Destination UN Location Code

UN Location code of the destination M AN(25)



M/O/C Data Type

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

M AN(13)

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

Values are: ESTM ACTL

M AN(5)

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","Total_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_Date_Type","Destination_Location_Type","Destination_UNLocation_Code","Arrival_Date","Arrival_Date_Type" "CARRIER_A","JAKARTA EXPRESS","9301794","VD","2111A","EAX","8d8d365a6c3884d123a5cf37db229eeb",,"POL","NLRTM","2012061513:30","ESTM","POD","FRLEH","2012061522:30","ESTM" "CARRIER_A","MARE ATLANTICUM","9213272","VD","2214S,2214N","IMX","6faacd614e710b4704983b38561aa023",,"POL","INNSA","2012061509:30","ESTM","PLOD","INTUT","2012061614:30","ESTM"

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.

This is an illustration of multiple voyage numbers delimited by a comma.


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 & Disch arges

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","ESTM","POD","CAVAN","2012060200:00","ESTM"

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 carrier’s 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. Singapore (SGSIN) to Shanghai (CNSHA) 2. Singapore (SGSIN) to Busan (KRPUS) 3. Singapore (SGSIN) to Vancouver (CAVAN) 4. Singapore (SGSIN) to Seattle (USSEA) 5. Shanghai (CNSHA) to Busan (KRPUS) 6. Shanghai (CNSHA) to Vancouver (CAVAN) 7. Shanghai (CNSHA) to Seattle (USSEA) 8. Busan (KRPUS) to Vancouver (CAVAN) 9. Busan (KRPUS) to Seattle (USSEA) 10. Vancouver (CAVAN) to Seattle (USSEA)

"SCAC","VESSELNAME","9450375","VD","07E50","ESA","d8de192d557516ea9651aa2d6bbe7m",,"POL",

"SGSIN","2012060413:15","ESTM","POD","CNSHA","2012061507:45","ESTM"


"SGSIN","2012060413:15","ESTM","POD"," KRPUS","2012062211:00","ESTM"


"SGSIN","2012050413:15","ESTM","POD","CAVAN","2012060201:00","ESTM"

"SCAC","VESSELNAME","9450375","VD","07E50","ESA","d8de192f557516ea9651aa9d6bbe9n",,"POL",

"SGSIN","2012050413:15","ESTM","POD","USSEA","2012060416:30","ESTM"

"SCAC","VESSELNAME","9450375","VD","07E50","ESA","h2gu815m452616dt4211rp2s2eeq5t",,"POL",

"CNSHA","2012061621:00","ESTM","POD","KRPUS","2012062211:00","ESTM"

"SCAC","VESSELNAME","9450375","VD","07E50","ESA","h2gu815n452618du3211rp2s2eeq6t",,"POL",

"CNSHA","2012051621:00","ESTM","POD","CAVAN","2012060201:00","ESTM"

"SCAC","VESSELNAME","9450375","VD","07E50","ESA","h2gu815n452618du3211rp2s2eeq7t",,"POL",

"CNSHA","2012051621:00","ESTM","POD","USSEA","2012060416:30","ESTM"

"SCAC","VESSELNAME","9450375","VD","07E50","ESA","k6uo200e232816ze2817hj8p1wio3d",,"POL",

"KRPUS","2012052301:00","ESTM","POD","CAVAN","2012060201:00","ESTM"


"SCAC","VESSELNAME","9450375","VD","07E50","ESA","k6uo200e232816ze2817hj8p1wio3d ",,"POL",

"KRPUS","2012052301:00","ESTM","POD","USSEA","2012060416:30","ESTM"

"SCAC","VESSELNAME","9450375","VD","07E50","ESA","b3dc667w889016ar3241vv8j1hyu3q ",,"POL",

"CAVAN","2012060301:00","ESTM","POD","USSEA","2012060416:30","ESTM"

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", "NLRTM","2012050513:15","ESTM"," PLOD ","AUSYD","2012061801:00","ESTM" "SCAC","VESSELNAME","9450375","VD"," 07E50","WSA","d8de192d557516ea9651aa2d4sse1u",,"POL", "NLRTM","2012050513:15","ESTM"," PLOD ","NZAKL","2012061703:00","ESTM"

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 ", "FIHEL","2012052313:15","ESTM","PLOD","BDCGP","2012063001:00","ESTM"

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


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", "USDET","2012052813:15","ESTM","PLOD","ZAJNB","2012060101:00","ESTM"

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 Customer’s Data Feed customizations. See Appendix 2 – Schedules Customization for details.

"INTTRA","TP EDI ID","1.0","REISSUE","2012052409:30","328"

"SCAC"," VESSEL NAME A","9317971","IV"," 101N","WSA","d8de192d557516ea9651aa2d4sse1u",,"POL", "SAJED","2012051004:10","ACTL"," POD ","JPTYO","2012062600:00","ACTL"

"SCAC"," VESSEL NAME A","9317971","IV"," 101N","WSA","t2de342d557516ea9651aa2d6bbe2s",,"POL", "SAJED","2012051004:10","ESTM","PLOD ","CNHUA","2012061200:00","ESTM"

"SCAC"," VESSEL NAME A","9317971","IV"," 101N","WSA","q5yi392d557516ea9651aa2d6bbe2t",,"POL", "SAJED","2012051004:10","ESTM"," POD ","CNSHA","2012060201:00","ESTM" "SCAC"," VESSEL NAME B","8703397","VD"," 06W23",,"x0re777u557516ea9631bb2d6kle5u",,"POL", "ITGOA","2012061121:00","ACTL","POD","USSAV","2012062715:00","ESTM" "SCAC"," VESSEL NAME B","8703397","VD"," 06W23",,"d8de192d557516ea9651aa2d4sse1u",,"POL", " ESBCN ","2012061313:00","ESTM","POD","USSAV","2012062715:00","ESTM" "SCAC"," VESSEL NAME B","8703397","VD"," 06W23",,"d8de192d557516ea9651aa2d4sse1u",,"POL", " ESBCN ","2012051313:00","ESTM","POD","USHOU","2012060712:01","ESTM" "SCAC"," VESSEL NAME C","9317975","VD"," 10E ","ESA","d8de192d557516ea9651aa2d4sse1u",,"POL", " USNYC","2012052804:10","ACTL","POD"," INBOM","2012060815:00","ACTL" "SCAC"," VESSEL NAME D",,,"35E",,"d8de192d557516ea9651aa2d6bbe8n",,"PLOR", " USDET","2012052804:10","ESTM","PLOD","ZAJNB","2012060815:00","ESTM" "SCAC"," VESSEL NAME E","9999999","IV"," 31W ",,"d8de192d557516ea9651aa2d6bbe6l",,"PLOR", " THBKK","2012050404:10","ESTM","POD","ZAJNB","2012060215:00","ESTM"

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. "INTTRA","TP EDI ID","1.0","DELTA","2012052409:30","328"

"SCAC"," VESSEL NAME A","9317971","IV"," 101N","WSA","d8de192d557516ea9651aa2d4sse1u","U"," POL", "SAJED","2012051004:10","ACTL","POD","JPTYO","2012062600:00","ACTL"

"SCAC"," VESSEL NAME A","9317971","IV"," 101N","WSA","t2de342d557516ea9651aa2d6bbe0s","D"," POL",


"SAJED","2012051004:10","ESTM","POD","KRPUS","2012062400:00","ESTM"

"SCAC"," VESSEL NAME A","9317971","IV"," 101N","WSA","t2de342d557516ea9651aa2d6bbe2s","C","POL", "SAJED","2012051004:10","ESTM","PLOD","CNHUA","2012061200:00","ESTM"

"SCAC","VESSEL NAME A","9317971","IV"," 101N","WSA","q5yi392d557516ea9651aa2d6bbe2t","C","POL", "SAJED","2012051004:10","ESTM","POD","CNSHA","2012060201:00","ESTM"

"SCAC"," VESSEL NAME B","8703397","VD"," 06W23",,"x0re777u557516ea9631bb2d6kle5u","C","POL", " ITGOA ","2012061121:00","ACTL","POD","USSAV","2012062715:00","ESTM" "SCAC"," VESSEL NAME B","8703397","VD"," 06W23",,"d8de192d557516ea9651aa2d4sse1u","C","POL", " ESBCN","2012061313:00","ESTM","POD","USSAV","2012062715:00","ESTM"

"SCAC"," VESSEL NAME B","8703397","VD"," 06W23",,"d8de192d557516ea9651aa2d4sse1u","U"," POL", " ESBCN","2012051313:00","ESTM","POD","USHOU,"2012060712:01","ESTM"


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 carrier’s 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.

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

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

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

5. Arrivals Only in Future : Customers can choose to receive schedules with arrivals only in the future.

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

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

8. Compressed files: Customers can choose to receive compressed (*.zip) schedules files from INTTRA.

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


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. Previous Snapshot – Schedules processed on Current Date minus 2 (example: Jun 4, 2012) with departures within the next 42 days (Jul 15, 2012)

b. 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. Previous Snapshot – Schedules processed in the previous week (example: Aug 5, 2011) with departures within the next 42 days (Sep 16, 2011)

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

Schedule Present in Previous Snapshot

Schedule Present in Current Snapshot

Change? Action Indicator in Delta Feed

1 Not Present Present N/A C (Created or New)

2 Present Present No Not Included in Delta

3 Present Present Yes U (Updated)

4 Present Not Present N/A D (Deleted or Not Present)


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. Carrier Selectivity 2. Departures Only in Future 3. 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 Origin: Rotterdam Destination: New York Vessel: CAP STEPHENS Voyage #: 17W20 Future Departure Date Range: 6 weeks

Delta Date

Previous Snapshot

Current Snapshot

Departure Date

Arrival Date

Carrier/Application Functionality

5-Aug 3-Aug 4-Aug 16-Sep 29-Sep Carrier added the schedule on Aug 4. Included as NEW in Delta on Aug 5.

8-Aug 6-Aug 7-Aug 16-Sep 29-Sep Carrier removed the schedule on Aug 7. Included as NOT PRESENT in Delta on Aug 8.


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 Origin: Rotterdam Destination: New York Vessel: CAP STEPHENS Voyage #: 17W20 Future Departure Date Range: 6 weeks

Delta Date

Previous Snapshot

Current Snapshot

Departure Date

Arrival Date


5-Aug 3-Aug 4-Aug 20-Sep 3-Oct Carrier added the schedule on Aug 4. Not Included in Delta on Aug 5 as the departure is more than 6 weeks in future

9-Aug 7-Aug 8-Aug 20-Sep 3-Oct 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.


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 Origin: Rotterdam Destination: New York Vessel: CAP STEPHENS Voyage #: 17W20 Future Departure Date Range: 6 weeks Delta Date

Previous Snapshot

Current Snapshot

Departure Date

Arrival Date

Carrier/Application Functionalit y

5-Aug 3-Aug 4-Aug 16-Sep 29-Sep Schedule present in Aug 3 & 4 snapshots and is unchanged. Not included in Delta on Aug 5.

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 Origin: Rotterdam Destination: New York Vessel: CAP STEPHENS Voyage #: 17W20 Future Departure Date Range: 6 weeks

Delta Date

Previous Snapshot

Current Snapshot

Departure Date

Arrival Date



8-Aug 6-Aug 7-Aug 13-Sep 27-Sep Carrier changed arrival date in the schedule on Aug 7. Included as UPDATE in Delta on Aug 8.

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


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.

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

Carrier: Carrier1 Origin: Rotterdam Destination: New York Vessel: CAP STEPHENS Voyage #: 17W20 Future Departure Date Range: 6 weeks

Delta Date

Previous Snapshot

Current Snapshot

Departure Date

Arrival Date

Carrier/Application Functio nality


8-Aug 6-Aug 7-Aug 15-Sep 28-Sep Carrier cancelled the schedule on Aug 7. Included as NOT PRESENT in Delta on Aug 8.

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.


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. Vessel stops at multiple ports at a location and all ports are identified via the same UN Location Code.

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

3. Vessel calls multiple terminals in a Port

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.


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.

3. Vessel calls multiple terminals at a Port

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.

csv out oceanschedules_v10.pdf

Documents

delta schedules

ocean schedules

location code

service schedules

lloyds code

party code

message processing

message content