BUC B: lock & amend offers - #79
Open
edwinvandenbelt wants to merge 19 commits into
Open
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>
CGantert345
reviewed
Aug 10, 2026
| - **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) |
Collaborator
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.
CGantert345
reviewed
Aug 10, 2026
| - **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. |
Collaborator
There was a problem hiding this comment.
Time table data could be provided by a third party.
CGantert345
reviewed
Aug 10, 2026
| - **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. |
Collaborator
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.
CGantert345
reviewed
Aug 10, 2026
|
|
||
| ## 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. |
Collaborator
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.
CGantert345
reviewed
Aug 10, 2026
|
|
||
| ## 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. |
Collaborator
There was a problem hiding this comment.
That offers might be restricted is not a precondition.
CGantert345
reviewed
Aug 10, 2026
| - **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. |
Collaborator
There was a problem hiding this comment.
a catalog is not required.
CGantert345
reviewed
Aug 10, 2026
| - 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. |
Collaborator
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.
CGantert345
reviewed
Aug 10, 2026
| - 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. |
Collaborator
There was a problem hiding this comment.
the meaning of included is unclear
CGantert345
reviewed
Aug 10, 2026
| - **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)) |
Collaborator
There was a problem hiding this comment.
The fare products are not exposed
CGantert345
reviewed
Aug 10, 2026
| - 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), |
Collaborator
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.
CGantert345
reviewed
Aug 10, 2026
| - 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) |
Collaborator
There was a problem hiding this comment.
applies to optional reservations as well.
CGantert345
reviewed
Aug 10, 2026
| 1. The Customer is planning the travel (TRAVEL), which can be composed of one or more trips (TRIP(s)), each consisting of one or more legs (LEG(s)). The Customer wants to travel from an origin place (TRIP ORIGIN PLACE) to his destination place (TRIP DESTINATION PLACE) using public transport and, optionally, return to the origin place (PLACE can be a POINT, a SECTION or a ZONE). Any discontinuities (‘gaps’) between trips are not managed by this BUC by default; however, a Distributor may propose an end-to-end offer and/or a connection protection mechanism to cover such gaps (e.g. a combined offer or a travel guarantee for connections), in which case it is presented as part of the returned offer. The Customer provides selection criteria to the Retailer (for one or several Traveller**(s)**): timing/frequency, preferred modes, route preference (fastest/cheapest/greener), flexibility level (refund/exchange constraints), accessibility needs, and any other criteria needed to identify relevant options. | ||
| 2. The Customer may or may not connect to a customer account (CUSTOMER ACCOUNT) on digital platform of the Retailer, of a Distributor or another party. The Customer may request or prove eligibility for a particular passenger profile (USER PROFILE) (under 25 years old, PRM indications, corporate participation, companion, bike spot). The Customer may apply for a particular commercial profile (COMMERCIAL PROFILE). Relevant eligibility elements may already be registered or may be provided during the consultation (transport card, reduction cards, entitlements, vehicle plate, driving licence). The Customer can indicate that he wants to include associated offer (THIRD-PARTY PRODUCT) in the solution (example: museum entry) | ||
| - **Select the right content sources** | ||
| 3. The Retailer determines which Distributor**(s)** to query (one or many), according to coverage (network/area/operators/commercial brand) and commercial/access rules. The Retailer then requests content to retrieve an initial set of candidate options. |
Collaborator
There was a problem hiding this comment.
content to retrieve an initial set of candidate options. --> this is unclear. These are offers or offered packages.
CGantert345
reviewed
Aug 10, 2026
| > Ok | ||
|
|
||
| 6. If the selected SALES OFFER PACKAGE is not yet fully defined, the TRANSPORT CUSTOMER enters additional customer parameters by providing the required information, such as the traveller profile, eligibility, accessibility needs, class, date, zone, quantity, or extras. Once the required information is filled in, the retailer checks the entries and provides a price with the applicable commercial and travel conditions (aftersales including exchange or refund, specific restrictions, guarantees, passenger rights) for the selected SALES OFFER PACKAGE. It may be composed of several products. | ||
| - **Retrieve candidate offers (two entry points)** |
Collaborator
There was a problem hiding this comment.
Candicate offers _-> are there non-candicate offers?
CGantert345
reviewed
Aug 10, 2026
| - **Retrieve candidate offers (two entry points)** | ||
| Depending on the context, the Retailer may obtain candidate options through two entry points (the orchestration is the same; only the starting input differs): | ||
| 4. **Trip-based entry (journey planner result as input)** | ||
| - When the travel is not straightforward or if the Customer does not know how to make his travel or wants route suggestions, he can use a journey planner to compute possible routes and connections whether or not it is populated with the information from an account (CUSTOMER ACCOUNT), such as passenger profile attributes (e.g. age band), eligibility/entitlements (e.g. reduction rights, corporate profile), accessibility needs, preferred fulfilment medium (when it impacts eligibility), and party composition (number and type of travellers). It gives one or more results with details: schedule, transport modes, lines, stops, and connections (TRIP PATTERN(s)). |
Collaborator
There was a problem hiding this comment.
age bands are not exchanged, the customer only knows his age.
CGantert345
reviewed
Aug 10, 2026
| - **Selection of offers** | ||
| - The journey planner may be associated with a fare calculator based on the selected route(s) and the Customer/Traveller parameters, the fare calculator returns priced offer/options for that route (PASSENGER FARE OPTION) (from basic default assumptions to more tailored results using eligibility, reductions, accessibility needs, corporate traveller profile/entitlements (when applicable), loyalty attributes (when applicable) and guarantees (TRAVEL GUARANTEE(s)). It may also indicate any availability constraints when relevant (AVAILABILITY CONDITION) (combined ticket, multimodal offers, with reduction and guarantees, including passes already purchased) and may display availability of some assets or mandatory reservations. | ||
|
|
||
| - If the journey planner is not associated with a fare calculator, the Customer may be provided with a fallback to continue outside EUDIT (for example, redirecting the Customer to an external sales channel for the relevant segment), which is equivalent to the catalogue-based entry but outside the EUDIT flow. |
Collaborator
There was a problem hiding this comment.
This is not understandable. A separated journey planner needs to be supported by a distributor to esure compliance with competition law. Nether-the-less a combined journey planning / sales API may be offered aditionally for convenience.
CGantert345
reviewed
Aug 10, 2026
| Catalogue consultation is a Retailer/Distributor sourcing mechanism used to retrieve candidate offers; it does not imply that the Customer is manually selecting individual fare products. | ||
| - The Customer can browse one or more catalogues on a digital platform, go to a travel agency, a distributor desk, a ticket vending machine in a station or any distribution channel to request and compare offers proposed by the Retailer. The Customer may express preferences (e.g. mode, comfort, flexibility), but the Retailer presents priced offers returned by Distributor(s), and the Customer selects among those offers. He wants to choose by himself between offers, choosing himself the transport modes and the prices he is willing to pay. He can also include additional offers (THIRD-PARTY PRODUCTs) in his search when they are distributed through the same Distributor(s). | ||
|
|
||
| - Either the Customer or the Retailer on behalf of the Customer ask the Retailer for offers matching their criteria. The Retailer browses one or more catalogue to retrieve an initial set of candidate offers and presents an initial list. This catalogue exists as a reference static dataset (which may result from aggregation and harmonisation of one or more Distributor catalogues). When needed, this reference catalogue may be complemented or refreshed through real-time requests to Distributor(s), for example to retrieve up-to-date content or to confirm pricing and availability constraints. |
Collaborator
There was a problem hiding this comment.
This catalogue exists as a reference static dataset...
This should not be part of a use case description. Browsing a catalog in no way requires an exchange of static data which is always the worst technical implementation in terms of costs and dependencies. The requirement for browsing a calaog (e.g. for rail pass products) will usually also be implemented via the API and will not expose any internal data catalog of the distrbutor.
CGantert345
reviewed
Aug 10, 2026
| - **Consult offers details ( for a selected candidate offer )** | ||
| 7. The Customer selects one candidate offer and requests details so that he can consult the detailed contents, conditions, guarantees, and optional parts. This consultation can be done for more than one offer at the same time, if they can be displayed on the same screen at the same time. The Retailer retrieves the detailed information from the relevant Distributor(s) and presents it in a consistent way. | ||
| 8. If the selected offer cannot be confirmed for the specific customer context, the Customer enters additional customer parameters by providing the required information, such as the traveller profile, eligibility, accessibility needs, class, date, zone, quantity, or extras (ACCESS RIGHT PARAMETER(s), USER PROFILE, ENTITLEMENT(s), CLASS OF USE). Once the required information is filled in, the Retailer checks the entries, updates the customer context (adds the missing parameters) and requests confirmation from the relevant Distributor(s). The Distributor(s) then either confirm the offer (price/conditions/availability) or reject it if the provided inputs do not satisfy eligibility or other constraints. The Customer is informed with a price with the applicable commercial and travel conditions: | ||
| - sales and aftersales conditions including exchange, cancellation or refund conditions (USAGE PARAMETER(s): EXCHANGING / REFUNDING / CANCELLING), |
Collaborator
There was a problem hiding this comment.
The information will not be exchanged in the form of Netex parameters!
CGantert345
reviewed
Aug 10, 2026
| ### Diagram | ||
| 1. The Customer starts his mobile application/distribution channel; the entry point can display a shortcut for single-trip purchase “in one action” (i.e. with minimal input) (CUSTOMER ACCOUNT optional). | ||
| 2. The Customer chooses an anonymous single-trip ticket by using this shortcut (default assumptions may apply: anonymous adult, single trip, no reduction) (USER PROFILE default, TRAVEL SPECIFICATION minimal). | ||
| 3. The Retailer requests and displays the priced offer with sales conditions and travel guarantees (PASSENGER FARE OFFER, PRICE, USAGE PARAMETER(s), TRAVEL GUARANTEE(s)). |
Collaborator
There was a problem hiding this comment.
What is a PASSENGER FARE OFFER?
CGantert345
reviewed
Aug 10, 2026
|
|
||
| - **PRM journey** | ||
| 1. The Traveller(s) have specific needs that must be guaranteed to be met during the travel (on each leg and between legs, during connections). The journey planner gives solutions that meet the travel specification with mobility services even on the first leg (from house/postal address to first stop point), during interchange and on the last leg (from last stop point to final destination) (TRAVEL SPECIFICATION, LEG(s)). | ||
| 2. If the journey planner is associated with a fare calculator, the Customer receives an offer compliant with passenger profile and with the travel specification, including continuous additional services and travel guarantees from house to destination (USER PROFILE, PASSENGER FARE OFFER, TRAVEL GUARANTEE(s)). |
Collaborator
There was a problem hiding this comment.
The sales api provides the offers based on the results of the journy planner. There is no such thing as a fare calculator. Journey planner and sales Api are separate.
CGantert345
reviewed
Aug 10, 2026
| - **PRM journey** | ||
| 1. The Traveller(s) have specific needs that must be guaranteed to be met during the travel (on each leg and between legs, during connections). The journey planner gives solutions that meet the travel specification with mobility services even on the first leg (from house/postal address to first stop point), during interchange and on the last leg (from last stop point to final destination) (TRAVEL SPECIFICATION, LEG(s)). | ||
| 2. If the journey planner is associated with a fare calculator, the Customer receives an offer compliant with passenger profile and with the travel specification, including continuous additional services and travel guarantees from house to destination (USER PROFILE, PASSENGER FARE OFFER, TRAVEL GUARANTEE(s)). | ||
| 3. If the journey planner only provides basic mobility solutions, the Customer browses the catalogue to select one by one the required tickets/services/guarantees. When his selection fulfils his complete travel, he has a satisfactory solution. If this requires combining several items, it is handled in BUC-B (TRAVEL BASKET / TRAVEL PACKAGE). |
Collaborator
There was a problem hiding this comment.
No, there is no catalog consultation.
CGantert345
reviewed
Aug 10, 2026
| - **Return trip** | ||
| 1. The Customer plans a travel composed of an outward journey and the corresponding return journey. The journey planner can manage the full travel, requesting only minimal criteria for the return trip (return time and reversing origin-destination) (TRAVEL, TRIP(s)). | ||
| 2. If an integrated fare calculator is available, it may produce an initial indicative priced offer based on the result of the journey planner: , the Customer can receive an offer that considers the whole travel (for example, a daily pass less expensive than two separate tickets) (PASSENGER FARE OFFER, PRICE). | ||
| 3. If the journey planner only proposes basic mobility solutions, the Customer browses the catalogue to select one by one the tickets, looking for a solution that includes the two trips. If this requires assembling multiple selected items, it is handled in BUC-B (TRAVEL BASKET / TRAVEL PACKAGE). |
Collaborator
There was a problem hiding this comment.
the sales API is consultet, not a catalog.
CGantert345
reviewed
Aug 10, 2026
| 2. If an integrated fare calculator is available, it may produce an initial indicative priced offer based on the result of the journey planner: , the Customer can receive an offer that considers the whole travel (for example, a daily pass less expensive than two separate tickets) (PASSENGER FARE OFFER, PRICE). | ||
| 3. If the journey planner only proposes basic mobility solutions, the Customer browses the catalogue to select one by one the tickets, looking for a solution that includes the two trips. If this requires assembling multiple selected items, it is handled in BUC-B (TRAVEL BASKET / TRAVEL PACKAGE). | ||
|
|
||
| - **Bank card as TRAVEL DOCUMENT** |
Collaborator
There was a problem hiding this comment.
this is out of scope, as there is no sale by the retailer. Furthermore it requires additional actors to craete the tolken from the bank card.
There might be an alternative case where the bank card is used as account identifier, but this requires additional logic to create a token recognisable by multiple companies.
CGantert345
reviewed
Aug 11, 2026
| - **Retailer (FARE PRODUCT RETAILER ROLE (API consumer)):** manages the shopping flow and customer interaction, presents the TRAVEL BASKET to the TRANSPORT CUSTOMER and may manage a logical and/or technical basket (basket consistency, requests sent to one or more distributors). | ||
| - **Distributor (FARE PRODUCT DISTRIBUTOR ROLE (API provider)):** provides offer completion rules, PRICE information, commercial conditions, after-sales conditions, guarantees, and dependency rules affecting basket elements. May manage a technical basket for one or more basket elements. | ||
| - **Retailer** (FARE PRODUCT RETAILER ROLE (API consumer)): manages the shopping flow and customer interaction, presents the basket to the Customer and may manage a logical and/or technical basket (basket consistency, requests sent to one or more distributors, consolidates responses from Distributor(s)). | ||
| - **Distributor** (FARE PRODUCT DISTRIBUTOR ROLE (API provider)): provides offer completion rules, price information, commercial conditions, after-sales conditions, guarantees, and dependency rules affecting basket elements. May manage a technical basket for one or more basket elements. |
Collaborator
There was a problem hiding this comment.
provides offer including: completion rules
CGantert345
reviewed
Aug 11, 2026
| - Each basket element contains one selected offer and the information needed for continuation: | ||
| - selected **offer(s)** and quantity, including validity when applicable (CUSTOMER PURCHASE PACKAGE) | ||
| - the associated current price (PRICE), | ||
| - applicable reductions, guarantees and aftersales conditions (TRAVEL GUARANTEE(s), USAGE PARAMETER(s)), |
Collaborator
There was a problem hiding this comment.
quarantees is toon abstract and shouldbe detailed.
CGantert345
reviewed
Aug 11, 2026
| - 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)). |
Collaborator
There was a problem hiding this comment.
USAGE PARAMETER(s), VALIDITY CONDITION(s). The data models will be different for an API.
CGantert345
reviewed
Aug 11, 2026
| - 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). |
Collaborator
There was a problem hiding this comment.
resulting price, validity and applicable conditions for presentation (PRICE). --> resulting package including ...
CGantert345
reviewed
Aug 11, 2026
| - 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. |
Collaborator
There was a problem hiding this comment.
it is always the package that is retrieved
CGantert345
reviewed
Aug 11, 2026
| > 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 |
Collaborator
There was a problem hiding this comment.
only pre-booked offers can be modified, thus a pre-booking is mandatory.
CGantert345
reviewed
Aug 11, 2026
| > **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). |
Collaborator
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.
CGantert345
reviewed
Aug 11, 2026
|
|
||
|
|
||
| > **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 |
Collaborator
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).
CGantert345
reviewed
Aug 11, 2026
|
|
||
| > **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. |
Collaborator
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.
CGantert345
reviewed
Aug 11, 2026
| - 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) |
Collaborator
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.
CGantert345
reviewed
Aug 11, 2026
|
|
||
| > **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 |
Collaborator
There was a problem hiding this comment.
--> Customer Offer Package?
CGantert345
reviewed
Aug 11, 2026
|
|
||
| > **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) |
Collaborator
There was a problem hiding this comment.
There are no Sales Offer Parts requested.
CGantert345
reviewed
Aug 11, 2026
|
|
||
| > **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. |
Collaborator
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Please add adjustments/additions to BUC B to this branch!