BUC B: lock & amend offers - #79
Conversation
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
| - **Context**: This use case describes **the pre-purchase offer discovery** phase for ground transport. It focuses on how a **Retailer** helps a **Customer /Traveller** identify suitable travel options by interacting with one or more **Distributors/Operators** and presenting comparable results. It does **not describe the retailer’s end-customer user interface** in detail, and it does **not cover non-ground content** such as flights, hotels or car rental. | ||
| - **Primary Actor: Customer** (end customer) (TRANSPORT CUSTOMER ROLE and PURCHASER ROLE**) :** the person who expresses the needs and makes choices to purchase offers suited to travel needs. He can act for one or several Travellers (be the manager of a group, a PRM, the purchaser for a minor traveller or other with specific needs or none). The Customer may also be the traveller (i.e. the person who will actually travel and use the entitlement) (PASSENGER ROLE). | ||
| - **Supporting Actors:** | ||
| - **Retailer (**FARE PRODUCT RETAILER ROLE) (API consumer): supports the Customer queries, initiates catalogue consultation, aggregates and presents options and support comparison (ranking / filtering). See Role schema: orange rectangle on the right) |
There was a problem hiding this comment.
initiates catalog consultation is unclear and should be deleted as there is no catalog exchanged. Better: "Initiates Distributor Consultation" which would still need a description.
There was a problem hiding this comment.
Maybe improve the text, but I think catalog consultation is relevant for many types of sales, e.g. local public transport .
There was a problem hiding this comment.
catalog exchange is not needed, modern imle3mentations will always use apis and no catalog. There might still be legacy applications out thre with data exchange, but that is not interoperable and not an EUDIt use case.
There was a problem hiding this comment.
From RETAILER to CLIENT, yes, but for RETAILER this may be the case.
| - **Primary Actor: Customer** (end customer) (TRANSPORT CUSTOMER ROLE and PURCHASER ROLE**) :** the person who expresses the needs and makes choices to purchase offers suited to travel needs. He can act for one or several Travellers (be the manager of a group, a PRM, the purchaser for a minor traveller or other with specific needs or none). The Customer may also be the traveller (i.e. the person who will actually travel and use the entitlement) (PASSENGER ROLE). | ||
| - **Supporting Actors:** | ||
| - **Retailer (**FARE PRODUCT RETAILER ROLE) (API consumer): supports the Customer queries, initiates catalogue consultation, aggregates and presents options and support comparison (ranking / filtering). See Role schema: orange rectangle on the right) | ||
| - **Distributor** (FARE PRODUCT DISTRIBUTOR ROLE) (API provider): provides the data and content to build timetable, fare catalogue, prices, availabilities, and guarantees. |
There was a problem hiding this comment.
Time table data could be provided by a third party.
| - **Primary Actor: Customer** (end customer) (TRANSPORT CUSTOMER ROLE and PURCHASER ROLE**) :** the person who expresses the needs and makes choices to purchase offers suited to travel needs. He can act for one or several Travellers (be the manager of a group, a PRM, the purchaser for a minor traveller or other with specific needs or none). The Customer may also be the traveller (i.e. the person who will actually travel and use the entitlement) (PASSENGER ROLE). | ||
| - **Supporting Actors:** | ||
| - **Retailer (**FARE PRODUCT RETAILER ROLE) (API consumer): supports the Customer queries, initiates catalogue consultation, aggregates and presents options and support comparison (ranking / filtering). See Role schema: orange rectangle on the right) | ||
| - **Distributor** (FARE PRODUCT DISTRIBUTOR ROLE) (API provider): provides the data and content to build timetable, fare catalogue, prices, availabilities, and guarantees. |
There was a problem hiding this comment.
a fare catalog is not provided. prices, availabilities and gauarntees are not provided as such but integrated in offers.
There was a problem hiding this comment.
For public transport it is, no need for get an offer in many cases, so not agree on this comment
|
|
||
| ## Preconditions & Postconditions | ||
| - **Assumptions and Preconditions (must be true before start):** | ||
| - Commercial agreements are in place: Access to the Distributor’s catalogues are available to the Retailer. Some offers may be restricted. |
There was a problem hiding this comment.
Thee is no access to a catalog provided. The access to the distributors API needs to be provided, but that is not a acatalog.
There was a problem hiding this comment.
Not agree on this, the catalog is provided.
|
|
||
| ## Preconditions & Postconditions | ||
| - **Assumptions and Preconditions (must be true before start):** | ||
| - Commercial agreements are in place: Access to the Distributor’s catalogues are available to the Retailer. Some offers may be restricted. |
There was a problem hiding this comment.
That offers might be restricted is not a precondition.
| - **Assumptions and Preconditions (must be true before start):** | ||
| - Commercial agreements are in place: Access to the Distributor’s catalogues are available to the Retailer. Some offers may be restricted. | ||
| - The relevant content (for the distributor/network/area) sources are identified: the Retailer can determine which Distributor(s) to query for the requested trip (this may involve one or several sources depending on the journey). | ||
| - The catalogue exists and is available as a pre-loaded/static reference dataset; availability and final price confirmation (when required) are performed through the responsible Distributor systems. |
There was a problem hiding this comment.
a catalog is not required.
There was a problem hiding this comment.
The catalog will provide information on where the price engine etc. is available, so not sure if I agree on this comment
| - The relevant content (for the distributor/network/area) sources are identified: the Retailer can determine which Distributor(s) to query for the requested trip (this may involve one or several sources depending on the journey). | ||
| - The catalogue exists and is available as a pre-loaded/static reference dataset; availability and final price confirmation (when required) are performed through the responsible Distributor systems. | ||
| - The Customer/Traveller can provide the minimum additional information required to propose relevant options (e.g. origin/destination or travel area, timing/frequency, passenger profile/eligibility, preferences) the best offer | ||
| - Basic travel intent is known (at minimum: the customer wants to travel; optionally: zone/route/date/passenger profile), focused on ground-transport distribution. |
There was a problem hiding this comment.
zone/route come from the travel planner as a journey, not as the Tone or Route objects from fares.
There was a problem hiding this comment.
Not all purchases need a travel search, for public transport you can purchase from a zone map or similar without the need for travel search
| - The catalogue exists and is available as a pre-loaded/static reference dataset; availability and final price confirmation (when required) are performed through the responsible Distributor systems. | ||
| - The Customer/Traveller can provide the minimum additional information required to propose relevant options (e.g. origin/destination or travel area, timing/frequency, passenger profile/eligibility, preferences) the best offer | ||
| - Basic travel intent is known (at minimum: the customer wants to travel; optionally: zone/route/date/passenger profile), focused on ground-transport distribution. | ||
| - **T**hird-party products may be included only when they are distributed through the same Distributor(s) in scope (i.e. provided as part of the Distributor’s content/offers). Third-party products delivered outside that distribution scope are not covered here. |
There was a problem hiding this comment.
the meaning of included is unclear
| - **Postconditions — Success guarantees:** | ||
| - The Customer receives one or more candidate offers proposed by the Retailer and sourced from one or more Distributors (shortlist: CUSTOMER OFFER PACKAGE(s)). | ||
| - For each candidate offer, the Customer can see: | ||
| - offer content and his packaging (FARE PRODUCT(s), SALES OFFER PACKAGE(s)) |
There was a problem hiding this comment.
The fare products are not exposed
| - validity constraints (e.g. zone, time window), | ||
| - eligibility requirements (e.g. reduction card, corporate entitlement), | ||
| - combination/combinability rules (e.g. outward must be part of a return trip), | ||
| - and after-sales conditions (exchange/refund/cancellation). (VALIDITY CONDITION(s), ENTITLEMENT(s), OFFER RULE(s), USAGE PARAMETER(s): EXCHANGING / REFUNDING / CANCELLING), |
There was a problem hiding this comment.
VALIDITY CONDITION(s), ENTITLEMENT(s), OFFER RULE(s), USAGE PARAMETER(s): EXCHANGING / REFUNDING / CANCELLING
this seems to refere to the NeTEx model which is not useable in the API as it is a static model.
There was a problem hiding this comment.
This is Transmodel terms, not NeTEx
| - eligibility requirements (e.g. reduction card, corporate entitlement), | ||
| - combination/combinability rules (e.g. outward must be part of a return trip), | ||
| - and after-sales conditions (exchange/refund/cancellation). (VALIDITY CONDITION(s), ENTITLEMENT(s), OFFER RULE(s), USAGE PARAMETER(s): EXCHANGING / REFUNDING / CANCELLING), | ||
| - availability information (where applicable) (e.g. mandatory reservation, remaining capacity). (AVAILABILITY CONDITION) |
There was a problem hiding this comment.
applies to optional reservations as well.
| - the total price of the basket, | ||
| - the quotation validity periods applicable to each concerned, | ||
| - any validity extension possibilities, | ||
| - the key conditions and constraints attached to each element and to the basket as a whole or only part of it (USAGE PARAMETER(s), VALIDITY CONDITION(s)). |
There was a problem hiding this comment.
USAGE PARAMETER(s), VALIDITY CONDITION(s). The data models will be different for an API.
| - send the relevant updates requests to the concerned Distributor (including retailer's basket if required), where distributor-side processing is required; | ||
| - create or update the corresponding basket element (TRAVEL BASKET ELEMENT); | ||
| - evaluate dependencies between basket elements when required to assure the consistency of the basket and inform the Customer of the consequences; | ||
| - retrieve the resulting price, validity and applicable conditions for presentation (PRICE). |
There was a problem hiding this comment.
resulting price, validity and applicable conditions for presentation (PRICE). --> resulting package including ...
| - send the relevant update request to the concerned Distributor(s), where required, | ||
| - retrieve the updated offer details, price, validity period and other applicable conditions, | ||
| - evaluate dependencies between basket elements and prepares consequences for the Customer if other elements are impacted, | ||
| - retrieve the resulting price, validity period and applicable conditions for presentation to the Customer. |
There was a problem hiding this comment.
it is always the package that is retrieved
| > The travel basket is based on offers with no block of price bucket or seat. so a travel basket keeping can enlarge the chance of failure at provisional booking step in use case C. If this means a provisional booking, then we should move this to use case C | ||
|
|
||
| > **Comment (Bourdelin, Sonia, 2026-05-19):** | ||
| > In BUC-B we only state that such a hold may be required and that the basket is updated with the resulting status/constraint. But provisonnal booking is not a mandatory step in BUC-B |
There was a problem hiding this comment.
only pre-booked offers can be modified, thus a pre-booking is mandatory.
| > **Comment (Bourdelin, Sonia, 2026-05-19):** | ||
| > Added in step 2 | ||
| This is an example of group quotation flow; it is not mandatory for all implementations. | ||
| 1. The Customer is welling to purchase for a group of travellers, larger than what it is proposed in the catalogue. The Customer submits a specific group offer request, for example, by email for a group quotation (specific channel). |
There was a problem hiding this comment.
There is no catalog. The request for an offer might result in an error indicating that the group size requested can only be booked in a manual process. The manual process is out of scope.
|
|
||
|
|
||
| > **Comment (Bourdelin, Sonia, 2026-05-26):** | ||
| > I would add once here the list of the concepts : available reservation/facility options, constraints per leg/operator, price where applicable, and availability status |
There was a problem hiding this comment.
available reservation/facility options: facility options--> ancillary options
facility is a concept of the travel planner and informs on facilities on a service/bus/train regardless whether they need to be bought (e.g. a bistro is a train facility, but you can't buy the bistro).
|
|
||
| > **Comment (Bourdelin, Sonia, 2026-05-21):** | ||
| > and in some cases, Retailer or Distributor can propose alternatives | ||
| - Customer can select seat preferences (window/aisle, facing direction, quiet zone, power socket, legroom) depending of each operator. |
There was a problem hiding this comment.
This depends on the leg. An ÖBB night trains and a feeding ÖBB day train have different preferences.
| - In case of reservation only, this step can take place based on trip only selection in use case A, where reservation only was selected. | ||
|
|
||
| > **Comment (BIGEX Olivier, 2026-05-11):** | ||
| > To be developped here: the customer can resquest a reservation only, if he already has a valid fare contract (e.g. a pass or a single ticket). But to do that, he shall prove that he has a valid fare contract (or retrieved by the retailer) |
There was a problem hiding this comment.
The prove is usually done via the control on board. The cases where you need a validation at sales time are very rare.
|
|
||
| > **Comment (BIGEX Olivier, 2026-05-21):** | ||
| > Indeed. We could consider that this proof process is an internal process of the distributor/fare provider. But at least the related travel right could (not mandatory) be added as customer context (booking/ticket ref ?). | ||
| It is possible this step is done as part of SALES OFFER PACKAGE selection in use case A |
There was a problem hiding this comment.
--> Customer Offer Package?
There was a problem hiding this comment.
SALES OFFER PACKAGE is correct; there is no CUSTOMER OFFER PACKAGE in Transmodel as I understand
|
|
||
| > **Comment (BIGEX Olivier, 2026-05-27):** | ||
| > Ok with this reformulation | ||
| - The RETAILER requests for preliminary booking of the selected CUSTOMER OFFER PACKAGE(s) by requesting the SALES OFFER PARTS at all relevant DISTRIBUTOR(s) |
There was a problem hiding this comment.
There are no Sales Offer Parts requested.
|
|
||
| > **Comment (Bourdelin, Sonia, 2026-05-21):** | ||
| > Yes, in BUC-D is is explained also. Refers to BUC. But it is clearer to spoke about that in both cases for me | ||
| - The Distributor finalizes the sale of all SALES OFFER PARTS with all operators and confirms the completed booking to the Retailer. |
There was a problem hiding this comment.
The TRansmodel concepts get confused here. The distributor always provides a Customer Purchase Package, the Sales Offer Package is a Netex Object that never apears in an API.
There was a problem hiding this comment.
SALES OFFER PACKAGE is a Transmodel term
There was a problem hiding this comment.
SALES OFFER PACKAGE is a Transmodel term
Yes, but it is the wrong one the Transmodel term is Customer Purchase Package.
There was a problem hiding this comment.
Correct, and the CUSTOMER PURHCASE PACKAGE contains (may) one SALES OFFER PACKAGE
| - **Goal (Objective):** Enable the Customer to obtain travel access rights resulting of what he purchased, reserved and paid. His mobility contract(s) must be created according to the confirmed offers. The customer may also receive the appropriate supports/media (can be inspected). | ||
| - **Scope (Summary) :** | ||
| - Confirmation that selected offer(s) / basket element(s) are ready for fulfilment, | ||
| - Retailer request to Distributor for fulfilment constraints, supported fulfilment methods and required data |
There was a problem hiding this comment.
Fulfillment constraints need to be handleled in BUC-A, otherwise you end up with payed packages that cannot be fulfilled.
| - Distributor response with document, token, account/media update, retrieval reference, delivery reference, tele-distribution of all required media, or pending/failed status with management of delayed distributions, | ||
| - Coordination with reservation process (confirmation of contract creation and fulfilment, data exchange, failure management), | ||
| - Consolidation of fulfilment status by the Retailer and provision of the final fulfilment result to the Customer, | ||
| - Management of fulfilment failure, partial fulfilment, delayed fulfilment, reissue or cancellation before delivery |
There was a problem hiding this comment.
cancellation before delivery should go to the after sales use case (refund) as it is not related to fulfillment.
| - The contracts are created and ready to be used. | ||
| - The Customer has received appropriate: | ||
| - travel right (**FARE CONTRACT** or equivalent access right) is created, confirmed or updated, | ||
| - travel evidence (**TRAVEL DOCUMENT**) or equivalent, account/media/retrieval reference is created or made available |
There was a problem hiding this comment.
There are cases where the travel document is not created at this point. E.g. passes where you need to activate specific travel dates lateron.
|
|
||
| - **Other retailer/distributor-facing Actor :** where applicable | ||
| - **Media and Medium Application Provider** (MEDIA PROVIDER ROLE, MEDIUM APPLICATION PROVIDER ROLE) : May load or activate a physical or digital support, such as a smartcard, NFC mobile application, RFID token or wallet. | ||
| - **Fulfilment Provider** / Document Generator (FARE PRODUC ISSUER ROLE) : May generate a barcode, QR code, Aztec code, PDF, BoB BCT token, wallet pass, collection reference or other document artefact. |
There was a problem hiding this comment.
This is a security provider role, niot an issuer role (issuer is a legal term in public transport and should not be used in other meanings)
| - **Assumptions and Preconditions (must be true before start):** | ||
| - Payment phase has ended with a known payment or confirmation status for the concerned basket element(s) and even zero-amount basket element are ready for fulfilment. | ||
| - The Retailer knows which Distributor is responsible for each selected offer with its fulfilment rules (immediate fulfilment, delayed fulfilment, account update, media loading, collection, physical delivery, or no separate document because the right is account/media-based.) | ||
| - Distribution channel is chosen by customer and accessible, even asynchronously. |
There was a problem hiding this comment.
Distribution channel usually has a different meaning as it is the channel used for the sales. Terms should not be mixed.
| Examples: | ||
| - generate PDF / mobile ticket / barcode / QR code; | ||
| - generate wallet pass; | ||
| - prepare customer account update; | ||
| - perform NFC loading if delegated; | ||
| - create a collection reference; | ||
| - produce a customer-facing document combining several Distributor results. | ||
| 8. The Retailer sends a fulfilment notification or registration request to the Distributor (what has been done and status). The Distributor validates and records the fulfilment result. The Retailer informs the Customer with fulfilment status accordingly. |
There was a problem hiding this comment.
the retailer will not generate mobile ticket / barcode / QR code, he might format them for printing in some special cases (e.g. combining multiple pdfs into one or formatting signed data in a qr code).
| - email attachment; | ||
| - mobile ticket; | ||
| - wallet pass; | ||
| - barcode / QR code; |
There was a problem hiding this comment.
a QR code is a barcode
| - If the delayed fulfilment fails, the Distributor returns the business consequence and next possible action. | ||
| - | ||
| **Cancellation before distribution** | ||
| - A fulfilment operation must be cancelled before the travel evidence / support is distributed or before the travel right becomes usable. The Retailer requests cancellation before distribution from the Distributor. |
There was a problem hiding this comment.
This should be part of the refund use case. There needs to be the option to cancel for technical or legal reasons or sales staff error imediately after the confirmation, but this does not depend on the fulfillment not yet created.
| > **Comment (Bourdelin, Sonia, 05/27/2026):** | ||
| > Please put the steps in the temporal order : add a step where the retailer request for the distributor for the cancellation conditions deleguated (to the retailer) | ||
| > Add precision if the authorization is/must be requested in real-time (additional step) and if there is an overrule | ||
| - The customer is informed if transport contract cannot be partially cancelled. |
There was a problem hiding this comment.
This is the refund offer step. There is no additional step to ask whether a refund offer would be possible.
|
|
||
| > **Comment (Bourdelin, Sonia, 2026-05-27):** | ||
| > Enlarge : cancellation possibilities : full, partila , not allowed, with fees, .. | ||
| - The customer is informed of all applicable rules of cancellation in full and in plain language so the customer can make an informed decision. |
There was a problem hiding this comment.
THe customer is informed on the refund offer, not on a list of applicable rules.
|
|
||
| > **Comment (Bourdelin, Sonia, 2026-05-27):** | ||
| > Enlarge : cancellation possibilities : full, partila , not allowed, with fees, .. | ||
| - The customer is informed of all applicable rules of cancellation in full and in plain language so the customer can make an informed decision. |
There was a problem hiding this comment.
On partial refund the customer asks for partial refund providing the parts to be refunded. It is useless to provide information on parts that he does not want to refund.
|
|
||
| > **Comment (Bourdelin, Sonia, 2026-05-27):** | ||
| > c and d are the same step ? or it is done with 2 different ways and steps ? | ||
| - The customer confirms the cancellation. If the transport contracts are stored in system, they are cancelled by the concerned distributors, and the travel documents are useless (can be destroyed if disposable). If the transport contracts are stored in an NFC smartcard, the card content must be successfully updated on an eligible device. If the transport contracts are stored on secured (paper) travel documents, the travel documents must be returned to the retailer. |
There was a problem hiding this comment.
depending on the fulfillments this might include to issue new fulfillments for the remaining parts (e.g. a new ticket with less travellers)
|
|
||
| > **Comment (Bourdelin, Sonia, 2026-05-28):** | ||
| > two responsibility models | ||
| - The customer is informed of all applicable rules of exchange in full and in plain language so the customer can make an informed decision. |
There was a problem hiding this comment.
The customer is informed on the exchange offers, not on fare rules.
| > **Comment (Bourdelin, Sonia, 2026-05-28):** | ||
| > two responsibility models | ||
| - The customer is informed of all applicable rules of exchange in full and in plain language so the customer can make an informed decision. | ||
| - The customer selects and confirms an exchange offer (BUC-C). The initial reservation(s) are released once the exchange confirmation is successful. |
There was a problem hiding this comment.
The customer selects and confirms an exchange offer (BUC-C): The exchange offer might require alls steps similar to BUC-B as well: selecting new seats for reservation, adding passenger information for added passengers,.. . On this step the exchange offer would be locked, and would be confirmed laoeron.
|
|
||
| > **Comment (Bourdelin, Sonia, 2026-05-27):** | ||
| > commercial agreements between distributor(s) and retailer(s). The dependencies between offers can be part of the D data sent to R (commercial profil required, etc ..). But it could be (urban transport) the distributor that calculates the cohabitation rules and the dependencies and the final acceptance (or not) of the new offer | ||
| - The distributor can apply support automatic journey continuation (AJC), re-pricing a journey when a customer extends travel beyond the originally booked destination. In that case, new transport contracts can concern the new offer and initial transport contracts. |
There was a problem hiding this comment.
that would be an exchange
|
|
||
| > **Comment (Bourdelin, Sonia, 2026-05-27):** | ||
| > relevant | ||
| - The new booked offers are included in the initial trip (depending of the booked offers, the aggregation is done by the retailer or the distributor). |
There was a problem hiding this comment.
included in the initial trip: --> basket? The trip does not include booked offers
| Independent alternative scenarios **fully compatible** with the main scenario; using shortcuts or very detailed specific points of the main scenario. | ||
|
|
||
| - **Simple CBT / document centric ticket withaftersales conditions included in shared dataset** | ||
| - After having retrieved transport contract information by reading the travel document, the retailer can inform directly the customer about aftersales conditions based on shared dataset of products. Then the customer can proceed to the Cancel/Exchange request, without asking the distributor previously for aftersales conditions on this transport contract. |
There was a problem hiding this comment.
without asking the distributor previously for aftersales conditions on this transport contract: There is no extra step to ask for conditions, you ask for the refund offer and confirm it.
|
|
||
| B) Claims, disputes, passenger rights servicing | ||
| 5. Create and manage a customer claim/dispute (service incident, eligibility disagreement, “consumed vs not consumed”, amount contested). | ||
| 6. Provide “who to contact / servicing responsibility” information per leg/operator/contract. |
There was a problem hiding this comment.
This needs to be part of the contract
| 8. Compensation decision outcomes (operator decision), including form of compensation (voucher/credit/other). | ||
|
|
||
| C) No-show and post-trip entitlement consequences | ||
| 9. Handle no-show status and its consequences according to after-sales conditions (fees, loss of right, partial refund eligibility). |
There was a problem hiding this comment.
This is done between the operators and the distributor (outside of EUDIT).
4 participants
Please add adjustments/additions to BUC B to this branch!