Place map for multiple reservation offers

[jspetrak]

Reservations for different seats may have different price. (regardless if the price is on reservation or fee)

Create new place map API to get multiple reservation offer IDs and return availability with multiple vehicle views based on the reservation offer ID.

Note: Query string may be too long for the URL, consider POST request.

To be discussed: retire the original place map API?

[Linus-Turnit]

Comment from Turnit/Linus I agree of the need to do this change. It makes it possible to fetch placeMap avialability for different types of reservations in one hit. It also opens up the possibility to make an upgrade from 2:nd class to 1:st class in a good way. That is good.

Our real need is to have the possibility of adding a selection-fee when selecting seat from placeMap, and the fee can be different for different places as well.

IMS can rank the places internally and add different fee amounts depending of the place-rank to the place-map availability response . It is easy for the distributor to show the customer the extra fee on each place (if any). image

At booking with placeSelections, the IMS add the proper fee for the place to the reservation or not depending of selected place.

The selection fee shall be tight connected (by reference) to the reservation to make it easier to handle it at delete and refund of the reservation.

This behavior to charge some extra when selecting from a place-map is quite common and popular for commercial express bus companies and there is also examples in the rail industry (Flix train). To add a optional placeMapSelectionFeeAmount to the PlacePostions structure would in our opinion make it easy for both distributors and providers to handle this.

The alternative is to define different reservationOfferParts for different accommodationSubType (one with a fee and one without the fee) for each place. In case of different fees on different places this can expand to a big number of different accommodationSubTypes.

For the distributor it will be complicated to choose the right reservationOfferPart with the correct accomodationSubTypes in case of not selecting place.

When rendering the place-map for a coach, several availability/place-map responses must be merged into one common place-map.

Answer from Clemens: The indication in the reservationfferPart that a graphical selection is provided is included in availablePlacePreferences. This allows a fee fo reserations with graphical reservation.

Response from Turnit/Linus So you mean at "normal" booking time the distributor selects reservationIds that don't have graphicalReservation. When place-map is used, reservationIds with the tag graphicalReservation set, is in the game.

Yes that can work, but still you have a complicate process for the distributor to show the fee in the place-map.

To get something like this (Flix train) Before rendering the place-map. The distributor has to:

GET /coach-layouts/{layoutId} POST /availabilities/place-map Merge several PlaceAvailabilities for the accomodationType/travelClass/serviceClass Populate the fee on each places buy running GET /bookings/{bookingId}/booked-offers/{bookedOfferId}/additional-offers). The provider must generate two reservationOfferParts for the same place/seat.

It is doable, but for me it is way more complicated, both for distributor and provider, than adding the placeMapSelectionFeeAmount direct to the place/seat.

[CGantert345]

Here an Option that might work for seat specific prices:

Requirements:

• Must be Non-Breaking (also functionally)
• Booking must be possible without Graphical Display for the cheapest Price)
• Cheapes Price must be displayed directly and not hidden in the places (legal requirement)
• Offer must be transparent for the customer

Changes in the spec:

• ProductTag "ACCEPT_SEAT_PRICES"

• ReservationOfferPart

  • indication for additional supplements/fees per seat
  • show price range?

• Availability:

  • indication in the request to show only non-priced seats
    • show additional prices (supplements and/or fees) per seat
    • combinatoric rules are modelled via reservationOfferPart, the seats shown for one reservationOfferPart must be selectable in combination.

• Additional seat offers

  • e.g. book the free seat next to you for luggage
  • Might work as additional AncillaryOfferPart + ReservationOfferPart

• PatchBookingPart with seatSelection:

  • return additional fees, changed fees, removed fees
  • return reservationOfferParts where prices are changed
  • return additional ancillaries/reservations offered

We need a documentation on where to use seat price and where not.

• seat price: many specific prices for seats which can be combined additive in the bookingPart.
• only reservationOffer: cheapest price, prices in categories which are not combinable in one reservation, prices for a few categories only.

[Linus-Turnit]

This will probably be a feasible approach when displaying the placeMap for offers, but I think we have to clarify the content of a reservationId itself. At offer level it is probably a static id for a travelClass and accomodationType combination.

In a bookedOffer the reservationId is unique at least within the bookedOffer.

For distributor systems that start the process by booking the admission and system decided reservations and later in the flow give the customer the possibility to select a specific place within the same travelClass and accomodationType, there is only one unique reservationId to provide to GET /availabilities/place-map. We don't have the list of offered reservationId's to provide.

It is up to the IMS to give the customer possible seats to select from in a placeMap. It is probably seats within the same travelClass and accomodationType that are returned, but that can be an upgrade as well to an extra cost.

Do we need different end-points for the placeMap depending on offer or booking context?

[jspetrak]

Do we need different end-points for the placeMap depending on offer or booking context?

There is a context switch query parameter contextType (OFFER or BOOKING)

there is only one unique reservationId to provide to GET /availabilities/place-map

I believe we discussed last time that new version of availability endpoint (new POST vs current GET) could be created to take multiple reservation IDs as parameter and provide available seats for each.

[Linus-Turnit]

I know the context switch in the query parameter, but maybe it should be different responses depending on context. I am not sure but it is a feeling I have.

The reservationId points out different things depending on context. For OFFER-context it is a stable id for the travelClass/accomodationType combination. In BOOKING-context it is a unique id for the already booked reservation.

With the new POST end-point in BOOKING-context, it is possible to provide unique ids for each passenger in the travel party. In OFFER-context it is possible to provide different stable reservationIds describing different types of reservations.

In BOOKING-context it is up to the IMS to identify alternative places for the given unique reservationIds. It is probably places with the same travleClass and accomodationType but it could also be places with some minor differences, candidates for an extra fee. The IMS know the difference and can provide the individual fee on each selectable place in the response, Sales tool can then show the fee on each place to the customer before selecting the place. The customer is then informed of the extra cost to pic that place.

[jspetrak]

FOR 3.2.0 (+ backport to 3.1, 3.0 patch) + deprecate the GET

THE REQUEST

POST /availabilies/place-map

{
  "contextType" : "OFFER",
  "contextId" : "offer1",
  "resourceType" : "RESERVATION",
  "resourceIds" : [
    "reservation1",
    "reservation2"
  ],
  "referenceCoachNumber" : null,
  "referencePlaceNumber" : null
}

(The same payload for nearby and preferences request, responses differ)

THE RESPONSE

{
  "vehicleAvailability" : [
    {
      "objectType" : "PlaceAvailability",
      "resourceId" : "reservation1",
      ...
    }
  ]
}

FOR 4.0.0 remove the GETs

[Linus-Turnit]

We still haven't any seat-map selection fee/cost per seat at preBooking in the response.