Add support for a `PENDING` `TravelDocument`

[jorgenosberg]

Could OMSA include a new pending_ticket type or similar type of TravelDocument that may be used in the case where a package is purchased for a journey in the future & the actual ticket content is not ready yet?

At Entur we encounter this scenario frequently:

• A package is purchased e.g. with a startDate set sometime next month
• We know about the package and the type of ticket that will exist, BUT
• The actual QR code or binary ticket data is not available for pickup from the ticketing system yet

[edwinvandenbelt]

Understood, but the TravelDocument has a startValidaty and endValidity. It's common that the traveldocument cannot be obtained a long time before the startValidity:
travelDocument:
x-tm: TRAVEL DOCUMENT
type: object
discriminator:
propertyName: travelDocumentType
mapping:
LINK: "#/components/schemas/externalTicket"
BARCODE: "#/components/schemas/binaryTicket"
QRCODE: "#/components/schemas/binaryTicket"
AZTECCODE: "#/components/schemas/binaryTicket"
required:
- startValidity
- endValidity
- travelDocumentType
properties:
startValidity:
$ref: "#/components/schemas/dateTime"
endValidity:
$ref: "#/components/schemas/dateTime"
travelDocumentType:
$ref: "#/components/schemas/typeOfTravelDocument"

Should we add a property 'ticketAvailableFrom'? Or, another question, how do you provide the tickets? Using the /collections/travel-documents/items, of as a link in the package?

[jorgenosberg]

We provide the tickets with the collections/travel-documents/items and the clients typically filter with the packageId query param.

Since there is no reference from package/offers/leg to which travel documents will be issued or when, it would make sense to either have a new pending_ticket type or at least add the ticketAvailableFrom as you suggested - since it's the only way for clients to check which tickets are being issues for their CONFIRMED package.