Team Offer and Purchase - BUC A-C simplified #82
Replies: 13 comments 50 replies
|
Open topic: Non-trip-based offer search. there are however also Non-trip-based offer requests. This could be an alternative flow in the use case. What needs to be added to the Busness use case as an alternatieve flow QUESTION: what standard has an existing implementation for this. How does it work in that standard? |
|
OSDM does |
|
The TOMP-API its core is the non-trip-based search. It starts often with a location, or with an asset, product of a from-and-to specification. The use case 'Non-trip-search' has 3 possibilities: The first use case (location based) is shown here: |
|
Bob has this too, but does not distinguish between trip-based and non-trip based searches on the API level. In the product query you could specify only a location (such as a geo-coordinate, a stop id or a zone if you happen to know that concept) and the product service would provide relevant offers for that spot. A typical example could be a ticket for a city bus, valid in the entire municipaility for a certain time (e.g. 90 minutes). It is also possible to provide a list of locations, whereby the product service would provide (for example) relevant travel passes for different periods (daily, monthly, yearly, etc.) that cover these areas. But could, in theory, also render a single-journey ticket. Depending on the search criteria. |
|
If the BOB model does not distinguish between trip and non-trip based, the question is, do we have the retailer or the Distributor make the transaltion how to request the offer. Some examples would help of a high level BOB request and reply, to explain the different situations. voor this project the focus is a multi model trip from A to D via B and C. A to B might be a BOB request. so the Retailer wants an offer that fits A-B in a certain time frame. It could be the Distributor that uses this to translate this to a valid BOB request. Alternative is the retailer needs to know how to aks an offer when in the back ground it is BOB or ODSM, or TOMP. Makes it more difficult for retailers. |
|
I don't know now what is ment by 'non-trip based' searches.... In my mind, it covered multiple scenarios:
|
|
open topic: Product based offer search a customer might want to by a discount card, or ather product that is not an ancillary. This could be an alternative flow in the use case. What needs to be added to the Busness use case as an alternatieve flow QUESTION: what standard has an existing implementation for this. How does it work in that standard? |
|
I would prefer to invoke @CGantert345 to provide exact OSDM examples :) |
|
In OSDM the request for offers is the dame, but using product tags instead of trips. Additionally you use the OSDM endponts to retrieve product tags and groupings before the offer request. This is implemented by Eurail for their paases, but works the same way for other products as well. |
|
But with OSDM, I think that you cannot mix trip based + product tag based request. You don't have an open list of criteria, you must choose either trip-based, or non-trip-based or product-based request. Is that correct ? |
|
The TOMP works more or less the same. We only have a 'search-offers' endpoint, delivering all functionality, and comparable with OSDM and BoB. I think in the final result, we should strive for the same approach, but it can be simplified a lot. Nowadays you really need to know how to work with the search for offers in all of the used standards. |
|
@edwinvandenbelt So you mean that you want to achieve that the retailer does not need to know how it works underneeth? that the Distributor solves this for the retailer? Can you share your ideas? |
|
open topic: Realtime data in offer response Trip planning is on Retailer side for EUDIT currently. Retailer schould use real time data to populate its trip planner. This is out of scope, however this assumes that the planed trip is up to date. in practice the situation could exist that the retailer does not have acces to real time data. in this case there could be a discrepancy between the Trip times in the offer request and the actual timing. this could have impact on the feasibility of the total trip. as minimal connecting times might not be respected by a delay. In this case the distributor needs to check the times and reply if the realtime departure and arrivel time are changed. so retailer can check feasibility of its ittineray and act accordingly. an alternative situation could be that the retailer uses an old planning file. This could be an alternative flow in the use case. What needs to be added to the Busness use case as an alternatieve flow OSDM supports this. Other models as well? |
|
TOMP works with notifications, sending information to the retailer. It does not share other real-time data in the offers, or maybe the available number of assets on a station (e.g. family-bikes: 30). |
|
In Bob, products are sold against a geographic pattern — typically a route expressed as a list of stops. In almost all cases the traveller may take any departure, and travel in the opposite direction as well. The offer therefore carries no service identity and no departure times, hence no timing issues or need for realtime data in offer response. However, where booking is required, such as demand-responsive transport, the booking and the travel right are two separate things: the booking secures the vehicle, the ticket grants the right to travel on it. A traveller can hold a 30-day pass and then book a DRT trip from A to B against it. In those cases the retailer will receive the exact departure times at the location requested by the traveller at the time of booking. This should structurally be the same as a pass plus a seat reservation in the rail world? |
|
For TOMP, if the information is sent to the retailer after the sale, we need to model this in one of the other teams. For BOB, First alinea: I have dificulty picturing this. Please make sure the relevant examples are in the Business use case, and the offer request model fits these type of requests. I can also picture that the retailer does request with route and time, and the Distributor makes the translation to the correct BOB type product to offer. Let see how we can make this understandable in the business use case. Second BOB alinea: I can picture a customer buying a 30 day pass as a product. This can be done in a seperate sale, or during the same sale as the first trip. I think it is good to create some examples of different product caracteristics, to fit in the flow. |
|
TOMP: we can assign indeed assets to a booking after the purchase, but in the purchase it is described how many of each asset type is 'booked'. It has the same endpoint for assigning assets before and after the purchase. We should consider to make the 'exchange' and 'amend' very similar. |
|
Open point: Multi-distributor packages @edwinvandenbelt, can you elaborate on this open point? I think this is a retailer internal topic out of scope. do you agree? |
|
Basically, OTI should work between retailers and distributors, but also between distributors and distributors. |
|
Can we create an MVP to support the Retailer - Distributor interation first. A distributor can be an agregator of more than one mobility providers. Lets first FOCUS on this interaction. |
|
ok, Let's check later on if it will work between aggregator and distributor or between aggregator and retailer. But I am pretty sure that it will do ! |
|
@OlivierBigex hear hear. Maybe we need to add some additional fields on the "package elements", to refer to the original supplier. |
|
indeed. for reporting and settlement processes |
|
open point: Locked offers/on-hold offers/expiry times in step 4 Provisional Booking Creation this is covered. The provisional booking is locked for a difinite time period. an additional alternative flow to add is the request from a retailer for an extra long ticket time limit. For agents when customers need more time. we must take in to account that the ticket time limit supplied by the distributor is not static. If the offer is locked day's befrore travel, the time can be longer than locking on the day of departure. The time limit spuplied must be in the responce from the distributor to the retailer. Do we need to add more on this topic? @schlpbch can you add how this works in ODSM? or send me the location where I can find the details. |
|
The TOMP-API has an additional endpoint, requesting for additional time, to postpone the expiry time. This is not only applicable for the expiry time of the locked offer (provisional booking), but also for the validated offer (to handle the payments). And if exchange is more or less similar, I'd expect that the expiry time will also apply in the exchange (and cancellation). |
|
@OlivierBigex is this the same for OSDM? |
|
yep. an On-hold-offer can be patched to be manipulated. |
|
so this is an additional endpoint in both cases, not part of the FORGE "amend" endpoints. i will make sure this is adressed in the use case |
|
open point: Travel basket management functions ( "amend" ) Seats, assets, offer elements. in the main flow of the buca we have step 3 where the customer can select before provisional booking and some items can be added to the offer at proviosnal booking request. in step 5 these items can be added after the offer was locked. What do we need to add more to the use case for this open point? |
|
I think we need to be more precise. It should be clearly describe what can be modified, the why, and in which cases these modifications occur. For instance, how often does it happen that you add a traveller, even in the amend-phase? Or should we rely in that case directly to the 'search for offers' again, start all over? |
|
My suggestion would be:
|
|
deliverable discussion: Business Use Case The business use case to be part of the standard description should be easy to read and contain only that what is nessessary to understand what is supported by the standard. We keep to the high level content to understand the flow and alternatives. Details can be found in the Enterprice model. We must assure all relevant functions in scope, from the models covered (TOMP; BOB etc) are added in the use case. For this I ask model specialists to check if all functionalitys from ist model is covered in the use case and identify that the functionalities can be used in the flow as described. At a certain point we need to clearly state that all functionalities of the models covered are checked against the business use case, so we have an administration to know we are compleet. For this it would be good to have a name from each mode, that is responsible for this check of compleetnes. QUESTION: Please add a comment if you are willing to check the Business use case against all functionalities from the mode you are specialist from. So we know who can confirm we are compleet. "Name" "Model" (TOMP; BOB; OSDM; Ferry Gateway; OMSA) |
|
Edwin - TOMP-API |
|
Fredrik - Bob |
|
I can review from the angle of indirect distribution (id est: via travel sellers independent from the carrier platforms) |
|
joachim Seifaldet represents local transport |
|
Diliverable discussion: Technical specification. What do we need to identify als relevant content for the Technical specification? |
|
This is not really a discussion. We must at least include a precise description of the interface. The lowest level of detail is normally not a part of the TS, but is delivered seperately. |
|
Diliverable discussion: Enterprice Architect. How can we, in a structured way, use the details of the current model API's to asure all relevant details are available in AEnterprice architect? |
|
A good question. I think it is only possible taking the details of each API, and try to map it towards we're producing. |
|
When to provide passenger information. in some cases, passenger specific information is needed in step 4 Provisional booking creation. This in the case that this information is mandityory for provisional booking. However providing the data at final booking step prevents sharing personal data for bookings that will never be booked. do we agree to keep the option in both steps? |
|
As written in previous BUC, an offer is locked as soon as it is put in a basket (cart), in order to secure price and assets until the final confirmation and payment. With OSDM, it is done through the initial creation of a booking with a Ticket Time Limit in the reply. |
|
@OlivierBigex let me ask my question differently, does OSDM have a second time limit
and how is this for TOMP; BOB; Ferry Gateway and OMSA? |
|
OSDM:
|
|
you mean with the 3d, the Pre-booking can be put on hold, but this is not the main flow. Is it correct that normaly the Pre-booking is het main TTL, also for payment? |
|
yep ! a TTL aims to let the custumer the time to make up his mind, provide additional informations, add ancillary services and pay (which triggers confirmation). |
|
Comment to collect high level Mode examples of requests and answers from different models (TOMP; BOB etc). The aim is to have a high level view on the differece between an offer request and reply, for a trip based, a Non-Trip based and a product based request and offer for the different modes, to compare and find out how these can be combined in one endpoint. |
|
as discussed in the 2nd team meeting: lets create an example for a multi model booking, where we can show what actions the retailer - multi distributor interaction will contain. suggestion: prebooked trip containing 4 modes via 4 different distributors.
would this be a sensible example to show how OTI can be used? |
|
Can you change "bus from A-B" with "bus from Zone A to Zone B (or even only within Zone A)" ? even more representative, particularly for urban modes. Note that on an itinerary point of view (=itinerary based offer), the traveler will go from x (within zone A) to y (within zone B), but he will get a contract available from zone A to zone B. |
|
This BUC A to C is already quite big as it covers several steps (which could happen at different timing and in parallel or sequentially) 2nd use case: create provisional booking 3rd use case: book an offer etc This would also allow to have for each one the following sections (which can differ for each use case)
|
|
I understand what you mean, and I agree, However we need an overview business use case as well, to show hoe the whole proces fits together and to show the fact that some steps might not always be needed. your suggestion also helps to keep the alternative flows localyif they only refer to one step. For now I suggest to keep all in one document. The actual use case is 8 pages. The other 18 pages are for other details, like enterprice architect model pictures. |
|
Hello all! I added quite a few comments and proposed some rewritings to BUC A to C(some as side comments and some inline text when it is too long for the comment box) . Feel free to review and accept/reject/discuss these proposals |
|
Thank you Odile, for all the work. I will integrate it or replace. |
|
integration done |
|
thank you bob I'll review again in coming days also with other use cases for consistency if time permits ;-) |
Uh oh!
There was an error while loading. Please reload this page.
Hello all, you can react on the content of the document (previously BUC A-C), but only in simple steps. Please add additional information and/or remarks in the document. If you want to start a discusion on a specific item in it, please put these in this discusion thread.
The document can be found here: https://maasallianceeu.sharepoint.com/:w:/r/sites/europeandigitalticketinginterfaces/_layouts/15/Doc.aspx?sourcedoc=%7B404CC716-E9B0-47D2-A312-6868B7565800%7D&file=BUC%20A-C-multi%20model%20multi%20distributor%20booking.docx&action=default&mobileredirect=true
Small remarks -> use the word functionality (comments) or just apply them to the text. Please avoid making the document a "Comment Puzzle".
Discussions -> here
All reactions