Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

voyage number(s) in TnT specs #151

Open
rlilov opened this issue Mar 30, 2023 · 3 comments
Open

voyage number(s) in TnT specs #151

rlilov opened this issue Mar 30, 2023 · 3 comments

Comments

@rlilov
Copy link

rlilov commented Mar 30, 2023

Hello,
Reading your specifications, there are 4 voyage numbers. export, import and universal for each.
In tracking context, only one voyage number is relevant, if carrier reports discharge, he will likely use import voyage in the voyage field and respectively use export voyage number in voyage field.

Only context where maintaining 2 voyage numbers (import and export) makes sense is in scheduling data, i.e. vessel arrives with voyage A and departs under voyage B, but TnT feed does not deal with schedules

Can you please explain a use case where TnT scenario would require 2 voyage numbers in a transaction?

Seems to me, in the interest of simplicity (both from API creator and consumer POV) one voyage number (2 actually, if you insist on universal) are enough.

@HenrikHL
Copy link
Contributor

HenrikHL commented Aug 1, 2023

Hello @rlilov,
Sorry for this late reply - apparently your request has fallen between chairs...

To answer your question:
Import- and Export-VoyageNumbers are connected to entering and leaving a "region" in a roundtrip. So for a Europe-Asia service - some ports near the "turn-around" point have a different Import and Export VoyageNumber. Here is an example:

Port A Port B Port C Port D Port E
Import VoyageNumber 0123E 0123W 0123W 0123W 0123W
Export VoyageNumber 0123E 0123E 0123E 0123W 0123W

When arriving and leaving Port A above - the Import- and Export-VoyageNumbers would be the same: 0123E
For Port B and Port C the ImportVoyageNumber has changed to a West-bound voyage: 0123W
For Port D both are again the same: 0123W

It should also be mentioned that the carrier[Iport|Export]VoyageNumber differs from carrier to carrier for the same vessel (when used in VSA (Vessel Sharing Agreement) context). The universal[Import|Export]VoyageReference is an agreed identifier between all carriers. In the future the universal[Import|Export]VoyageReference will most likely deprecate the carrier[Iport|Export]VoyageNumber

@rlilov
Copy link
Author

rlilov commented Aug 2, 2023

Hello @HenrikHL ,
Thanks for your reply. Everything you say is true, but it is relevant to schedules context.
My question was related to TnT and was asking for use case where TnT scenario would require 2 voyage numbers in a transaction.

My understanding is that for any event , be it equipment, transport or shipment, only one voyage is relevant.
for example:
ARRIVAL: it is implied that it is import voyage
LOAD: it is implied that it is export voyage
Booking confirmed: voyage implied is export voyage
My point is that introducing the import and export voyage data elements in TnT flow is not required, could lead to confusion and increases the complexity of already complex TnT model.

@KPS010289
Copy link

Hello @rlilov

We acknowledge your reasoning behind the need for using one voayge number which is relevant for a certain phase. However, during our development phase for T&T standards the contributing SMEs considered this an important piece of information. We at DCSA functioning as a standards development body have to incorporate the processes within the all member organisations. We have so far not received this issue from any of the members. However, this is something we can put on our items to bringforth in next discussions when we get there. Highly appreciate your involvement in providing active feedback for our work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants