So, when a reservation comes in from the GDS:
1.) We create a new reservation in the Booking Engine.
2.) We assign that reservation to the unit type requested as long as there are still units of that type available.
a.) If there are no units of that type available, we will assign it to ANY AVAILABLE UNIT. (We do this because the property really MUST accept that reservation per contract with the GDS.)
3.) We then release the reservation so that it will be downloaded into the desktop software.
When a reservation modification comes in from the GDS:
1.) We CANCEL the original reservation that was made (described above).
2.) We then re-create a brand new reservation with the details of the changed reservation.
a.) NOTE: this new reservation maintains the SAME Confirmation number (ex. GDS86628). So when it is downloaded into the desktop, the desktop software should know that it is a modification instead of a new reservation and it will update the appropriate reservation in the desktop software.
So there is a flaw to this design in conjunction with the way our Booking Engine synchronizes data. When a modification comes in, the Booking Engine doesn’t know for sure which room the original reservation is actually assigned to (more below). Therefore it cannot remove the unit assignment when it performs the cancel. Therefore, the Booking Engine may assign the reservation to a different unit or even a different unit type because that unit/unit type may be booked (by the original GDS reservation). This is particularly gnarly for small properties that only have 1 unit per unit type (in which case the unit will virtually always be booked and therefore the modification will end up in the wrong unit type). For properties that have many units per type, this is a lot less of an issue since it will just end up moving the reservation from one unit to another within the same type.
The reason we can’t remove the unit assignment (the reason the Booking Engine doesn’t know for sure which unit the original reservation was in) is because of the way data synchronization happens with the desktop. Whenever you do a “Verify Occupancy”, the desktop software sends up a data map that maps Units to Days and includes which DESKTOP reservation is occupying that unit. So, when this happens, on the Booking Engine side of things, the connection between the original GDS reservation and it’s unit assignment is lost (it has no knowledge of what has happened in the desktop software). At that point, there is no way of knowing (on the BE side) what unit they were assigned to and so we can’t just go open it up for fear of allowing a double booking in the wrong place.