Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

This page explains the underlying mechanism of showing and updating online availability, for both the own website as well as TO websites. 


Image Added















Figure 1. Conceptual overview of availability mechanism


There are some basis principles that apply to this topic:

Ground rules

  • Ground rule is that it should never be possible to create an overbooking, because the online bookingflow contains at least 1, but best case 2 validation steps on realtime availability (depends on how TO-online bookingflow is setup by TO itself).
  • The online calendar on the customer's website is updated every hour. So it is possible some bookings are made within this hour and a certain weekend is sold out, but the dates are still visible. This does not mean a new booking can be created, because of the real time check further down the bookingflow when a user is trying to make a booking. 
  • The online calendar on the TO website is updated in accordance with the TO routines. Based on experience we know that most TO's only refresh the calendars only once or twice a day. So the same principle applies as for the direct website, only then with a larger timeframe. Certain dates may seem available, but in fact a booking cannot be created because of the realtime check during the bookingprocess. 

Test if uncertain

  • If it is not clear whether availability shown online is correct or not, quickest test case is trying to create a booking via MXTS system. This leads to 2 outcomes: 
    • Booking via system is possible >> Both via website and system a booking can be made, therefore the cause lies in configuration
    • Booking via system is not possible >> Availability in system is correct, a new booking cannot be created (no risk of overbooking). Online availability is not updated yet based on the re-index. Check again in 1,5 hours, otherwise contact Maxxton. 

Investigate issues

  • When an issue seems present with TO calendars, it is necessary to have clear: 
    • What date/time is configuration change performed (price, rentability, allotment)
    • What date/time is the own website checked
    • Was finalizing a booking via website possible (reservation is then present in system)
    • Was finalizing a booking via MXT system possible (reservation is then present in system)
    • At what point in the online booking flow was the TO when reporting a booking was possible to make
    • What webservice calls are included in the TO booking flow (create_reservation_proposal and/or confirm_reservation)