Question - an optional reservartion part for an already purchased ticket

[haghi82]

How to use the OSDM flow for the case where the purchaser wants to add an optional reservartion part for an already purchased ticket (especially of the multiride type) and, in addition, the carrier (distributor) requires control number of the reservations issued for admission? In such a situation, should a new bookingId be generated (if so, how can the fulfillmentID be transferred to the journey) or is there a way to add reservation parts to the booking in a FULFILLED state?

[jspetrak]

Hello @haghi82 this is something we have just made more clear in the documentation. The basic solution is to a new offer request for reservation only, and book it in a separate booking. However, distributors may support to add new offers to an existing booking, even one that already has all parts fulfilled. Please see https://osdm.io/spec/processes/#AddPartsToABookings

[haghi82]

Thanks for the response. According to the basic solution, is it possible to provide a reference to the primary booking or to the fulfilmentId, which includes a previously purchased admission?

[jspetrak]

The basic/general solution doesn't have any interlink between the already existing admission and newly requested reservation. In fact, in the optional solution, there isn't a exact link between ADM and RES either. They are only put into the same booking.

There is also possibility to provide a reference to an existing (multi-ride) ticket via AnonymousPassengerSpecification.card with TravelAccountType but that was never designed for single ride tickets and linkong them with separately booked reservations.

I would suggest to bring it as a feature gap to the Friday Technical Group so it can be analysed, other carriers/deistributors/vendor provide they current solutions and if not covered by the current specification, we can figure out an improvement.

[Azurab]

Hi, thanks for your instant reply.
So, we need to have strong statement that using POST /bookings/{bookingId}/booked-offers/ resource is valid for bookingId in CONFIRMED or FULFILLED state — it is important for PKP implementation. Is it necessary to make the technical group be sure about this?

[jspetrak]

Booking doesn't have a state, only its parts. So the openapi allows to add new parts even after first set of parts was all confirmed and fulfilled. The only exception is when a distributor explicitely disallow this.

tl;dr Unless PKPIC explicitely forbids it in its own implementation, it will be able to add new parts as second purchase to already purchased and paid booking.

[Azurab]

Booking doesn't have a state, only its parts.

I think Bookings Data Model should be updated though (btw. in "possible states" description it is also a mistake: CONFIRMED state is called "booked").

[jspetrak]

@Azurab Well, the booking status was actually removed from the API model. It can still be present internally in each inventory system but API doesn't disclose it for simplicity - for the same reason why the specification doesn't forbid or enforce ability to make secondary addition of new parts to already completed booking.

Please, could you point where did you find "booked" state so we can review it on the Friday Technical Group Call? Thank you.

[CGantert345]

TODO: update documentation in chaptermodel: Add Chapter BookingPartState Model and indicate in BookingStateModel that there is no booking State model. Clemens

[Azurab]

Please, could you point where did you find "booked" state so we can review it on the Friday Technical Group Call? Thank you.

Hi, e.g. https://osdm.io/images/models/bookings-data-model.png (comment on Booking resource).

[jspetrak]

@Azurab Thank you. This UML must be redrawn since it doesn't correspond to the current openapi specification. So far, we have adjusted the textual workding on the Models page to indicate there isn't a state on Booking.

[jspetrak]

TODO - Split Models page to State Models and Object Models.

[CGantert345]

additional reservation (or ancillaries) are allowed also in confirmed booking state. This is an optional feature.