Booking provisionalPrice and confirmedPrice

[rolandkla]

A booking contains 2 key elements:

• provisionalPrice
• confirmedPrice

These elements are both optional and lacking a description. Can we clarify these to prevent any confusion for (future) implementations?

I would like to verify our understanding

provisionalPrice Total sum of the offerParts that are pre-booked and yet to be confirmed. The (remaining) amount to be paid by the customer/passenger.

confirmedPrice Sum of the offerParts that are confirmed and paid for by the customer/passenger, the monetary value of the booking. A refund will reduce the confirmedPrice because the offerPart is not active/valid any more.

Example 1 An offer is booked in pre-booked state with value 100 provisionalPrice: 100 confirmedPrice: 0

After confirmation: provisionalPrice: 0 confirmedPrice: 100

Example 2 An existing booking with an offerPart of 100 is canceled, after confirmation provisionalPrice: 0 confirmedPrice: 0

Example 3 An exchange is initiated for the booking of example 1, to an new offerPart of 200. Customer has paid 100 and needs to pay an additional 100 for the new offerPart

In pre-booked state: provisionalPrice: 100 confirmedPrice: 100

After confirmation of the exchange: provisionalPrice: 0 confirmedPrice: 200

[jspetrak]

Document as recommended. Possibly make mandatory in 4.0

[CGantert345]

I found it in the documentation, but there it is called balance not price: "the confirmed balance amount only totals offer parts where the confirmation actually succeeded, while the provisional balance amounts to the total of the offer parts where the error occurred (or where the confirmation was never attempted because the error came too soon)"

It was initially introduced for the case where a confirmation of a booking failed partially.

[CGantert345]

Using it for an exchange could have strange results. Would the provisional price be negative if the new booking is cheaper?

[rolandkla]

If the customer needs to be refunded due to an exchange, then I would say yes. The OSDM client has to know the amount remaining to be paid for a booking, or has been paid.

It is the same behaviour if a booking is provisionally created and a new offer is added to that booking, then the provisionalPrice increases. And after removing one of the provisional bookedOffers, the provisionalPrice changes accordingly.

If this is not exposed or used then the OSDM client has to perform this calculation based on the individual offerParts, refundOffers, exchangeOffers and onHoldOffer values and external payments. After all, the OSDM client must know how much the customer should be charged and what the booking value is.

[CGantert345]

The confirmed refundAmount is in a separeate field refundAmount, not in price. Maybe it is better to add a provisionalRefundAmount.

[CGantert345]

TODO:

• add provisionalRefundAmount
• documentation: provisional amount should be positive. Documentation wording should be aligned (balance --> price) + examples.

CG