How to exchange only passenger details

[benys]

Dear OSDM Team

I have a scenario: a) after fulfillment, passenger discover that have to change passenger/purcharser details b) passenger doesn't want to change any other details like trip, offer etc.

It is any way to exchange passenger details without defining from start trip, offers etc? I found API related with passenger - but API specified that it should be used during booking.

Kamil

[jspetrak]

Hello, It depends on what passenger information you want to change. Any change of age, birtdate, reduction card would trigger re-pricing and will certainly be prohibited. In that case, the better option is to start exchange process.

If we talk about name change or adding contact details, PATCH /bookings/{bookingId}/passengers/{passengerId} could be also called on fulfilled booking. But that always depends on the API provider if allows such modification. E.g. airlines have fee associated with the name change so again, there would need to be an exchange process or other activity where fee may be formally offered, accepted, and paid.

Please let us know what passenger details would you like to allow be changed.

[benys]

My scenario is first name and last name. In out case - the first exchange is free. But from the ticket side - requirement is that we need to create new fulfillment. So it tricky for me use this API... because in result API.

I had idea, that exchange offer API should have option to change passenger details without defining trips other "specifications".

[jspetrak]

Exchange flow that "just" updates passenger details and the exchange is either free or for a fee would be good. I like that idea.

Could you join any Friday 9-11 Central European Team on the technical group call to present this idea? Different carriers and vendors meet to discuss the issues. They may present how they do this at the moment, or we can accept the idea and design the solution.

[jspetrak]

There are more operators anticipating this. We would like to organize a call, discuss different needs, and design either improvement of exchange flow or completely different flow for this use case based on gathered requirements. Please reach out to tech. group to be involved.

[benys]

Hello,

Can you share more information, how to join the meeting on Friday?

On Fri, Sep 27, 2024 at 9:54 AM Josef Petrák @.***> wrote:

There are more operators anticipating this. We would like to organize a call, discuss different needs, and design either improvement of exchange flow or completely different flow for this use case based on gathered requirements. Please reach out to tech. group to be involved.

— Reply to this email directly, view it on GitHub https://github.com/UnionInternationalCheminsdeFer/OSDM/issues/699#issuecomment-2378642564, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAENW5BSKFTG5TQVA2OR47TZYUFJXAVCNFSM6AAAAABOUPQS4GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZYGY2DENJWGQ . You are receiving this because you were assigned.Message ID: @.***>

-- Pozdrawiam Kamil

[CGantert345]

The link to the meeting is in the meeting minutes: https://github.com/UnionInternationalCheminsdeFer/OSDM/wiki/meeting-minutes

[benys]

@CGantert345 i tried few times to connect to the meeting. (18.10, 17.10, 11.10 at 9:00 CEST) :-( When will be next meeting?

[rolandkla]

An exchange is, as the name suggests, changing a current ticket to a new ticket. That means that there needs to be availability of the new ticket. If you want to do a name change through an exchange, that can lead to issues if the train is fully booked for which you already have a ticket, because then you will not get any offers back.

In my opinion changing passenger details through an exchange does not make sense. It is also not possible to passenger details during the exchange flow as the concept to change passenger details in OSDM is through PATCH /bookings/{bookingId}/passengers/{passengerId}

We should also prevent having different ways to change passenger details depending whether a fee is calculated or not. It would be inconsistent when providers A and B supports the PATCH passenger but with provider C you need to go through an exchange process.

A new ticket can be the result of the name change, a client should not implement different logic depending what result is given by a specific operator.

[jspetrak]

@rolandkla PATCH /bookings/{bookingId}/passengers/{passengerId} is currently permited for PREBOOKED bookings. Or, well, documentation says "at booking step" which is quite vague.

So, if we ignore the feature of monetization, we could use Cancel Fulfillment, return the booking to CONFIRMED state and then allow to PATCH passengers and Fulfill the booking again to get new documents.

[rolandkla]

@jspetrak , yes and that flow would not fit if there needs to be support for passenger change fee's. As with any offer, it requires a provisional step and then an explicit confirmation based on a returned offer.

I recommend we (as in all of us ;) ) gather the requirements, how it interacts with the existing flows and design with the "knowns" in mind. For example:

• exchange to the same service on a different travel date
• exchange to a different service on the same date
• exchange to the same service on same date to upgrade to a different travel class / flex level / compartment type / etc
• change passenger type (eg adult -> child)
• change passenger details (eg name correction, different person)
• exchange 1 fulfillment for 1 passenger to 5 passengers (is that even an exchange or just use POST /bookings/{id}/booked-offers?)
• etc

And from there have clear guidelines which scenario is supported in which flow. Now it can be anything because the exchange offers request is flexible, but yet limited -> harmonisation is extremely difficult with open interpretations ;)

[jspetrak]

@rolandkla agreed.

[TOP-PHE]

Joshi: In case of exchange on train ID/Depart date or Pax name, the exchange flow will be used tod o this exchange as documents change. Josef: The issue is that potentially changing the name with this flow cannot garantie that the seat number is kept as we restart from a new offer... The goal is to find a short cut allowing to keep the booked parts that does not change and only modify what need to be changed and re issuing a new fullfilment .

The processes above from Roland has an impact on the price that could trigger a new offer request...but some other (like name change could not have impact on price) and in this case a short cut flow is welcome. Same shortcut could be used for an upgrade from 2nd to 1st class. Some Railways used a supplement on top of the original ticket. In Swiss this is the way is done.

One use case in case of class of service is to bundle different trains in a global offer requesting for 1st class but some trains are only second. In this case the railway sell a full 2nd class trip plus supplements for trains with 1st.. In OSDM, ths supplement will be which kind of offerpart "ancillary" "admission"... as some railway call it supplement.... In Sweden it is an ancillary For SBB, ancillary is used for added value on top of the admission, thus more an admission.

Could we have multiple admissions in this case for one train ? Semantically possible, but not what we would like to have.... No need to create a new type of offerpart 'supplement" ancillary is good enough SBB will check if they can manage as ancillary. To be checked with Andreas should be reviewed with others too.