New version EA

[edwinvandenbelt]

No description provided.

[CGantert345]

OGC should not be used.

[edwinvandenbelt]

Why not? I've created both flavours: the REST (GET /personal-needs/) and the OGC style (GET /collections/personal-needs/items).

[CGantert345]

Don't use OGC

[edwinvandenbelt]

Why not? I've created both flavours: the REST (GET /personal-needs/) and the OGC style (GET /collections/personal-needs/items).

[CGantert345]

Don't use OGC

[edwinvandenbelt]

Why not? I've created both flavours: the REST (GET /personal-needs/) and the OGC style (GET /collections/personal-needs/items).

[edwinvandenbelt]

@Ulf9 "OTI - Search Offers Request.png": We should discuss if this is reflects the technical specification. E.g. the SEARCH OFFER POLICY contains now 'preferredContentLanguageCode'. The technical accepted header field is 'Content-Language'. I'd rather limit the number of possible synonims... Where it's possible, use the accepted standard wordings.

[edwinvandenbelt]

@Ulf9 What do you mean with 'Search locked Offers Amendments Request' and 'Search offer Amends Request'? I'm getting lost in all the amend requests.... And they're still to be discussed in the next phase...

[TOP-PHE]

My comments on BUC-A after a deep ananlysis spending few days reading it and cross checking with input documents.

[TOP-PHE]

The definition for catalogue is exactly the same than the offer.
As per Cambridge dictionnary a catlogue is a list of products... I do assume based on the overall environment the catalogue is a catalogues of offers
In Transmodel terms, this corresponds to a (CUSTOMER OFFER PACKAGE)" — I did not find this element in the Transmodel v6.2 model itself. I downloaded the EA extract from https://transmodel-cen.eu/model6.2/Transmodel2024-EA_extract_for_publication.xml and searched it: CUSTOMER OFFER PACKAGE gives 0 result, while SALES OFFER PACKAGE gives 302 and CUSTOMER PURCHASE PACKAGE gives 249 in the same file with the same search.

[edwinvandenbelt]

Indeed. Is CUSTOMER OFFER PACKAGE a TM concept? Or do you mean the TRAVEL PACKAGE?

[TOP-PHE]

I have 2 comments on the diagram

1. After Sale : This business process is initiated by the traveller, but the finalisation of the after sales is done by the purchaser (in business travel the traveller can decide to not travel and to "give back" the ticket sold before train departure to be in line with after sales condition, but this is the travek agency (the opurchaser who will manage the aftersales itself) meaning for example the refund. We have this split of the sales, why do not we have it on after sales.
2. You are representing the business flow of the fater sales, One flow is lissing on the diagram is the IROPS flow (Irregilar Operations flow) It is triggered by the RU, we do not see in the diagramm while part of the scope of EUDIT.

[edwinvandenbelt]

Hello Patrick, I don't get the first comment. What do you propose to change to this diagram (which is actually a result of CoRoM)?
And the second bullet, I fully agree, but it is not in this diagram since it isn't part of the 'Purchase process'.

[TOP-PHE]

We still have in business requirements reference to transmodel naming convention.
We should have in terminology the link to the transmodel definition anytime a transmodel term is used. And if it is a definition coming from COROM, it should be reviewed and validated as still open question on some of the concepts proposed by COROM and not yet validated by the team (no strong consensus).
COROM is already doing exactly this, we could just do the same. In their clause 3 they put the reference when the term comes from the standard (customer purchase package 3.4 "(EN 12896-5)", fare product 3.7, travel document 3.16, trip 3.21 "(EN 12896-6)"), and they put nothing when it is their own proposal (travel
guarantee 3.17, travel package 3.18, travel party 3.19, travel redress 3.20).
So in COROM you can see immediately what is standard and what is only proposed. We lose this information when we copy the terms into our own terminology.
CUSTOMER OFFER PACKAGE : not defined in Transmodel.md I checked also in the model itself, not only in our extract. I downloaded the Transmodel v6.2 EA extract from https://transmodel-cen.eu/model6.2/Transmodel2024-EA_extract_for_publication.xml and searched it in VS Code : CUSTOMER OFFER PACKAGE gives 0 result. And this is not a search problem : in the same file and with the same search, SALES OFFER PACKAGE gives 302 occurrences and CUSTOMER PURCHASE PACKAGE gives 249.
So these concepts are everywhere in the model and CUSTOMER OFFER PACKAGE is simply not there. It is not in COROM either, and not in our OpenAPI schemas. I maybe missed something.

So Catalogue and Offer, the 2 main terms of this BUC, are both pointing to something which is defined nowhere.

Last point, and it came out of the same check : our Transmodel.md is not complete.
VALIDITY CONDITION and AVAILABILITY CONDITION are not in it, but in the same v6.2
file they are real Transmodel classes ("Condition used in order to characterise a
given VERSION of a VERSION FRAME", and "A VALIDITY CONDITION expressed in terms of
temporal parameters and referring to DAY TYPEs"). This is exactly why we need the
link to the definition and not a copy : if you check only our glossary you
conclude the concept does not exist, and it is wrong.

[edwinvandenbelt]

Bull's eye. I assume that the CUSTOMER OFFER PACKAGE is actually the TRAVEL PACKAGE (to be verified), and that the Catalogue is indeed a list of SALES OFFER PACKAGEs.

And I don't know why the VALIDITY CONDITION and AVAILABILITY CONDITION are lacking from the registered csv; it is a filter on the XML. I'll remove the csv, and will add the XML file instead.

[TOP-PHE]

Travel guarantees: three different things are currently merged under one heading.
Detailed argument, with sources, in support of my comment above.

1. A travel guarantee is a service-quality promise, not a sales condition CoRoM (prCEN/TR XXXX:2025, in wiki/external-resources) defines it at 3.17 as "a promise that a travel service will be provided to a certain quality level and that a TRAVEL REDRESS will be offered if the guarantee is not met". It is breached
   by a TRAVEL EVENT — a disruption (§8.1.6) — and remedied by a TRAVEL REDRESS (3.20).
   CoRoM §6.4 lists exactly four categories: Travel quality, Trip repair, Travel information, Other. Refund, exchange and cancellation are not among them. Those belong to another branch of the model entirely: they are USAGE PARAMETERs of the fare product — EXCHANGING, CANCELLING, and the AR After Sales Usage Parameters MODEL ("conditions on after-sale handling of products").
   They are commercial terms agreed at purchase, not promises about how the service will be delivered.
   The same confusion appears in the API: Guarantee.yaml types a guarantee as refund | exchange | cancel | travel_through. Only travel_through is a travel guarantee in the CoRoM sense; the other three are after-sales conditions, and the Package already carries them separately as afterSalesFlexibility (flexible / semiFlexible / nonFlexible).

2. The guarantees reach further than the PRR, so "aligning the wording with the PRR" is misleading
   Reading CoRoM's "Other" category together with its Table 5, the intent is clearly to cover what else the customer bought in the package, not only the carriage: the illustration given is a vegetarian meal on board, with the redress being alternative food. That is a guarantee on an ancillary.

The PRR does not reach that far, in either version:

• Regulation (EU) 2021/782 applies to the transport contract, defined at Art. 3(6) as "a contract of rail carriage". Its subject matter (Art. 1) is carriage: non-discrimination, liability, accidents, disruption and compensation, information, assistance for persons with disabilities, quality standards, complaints, enforcement. The word "ancillary" does not appear. "Meals" appears once only, at Art. 20(2)(a), as assistance offered free of charge after a delay of 60 minutes or more — and even then qualified, "if they are available on the train or in the station". That is a remedy for disruption, not a guarantee on a purchased service.
• The new package does not extend this. COM(2026) 233 (protection of passengers with single tickets) still refers only to accommodation and refreshments as assistance; COM(2026) 232 (rail ticketing) contains no ancillary or on-board service provisions and defines "ticket" by reference to 2021/782 Art. 3(7). So a guarantee that a purchased ancillary will be delivered is a commercial guarantee, governed by contract and consumer law — not a passenger right.
  Grouping it with the PRR obligations under a single "travel guarantees" heading suggests a legal basis that does not exist.

3. Guarantees are executed through refund and exchange — which is precisely why the two must be named apart.
   Part of the confusion is understandable: when a guarantee is not met, the redress is technically carried out by a refund or an exchange. The operation is the same.
   What differs is the cause and the cost:

• Commercial refund/exchange: initiated by the customer, permitted or not by the fare conditions (EXCHANGING / CANCELLING), and priced — fees, penalties, non-refundable fares.
• Guarantee- or PRR-driven refund/exchange: triggered by a TRAVEL EVENT (disruption, missed connection, service not delivered), owed to the customer, and at no cost — it overrides the commercial conditions instead of applying them.
  If both are simply called "refund" and "exchange", an implementation cannot tell whether the fare conditions apply, whether a fee is due, who bears the cost, or how the case is to be accounted for and settled between operators. This is not a cosmetic point — it is a revenue and settlement issue.
  OSDM addressed this with reason codes on the after-sales operation. OverruleCode is described as "reason for and type of an after sale, code list in IRS 90918-10", with values such as DISRUPTION, CONNECTION_BROKEN, STOP_NOT_SERVED, STRIKE, TECHNICAL_FAILURE, PRM_SUPPORT_UNAVAILABLE and DELAY_COMPENSATION — the last documented as "allows to override conditions in context of passenger rights regulation (PRR)". The name carries the semantics: the code overrules the normal commercial conditions, and the code applied is retained on the result (appliedOverruleCode). PRR reimbursement outside the standard flows has its own separate process and its own ReimbursementReason.
  Worth noting for our scope: OSDM itself records that OverruleCode has "no direct Transmodel equivalent — API-level construct with no domain counterpart in Transmodel". So the mechanism that distinguishes a commercial refund from a guarantee-driven one does not exist on the Transmodel side today. If EUDIT is to
  be backward compatible with OSDM and to carry travel guarantees, it needs toprovide one.

4. Proposal
   Keep three layers explicitly distinct in the BUC, rather than merging them under one heading:
   (a) legal guarantees under the PRR — carriage, disruption, statutory redress;
   (b) commercial service guarantees, including on ancillaries — CoRoM's scope, beyond the PRR, provider-defined;
   (c) sales and after-sales conditions (exchange / refund / cancellation) — USAGE PARAMETERs of the fare product, not guarantees at all.
   And, because (a) and (b) are delivered by means of (c), add a fourth requirement:
   a naming convention and a mandatory reason code on every after-sales operation, making clear whether it applies the commercial conditions or overrides them, and carrying that code through to the result for settlement and reporting.
   This is consistent with the document's own Goal section, which already requires sales conditions to be shown "separately from travel guarantees". It would also make clear to the customer which guarantees are legally owed, which are a commercial promise, and which after-sales operations are chargeable — distinctions the current wording hides.

[edwinvandenbelt]

Makes sence.

would this do the trick?

The types of guarantees should be limited to 'legal' and 'commercial' (maybe extended with subtypes) and the (after-)sales conditions should be reflected in the after-sales flexibility (although, I think we should use a sales-conditions concept, with exchange, refund and cancellation as options; alternative modes don't know the concept of 'flexibility', and - if I understood it correctly - it is not sharply defined as well).

This way we'll have a clear split between the guarantees and (after-)sales conditions. The request to get offers for a cancellation MUST have a 'reason' field, to cope with your bullet 3.2.

[TOP-PHE]

A bit picky comment : Car rental is a ground transportation, does not change the fact that I agree on the fact it is not in the scope,

[edwinvandenbelt]

should we remove 'or car rental'? To avoid unnecessary discussions?

[TOP-PHE]

The way it is structure generate confusion, even if after reading twice I understand the logic, it is not obvious from the first read.
I think if we used indentation for point 4 and 5 insted of keeping them in the list nubering it could help well identifyin the 2 options Trip based versus catalogie

[TOP-PHE]

I think I understand the objective, but it is misleading, because just before we say "Catalogue consultation is a Retailer/Distributor sourcing mechanism". If it is a sourcing mechanism on the Retailer side, then what the Customer sees and browses is not a catalogue, it is a list of offers.
And in fact this sentence says it itself, a few words later : "the Retailer presents priced offers returned by Distributor(s), and the Customer selects among those offers". So the Customer chooses between offers, which is what I would expect.
The problem is that we use the word "catalogue" for 3 different things in 3 consecutive lines :

• line 83 : a sourcing mechanism used by the Retailer/Distributor ;
• line 84 : a sales channel seen by the Customer (we put it in the same list as the travel agency, the distributor desk and the ticket vending machine) ;
• line 86 : a reference static dataset, "which may result from aggregation and harmonisation of one or more Distributor catalogues".

[TOP-PHE]

For me there is a logic problem here from the customer point of view. He selects an item first, and only after he receives the conditions and the guarantees. But the conditions and the guarantees are exactly what he needs to choose.
And this contradicts what we say ourselves :

• the Goal of this BUC : "to choose the most suitable travel offer, with transparent pricing, sales conditions (exchange/refund rules) and travel guarantees" ;
• and the terminology on travel guarantees : "this BUC only requires that the applicable guarantees are made visible and selectable/comparable at offer selection time".
  You cannot compare at selection time something you only receive after having selected.
  I understand there is a technical reason for the 2 steps : line 86 says the initial list can come from "a reference static dataset", and the firm price and the availability really need a real-time request with the Customer context.
  So I am not asking to put everything in the first response. But we should say what can be deferred and what cannot :
• must be in the first response, because these are the selection criteria : the sales conditions (exchange / refund / cancellation) and the travel guarantees, at least at a level allowing comparison, plus an indicative price clearly marked as indicative ;
• can be confirmed in the second step : the firm price, the availability, and the validation of eligibility.
  Otherwise the Customer chooses on the price only and discovers the conditions afterwards, which is what the Goal of this BUC says we want to avoid.

[TOP-PHE]

Two things on this sentence.
First, a price validity period says nothing about availability, and the 2 will be understood as one by the Customer. If we tell him "this price is valid 10 minutes", he understands that the offer is purchasable for 10 minutes. For a yielded fare with a quota this is not true : the price can still be valid and the last place already taken by somebody else.
The sentence covers the case where the price expires, but not the case where the price is still valid and the availability is gone, which is the frequent one in yield management.

Suggestion : distinguish clearly the validity of the price from the availability of the offer, say that a valid price does not guarantee availability, and state whether the price is firm for the Distributor during the validity period. And if wewant to hold the availability too, then it is not a price validity any more, it is
a lock, and it belongs to BUC-B / the lock offer step.

[TOP-PHE]

I do not understand why the Customer would select a shortlist. For me at the end of this BUC he chooses one solution and goes to the purchase. I can imagine cases where a shortlist makes sense (a corporate traveller who proposes options to his manager, or a decision shared with the family), but then it is a different use case and it should be defined in a specific scenario.

And part of the confusion comes from the word itself : "shortlist" is used with 2 different meanings in the document, and it is never defined.
At line 45 it is what the Retailer presents - "the Customer receives one or more candidate offers proposed by the Retailer ... (shortlist: CUSTOMER OFFER PACKAGE(s))".
At lines 11, 56 and here, it is what the Customer selects - "a chosen option or shortlist". So the same word is the list we propose to him and the sub-set he keeps.

If we keep the shortlist as an output of this BUC, we must say :

• how long it lives ;
• whether the prices and the availability are held for the items of the shortlist, or not. This sentence already says that "all or part of the offer has expired", so I understand nothing is held, and then the shortlist has no operational value ;
• how we go from a shortlist to a purchase, because we cannot buy a shortlist.

My preference : the output of this BUC is one selected offer, the shortlist is only a Retailer display matter, and everything which is "several offers kept together" goes to BUC-B.

[Copilot]

Pull request overview

Introduces draft business use cases, reusable OpenAPI components, lookup APIs, interoperability mappings, and test documentation for search and lock-offer workflows.

Changes:

• Adds and archives business use-case documentation.
• Adds modular OpenAPI schemas, request/response components, and headers.
• Adds lookup specifications, mappings, guidelines, and test-case documentation.

Reviewed changes

Copilot reviewed 95 out of 124 changed files in this pull request and generated 39 comments.

Show a summary per file

File	Description
wiki/use-cases/business-use-cases/BUC-LETTER-main-feature-TEMPLATE.md	Adds a BUC template.
wiki/use-cases/business-use-cases/BUC-J-After-Trip (Aftersales & Claims).md	Defines post-trip servicing scenarios.
wiki/use-cases/business-use-cases/ARCHIVE/business_use-case_format.md	Archives the prior BUC format.
wiki/use-cases/business-use-cases/ARCHIVE/buc-e-fulfilment.md	Archives draft fulfilment content.
wiki/use-cases/business-use-cases/ARCHIVE/buc-d-pay.md	Archives payment use-case details.
wiki/use-cases/business-use-cases/ARCHIVE/buc-a-inspire-and-plan.md	Archives planning use-case details.
deliverables/usecases-to-endpoints.md	Maps BUCs to API endpoints.
deliverables/openapi/oti.yaml	Adds the modular OpenAPI root.
deliverables/openapi/components/schemas/Warning.yaml	Defines warning payloads.
deliverables/openapi/components/schemas/VehicleRack.yaml	Defines vehicle racks.
deliverables/openapi/components/schemas/TripPattern.yaml	Defines trip patterns.
deliverables/openapi/components/schemas/TravelRight.yaml	Defines travel rights.
deliverables/openapi/components/schemas/TravellingParty.yaml	Defines travelling parties.
deliverables/openapi/components/schemas/TravellingEntityPlaceHolder.yaml	Defines entity placeholders.
deliverables/openapi/components/schemas/TravellingEntity.yaml	Defines travelling entities.
deliverables/openapi/components/schemas/TravellerQualifyingCharacteristics.yaml	Defines traveller eligibility data.
deliverables/openapi/components/schemas/Traveller.yaml	Defines traveller payloads.
deliverables/openapi/components/schemas/TravelDocument.yaml	Defines travel documents.
deliverables/openapi/components/schemas/TransferLeg.yaml	Defines transfer legs.
deliverables/openapi/components/schemas/TopologicalPlaceInput.yaml	Defines area-based places.
deliverables/openapi/components/schemas/TimedLeg.yaml	Defines timetabled legs.
deliverables/openapi/components/schemas/Tax.yaml	Defines tax values.
deliverables/openapi/components/schemas/SummaryDetail.yaml	Defines offer summaries.
deliverables/openapi/components/schemas/StopPlaceInput.yaml	Defines stop-place inputs.
deliverables/openapi/components/schemas/Section.yaml	Defines journey sections.
deliverables/openapi/components/schemas/SeatAllocation.yaml	Defines seat allocations.
deliverables/openapi/components/schemas/Redress.yaml	Adds a redress placeholder.
deliverables/openapi/components/schemas/PurchasedPackage.yaml	Defines purchased packages.
deliverables/openapi/components/schemas/Product.yaml	Adds a product placeholder.
deliverables/openapi/components/schemas/PriceableObject.yaml	Defines priceable objects.
deliverables/openapi/components/schemas/Price.yaml	Defines prices.
deliverables/openapi/components/schemas/PointOfInterest.yaml	Defines points of interest.
deliverables/openapi/components/schemas/PlaceHolder.yaml	Defines information placeholders.
deliverables/openapi/components/schemas/Place.yaml	Defines geographic places.
deliverables/openapi/components/schemas/PassengerVehicle.yaml	Defines transported vehicles.
deliverables/openapi/components/schemas/PackageElement.yaml	Defines package elements.
deliverables/openapi/components/schemas/Package.yaml	Defines offer/package composition.
deliverables/openapi/components/schemas/OfferElement.yaml	Defines offer elements.
deliverables/openapi/components/schemas/Offer.yaml	Defines offers.
deliverables/openapi/components/schemas/Luggage.yaml	Defines luggage entities.
deliverables/openapi/components/schemas/LockedOffer.yaml	Aliases locked offers.
deliverables/openapi/components/schemas/Link.yaml	Defines hypermedia links.
deliverables/openapi/components/schemas/LegBoard.yaml	Defines boarding events.
deliverables/openapi/components/schemas/LegAlight.yaml	Defines alighting events.
deliverables/openapi/components/schemas/Leg.yaml	Defines base journey legs.
deliverables/openapi/components/schemas/Guarantee.yaml	Defines package guarantees.
deliverables/openapi/components/schemas/GeoPosition.yaml	Defines coordinates.
deliverables/openapi/components/schemas/Fulfillment.yaml	Defines fulfilment details.
deliverables/openapi/components/schemas/Fee.yaml	Defines fees.
deliverables/openapi/components/schemas/EntitlementRight.yaml	Defines entitlement credentials.
deliverables/openapi/components/schemas/ContinuousLeg.yaml	Defines non-timetabled legs.
deliverables/openapi/components/schemas/AssetAllocation.yaml	Defines asset allocations.
deliverables/openapi/components/schemas/Animal.yaml	Defines animal entities.
deliverables/openapi/components/schemas/AncillaryPlaceHolder.yaml	Defines ancillary placeholders.
deliverables/openapi/components/schemas/Ancillary.yaml	Defines ancillary elements.
deliverables/openapi/components/schemas/AllocationPlaceHolder.yaml	Defines allocation placeholders.
deliverables/openapi/components/schemas/AddresInput.yaml	Defines address inputs.
deliverables/openapi/components/responses/SearchOfferDelivery.yaml	Defines search delivery data.
deliverables/openapi/components/responses/LockOfferDetailsDelivery.yaml	Aliases lock-detail responses.
deliverables/openapi/components/responses/LockOfferDelivery.yaml	Defines lock response metadata.
deliverables/openapi/components/requestBodies/SearchOfferRequest.yaml	Defines search requests.
deliverables/openapi/components/requestBodies/LockOfferRequest.yaml	Defines lock requests.
deliverables/openapi/components/headers/version.yaml	Defines the version header.
deliverables/openapi/components/headers/expires.yaml	Defines the expiry header.
deliverables/openapi/components/headers/content-language.yaml	Defines content language.
deliverables/openapi/components/headers/authorization.yaml	Defines authorization input.
deliverables/openapi/components/headers/accept-language.yaml	Defines language preferences.
deliverables/guide-lines/enums.md	Documents enum and lookup usage.
deliverables/6 after sales/possibilities.md	Lists after-sales operations.
deliverables/2b amend offer/possibilities.md	Outlines offer-amendment operations.
deliverables/2 lock offer/test cases/test-cases.md	Documents lock-offer test cases.
deliverables/2 lock offer/mappings/mapping-tomp.md	Maps locking to TOMP.
deliverables/2 lock offer/mappings/mapping-tm.md	Maps locking to Transmodel.
deliverables/2 lock offer/mappings/mapping-osdm.md	Maps locking to OSDM.
deliverables/2 lock offer/mappings/mapping-omsa.md	Maps locking to OMSA.
deliverables/2 lock offer/mappings/mapping-fgw.md	Maps locking to FerryGateway.
deliverables/2 lock offer/mappings/mapping-bob.md	Maps locking to BoB.
deliverables/2 lock offer/lookup.yaml	Adds lock-offer lookup endpoints.
deliverables/1 search offers/to do.md	Records remaining search work.
deliverables/1 search offers/test cases/test-cases.md	Documents search test cases.
deliverables/1 search offers/mappings/mapping-omsa.md	Maps search to OMSA.
deliverables/1 search offers/mappings/mapping-fgw.md	Maps search to FerryGateway.
deliverables/1 search offers/mappings/mapping-bob.md	Maps search to BoB.
deliverables/1 search offers/lookup.yaml	Adds search lookup endpoints.
.gitignore	Adds local exclusions.

Suppressed comments (1)

deliverables/2 lock offer/test cases/test-cases.md:200

• This section again describes two POST detail operations and a request body, but the API exposes GET detail endpoints and no LockedOfferDetailRequest schema. TC-009 therefore cannot be implemented against the added specification; rewrite it around the lockedOfferId path/query parameters of the GET endpoints.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.