Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
60 changes: 60 additions & 0 deletions cs/v1/CS_v1.0.3.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -1660,6 +1660,52 @@ components:
pattern: ^\S(?:.*\S)?$
description: The identifier of an export voyage. The carrier-specific identifier of the export Voyage.

IntermediateCall:
title: Intermediate Call
type: object
description: |
An intermediate call between `departure` and `arrival` in the current leg.

The cargo remains on the same planned transport, and no transhipment takes place at this location.
properties:
transportCallReference:
type: string
example: SR11111X-9321483-2107W-NLAMS-ACT-1-1
maxLength: 100
description: |
The unique reference for the arrival transport call. It's the vessel operator's responsibility to provide the Transport Call Reference, other parties are obliged to pick it up and use it. It can take the form of Port Call References as defined in OVS Definitions Document, or alternatively a reference as defined by the vessel operator.
Comment on lines +1671 to +1676
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

1. Wrong transportcallreference description 🐞 Bug ≡ Correctness

IntermediateCall.transportCallReference is described as “the unique reference for the arrival
transport call”, which is incorrect for an intermediate call and conflicts with the spec’s generic
TransportCall.transportCallReference wording; this can lead implementers to populate/interpret the
wrong reference.
Agent Prompt
### Issue description
`IntermediateCall.transportCallReference` currently says it is the unique reference for the **arrival** transport call, which is misleading for an intermediate call and inconsistent with the spec’s generic `TransportCall.transportCallReference` definition.

### Issue Context
Intermediate calls are explicitly defined as calls **between** the leg `departure` and `arrival`, so the field description should be neutral (transport call at this intermediate location) rather than arrival-specific.

### Fix Focus Areas
- cs/v1/CS_v1.0.3.yaml[1671-1676]

### Suggested change
Update the description to align with `TransportCall.transportCallReference`, e.g.:
- “The unique reference for a transport call …”
or
- “The unique reference for the transport call at this intermediate location …”

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

facilityTypeCode:
description: |
The code to identify the specific type of facility. The code indicates which role the facility plays during the transportCall.
- `BORD` (Border)
- `CLOC` (Customer Location)
- `COFS` (Container Freight Station)
- `OFFD` (Off Dock Storage)
- `DEPO` (Depot)
- `INTE` (Inland Terminal)
- `POTE` (Port Terminal)
- `PBPL` (Pilot Boarding Place)
- `BRTH` (Berth)
- `RAMP` (Ramp)
- `WAYP` (Waypoint)
example: POTE
maxLength: 4
type: string
location:
$ref: '#/components/schemas/Location'
arrivalDateTime:
type: string
format: date-time
example: '2025-01-14T09:21:00+01:00'
description: The local date and time, when the arrival will take place.
departureDateTime:
type: string
format: date-time
example: '2025-01-14T09:21:00+01:00'
description: The local date and time, when the departure will take place.
required:
- location

Leg:
title: Leg
type: object
Expand All @@ -1681,6 +1727,20 @@ components:
- $ref: '#/components/schemas/OtherTransport'
departure:
$ref: '#/components/schemas/PlaceOfDeparture'
intermediateCalls:
type: array
description: |
The option to list all intermediate calls between `departure` and `arrival`.

Intermediate calls are calls where no transhipment and no change of mode of transport takes place.

This structure allows intermediate non-transhipment calls to be grouped under a single leg, enabling consumers to present them as collapsed or expanded elements in the user interface, instead of treating each call as a separate leg.

The list only includes calls taking place **between** the `departure` and `arrival` of the current leg.

The order of the list is the order of visits from `departure` to `arrival`.
items:
$ref: '#/components/schemas/IntermediateCall'
arrival:
$ref: '#/components/schemas/PlaceOfArrival'
footprint:
Expand Down
Loading