I 44 Booking synchronization management - UnionInternationalCheminsdeFer/OSDM GitHub Wiki
I-44: Booking Synchronization Management
Description
The objective is to provide an interface that allows the Distributors and Allocators to keep the bookings and compensation claims in their systems up to date when changes occur on the Carrier or Allocator side. Possible changes include re-accommodation of a passenger by the Carriers because of a disruption. In case the passenger bought a through ticket, the Distributors can trigger a re-accommodation of the remain part of the journey. The interface can also be used by the ticket vendor to update the booking after a schedule is confirmed or when changes occurs in a group booking for instance. Distributors and Allocators need to be updated on decisions for compensation claims made by the Allocators and Carriers.
Owner
- Koffi Frédéric Konan (ETT / Amadeus)
Business Value
For a customer
who has booked at ticket and faces a disruption
the synchronization API
is a means of booking synchronization between carriers and distributors
that allows the distributor to inform the customer
unlike the current situation
our solution permits to support the customer in case of disruptions.
Business Outcomes
This solution improves the customer satisfaction by reducing the risk of having stranded passengers. If the passenger is reaccommodated, the railways undertaking reduces its financial loss as it may not need to give a financial compensation to the traveller. The solution can be used to keep the booking in the Distributor system up to date when changes occur to the booking in the Carriers system via channel that is different from that of the Distributor.
Leading Indicators
The early measures that will help predict the business outcome hypothesis. For more on this topic, see the Innovation Accounting advanced topic article.
To do
Nonfunctional Requirements
Nonfunctional requirements (NFRs) associated with the epic.
To do
Context
The request is in the context of the European passenger right regulation which provide the legal framework on handling passengers in case of disruption. We also considered scenario in which it was critical to keep the booking in Distributor System up to date.
Required for: I-39 paperless complaint management
Solution Design
-
Event driven, push messages
-
Flow: Inform authorized listener of the fact that changes has occurred. Then the listener has to call the carrier about the what has changed.
-
Event types and their semantics:
-
Trip
TRIP_CONFIRMED
- (use case: group booking)TRIP_CHANGED
- booking is still valid, but trip has changed, e.g. re-routing due to construction etc., even a simple delayTRIP_CANCELLED
- (use case: disruption, strike,..): trip no longer rideable, no alternative available
-
Booking
-
BOOKING_CANCELED
- DELETE /bookings/{id}: pre-booking has either been cancelled by distributor or pre-booking has timed out -
BOOKING_CONFIRMED
- POST /bookings/{id}/fulfillments: booking has been confirmed -
FULFILLMENT_REFUNDED
- PATCH /bookings/{id}/refunds: either refunded by original distributor or (depending on agreements) other party -
FULFILLMENT_EXCHANGED
- PATCH /bookings/{id}/exchangeOperations: either exchanged by original distributor or (depending on agreements) other party -
FULFILLMENT_FULIFILLED
- PATCH /bookings/{id}/fulfillments: fulfillment has been fulfilled. Happens (for most providers) when BOOKING_CONFIRMED -
FULFIILLMENT_CONTROLLED
- only to be used when subsequent booking (e.g. train as "feeder flight") depends on use of the booking. Not to be used for "no refund after travel", as this decision stays with the provider/allocator -
REFUND_INITIATED
- refund initiated at provider level, e.g. at the station office. Needs to happen before travel. This implies releasing potentially booked places or ancillaries (e.g. meal). -
BOOKER_CHANGED
- PATCH /bookings/{id}/booker: name or contact data changed -
PASSENGER_CHANGED
- PATCH /bookings/{id}/passenger: name or contact data changed
-
-
Complaints
DECIDED
- PATCH /complaints/{complaintId}: A decision on the complaint has been madeSETTLED
- PATCH /complaints/{complaintId}: The complaint has been settled, i.e. a voucher has been issued or a bank transfer has been madeINFORMATION_MISSING
- PATCH /complaints/{complaintId}: To make a decision additional information is needed.
-
-
To verify whether a booking has changed on the distributor's side, a revision number (or timestamp) on the booking is required.
-
Subscribing to event. A receiver has to provide
- The events it is interested in. E.g.
BOOKING
,TRIP
- The end point the events need to be sent to. E.g.
https://trainline.com/api/webhooks/db
- Sign message to guarantee that the sender is in fact who it claims to be. E.g.
HMAC
- IP whitelist
- The events it is interested in. E.g.
-
The solution shall not be complex. :-)