Refund (offers) request & delivery - 20260702

[edwinvandenbelt]

Refund process contains 2 steps: request refund offers, and then request a refund, based on an offer.

Request refund offers:

Request refund:

Items to discuss:

• is it possible/required to have a 'rollback' on the refund?

[OlivierBigex]

Why naming this request "refund" when a refund implies a monetary transaction, which depends on retailer's process.

Cambridge definition: an amount of money that is given back to you, especially because you are not happy with a product or service that you have bought.

According to EUDIT BUC, the retailer requests a cancellation and gets information about the price balance. And the retailer could apply fees and choose to reimburse immediatly, later on, with vouchers...

I know that OSDM call it "refund" as well, but it is for me a tiny mistake.

I would prefer to name it "cancel" or "cancellation".

[OlivierBigex]

An aftersales is a change on a transport contract = a fulfillment. A package is not a contract. Thus the fulfillment should be the central object of the request. Package Elements and Travellings parties are parts of the fulfillment to me canceled.

[CGantert345]

The fulfillment is the proof of the contract, not the contact itself. The fiulfilments can be organized for an efficient control rather than according to separatable contracts.

[OlivierBigex]

I make a clear difference between the logical contract (I stay on "fulfilment", what else ?) and the way it is delivered ("travel documents").
Anyway, I would like to qualify my comment: the entry point could be the PackageId, but the fulfilmentsRefs are mandatory, not travellingEntityRefs or packageElementRefs.

[CGantert345]

In the request an overrule code is required to ask for overruling refund conditions in case of speciual circumstances:

OverruleCode
'CONNECTION_BROKEN'
'DEATH'
'EQUIPMENT_FAILURE'
'PAYMENT_FAILURE'
'PRM_SUPPORT_UNAVAILABLE'
'SALES_STAFF_ERROR'
'STOP_NOT_SERVED'
'STRIKE'
'TECHNICAL_FAILURE'
'TICKET_NOT_USED'
'INABILITY_TO_TRAVEL': Inability to travel due to accident or sickness.
'EXTERNAL_COMPENSATION': Offer has been compensated outside of the provider system in another way.
'DISRUPTION': Inability to operate due to disruption.
'JOURNEY_OBSOLETE': Due to external factors it's senseless to start the trip, thus the travel is obsolete.
'CERTIFIED_MEDICAL_CONDITION': A medical certificate certifies that the passenger is unable to travel.
'DELAY_COMPENSATION': Allows to override conditions in context of passenger rights regulation (PRR)

[CGantert345]

Refund offer summary should be able to provide additional translations (sales staff might need a language different from the customer).

[CGantert345]

As the refund offer will be part of the booking also after confirmation it needs a createdOn and confirmerOn date to show permanently when it was created and confirmed.

[CGantert345]

delayedReimbourcement should also be indicated in a code (IMMEDIATE, DELAYED) as it is usually not possible to provide an exact date time for the upcoming reimbourcement at offer time.

[CGantert345]

In the refund offer the applied overrule code needs to be indicated as not all requested codes might be accepted by the provider.

[CGantert345]

The refund offer needs to reference the affected fulfillments to indicate which fulfillments the customer needs to replace.

[CGantert345]

The confirmed refund offer needs to additionally reference the new fulfillments in case there are some (these could be reissued tickets with less passengers and / or vouchers). Issued vouchers should be listed separately.

[CGantert345]

The confirmed refund offer should be able to provide an accounting reference for the trasaction that can be retrieved in settlement data.

[CGantert345]

An optional RefundOfferBreakdown is needed to allow the detailed description of included parts in the refund offer . List of refundOfferBreakdownItems including refundFee, refundableAmount, reference to a booking part (id, summary, link structure).