Is it possible to ask for two refund offers in parallel

[Deb1484]

Hello OSDM team,

I cannot understand by reading the specifications if, given that a refund offers exists and it's valid, you allow to ask for a new refund offer request for a different fulfillmentID of the same booking.

Thank you in advance for your reply
sorry, I've forgotten to change the title and I cannot update it

[CGantert345]

Some systems reject the refund offer request in case a refund offer is still pending. You first need to confirm or delete the pending offer.

[Deb1484]

Hi @CGantert345 ,

thanks for your quick reply!
To be sure, my question was about different fulfilllments belongings to the same booking code so are you saying that, as some carriers do not allow to have or ask for several offers if one is already available for the same bookingCode even if there are fulfillments without offer refund, is it not possible to ask for multiple refund offers even when these do not concern the same fulfillment.
Am I right ?

[CGantert345]

yes. Even if the refunded fulfillments are different ones they might be linked due to commercial rules of the booked offers. To avoid complex constraints it might be usefull to restrict the pending refunds to one.

[Deb1484]

thanks ! Indeed I understand the risk when the booking concerns products of one carriers but in case of several carriers, it's a fonctionnal limitation to have just one refund offer per booking I think.
Anyway, thanks again @CGantert345 !

[ManuelQuemerais]

Hi,

as far as I can remember, OSDM specifications and documentation initially (couple years ago) explicitly pointed at restriction on "Proposed" refundOffers, it only supported one "Proposed" refundOffer at a given time (which implied to explicitly delete previous refundOffer if ever a new refundOffer was required).
I think that this OSDM restriction has been lifted since then, doc has been updated, OAS contracts also.
But that doesn't imply that all OSDM implementers may support having multiple "Proposed" refundOffers at the same time, as pointed at by Clemens, there's often constraints in underlying systems that may prevent it.
When it comes to our context Debora, i.e. an OSDM implementation on "retailer" scope, with multiple underlying distributors, I see no reasons to restrict support of parallel "Proposed" refundOffers (except obviously when they point at the same fulfillments, bookingPart, and that their providers do not support such parallel refund quotation).

@CGantert345 : please do not hesitate to fix/correct my above statements, especially if you're aware of OSDM "hard" limitations (in specs).

[ManuelQuemerais]

Hi @CGantert345 , we'd be interested into your view on above affirmations.
We've checked functionnal documentation (after-sales-processes/#refund), and below part looks to backup a constraining scenario in which only one refund-offer at once should be supported :

But that statements looks way to "vague", applying to all refund-offers, without even limitations of the fact that they point at the same fulfillment / bookingPart / Passenger, that's confusing, and not aligned with actual OAS Specs that have been fixed to properly support having multiple active refundOffers at a given time.

[CGantert345]

The multiple refund offers were introduced to cover the situation where you have a refund offer with refund in regular currency and another refund offer with refund in vouchers. There need to be two offers as the conditions are different but they refere to the same passengers / booking parts. Obviously you can only accept one of the offers.

[ManuelQuemerais]

I get you on that one, I think that it also corresponds to what is detailed here :

So, If I properly understand you

• even if current OSDM OAS specifications would support having multiple active refundoffers at a given time, even partially targeting the same fulfillments, passengers or bookingParts, even resulting from distinct requests (GET)
• there's an implementation requirement in functional documentation (after-sales-processes/#refund) that explicitly forbid such situation
• and only one refundOffer can be a active a given time, except if that refundOffer does not target the same fulfillments, passengers or bookingParts, or if that refundOffer is actually one variant of the same refundOffer (e.g. detailing conditions in another timeframe, or currency).

Do you know why such restrictive requirement is set ? Given that OAS specifications can handle having multiple active refundOffers (pointing at same targets, with same timeframe, with same currency), and that some back end systems may be able to cope with that, what are the rationales in forbiding such implementation ?

[jspetrak]

The reasons originate from the real business world - same, many, but not all providers limit the number of concurrently available refund offers to 1 (provided they are for the same payment method). But the OAS can't limit that, because some others are capable of existence of multiple refund offers, either because actively use it, or they don't care in the business process.

I leave the definitive decision to @CGantert345 but I feel we should relax this restriction in text, and just make "major recommendation" how to harmonize it here.

[ManuelQuemerais]

Answer (as shared in Friday's work meeting) is : because we've favored having a single behavior, straightening the standard over the (small) benefits of allowing having multiple refund offers active in parallel.