Search offers - the 'Delivery' part - 20260702#68
Conversation
edwinvandenbelt
changed the title
…and property updates
| @@ -0,0 +1,25 @@ | |||
| allOf: | |||
There was a problem hiding this comment.
I took the liberty to add 'PlaceHolder' concept, where retailers have the complete list of things they have to complete before they can purchase the package. E.g. personal aspects or choices of allocations/ancillaries.
|
Hmmm. On second thought, why is a 'REQUIRED ANCILLARY' or 'REQUIRED ALLOCATION' connected to the |
|
And why it is a 'TRIP PATTERN SECTION', instead of 'TRIP SECTION'? Now we need to use the tripPatternId explicitly when using sections. Not in all cases the TRIP PATTERN (inbound/outbound) is needed. And you cannot have sections that partly cover the first pattern and partly covers the second pattern... |
|
To be added somewhere: a token indicating that the offer package is valuable only if the customer buys another package with the same token provided by another distributor. That enable lower end-to-end price when a retailer combines 2 offers provided by 2 differents distributors that have aggrements. |
| description: The channel of the offer. | ||
| x-enum-values: | ||
| - "web" | ||
| - "mobile" |
| - completed | ||
| - issued | ||
| - revoked | ||
| - refunded |
There was a problem hiding this comment.
"refund" implies a financial transaction, which relies on retailer's process. "Canceled" would be better
| properties: | ||
| issuer: | ||
| type: string | ||
| description: The entity that issues the entitlement right. |
There was a problem hiding this comment.
it should be possible to have a code here (optional), like RICS code
| - "ISO/IEC 7816-4" # NFC, MIFARE DESFire | ||
| - "GATT" # Bluetooth Low Energy | ||
| - "AXA Bike lock" # AXA Bike lock | ||
| - "OTHER" # Other content standard |
There was a problem hiding this comment.
is calypso NFC card in this list ?
There was a problem hiding this comment.
- a link structure to reference the relevant terms and conditions would be usefull
- an indication of the relevant legal regulations (EU_PRR, SMPS, COTIC,..) and multilateral guarantees (CIT_AJC, RES_PLUS,..) would be needed (extensible enum).
There was a problem hiding this comment.
Guarantees might not always refere to the entire package but can refere to a travel right or even a trip section of a travel right.
| "placeHolderType": "personalDetail", | ||
| "travellingEntity": "Traveller-01", | ||
| "fieldName": "fullName", | ||
| "required": true |
There was a problem hiding this comment.
why would you make a placeholder for optional content?
There was a problem hiding this comment.
you would need to express something like "provide either e-mail or phone number for the traveler"
| expiryTime: | ||
| type: string | ||
| format: date-time | ||
| status: |
There was a problem hiding this comment.
The status is on the individual package parts. As you can add parts to a confirmed package the package can include parts in different state.
There was a problem hiding this comment.
The delivery needs to include also the list of trips that are referenced by the OfferedPackages.
| @@ -0,0 +1,64 @@ | |||
| type: object | |||
| required: | |||
There was a problem hiding this comment.
conditions usually refere to package elements and not to entire packages
There was a problem hiding this comment.
on textual descriptions a classification is needed:
INFORMATION: pure informational text (product/fulfillment).
MANDATORY: must be displayed to the customer prior to purchase (product).
MANDATORY_WITH_CONFIRMATION: must be confirmed, e.g. by checking a checkbox, prior to purchase (product).
TICKET_VALIDITY: any text on the ticket regarding it's validity (other than information which can be retrieved from the booking)
There was a problem hiding this comment.
The naming needs to be carified a summary is not a stand alone object, it is always defined as a summary of something. We need to split this:
PackageSummary,
PackagePartSummary,
ProductSummary.
There was a problem hiding this comment.
Product needs a lot more details:
summary:
description: |
A human-readable description of the product.
type:
x-extensible-enum:
- ADMISSION_PASS
- ADMISSION_MULTI_RIDE
- ADMISSION_POINT2POINT
- UPGRADE_PASS
- UPGRADE_MULTI_RIDE
- UPGRADE_POINT2POINT
- RESERVATION
- ANCILLARY_SERVICE
- ANCILLARY_ITEM
- REDUCTION_CARD
code: The product code expressed in the provider system (could be a
mapping from an even lower-level provider).
examples:
- PT00AD
description: Textual description of the product.
owner: $ref: '#/components/schemas/CompanyRef'
conditions:
description: |
description of the sales or after-sales conditions.
type: array
items:
$ref: '#/components/schemas/Condition'
flexibility:
x-extensible-enum:
- FULL_FLEXIBLE
- SEMI_FLEXIBLE
- NON_FLEXIBLE
serviceClass:
$ref: '#/components/schemas/ServiceClass'
travelClass:
$ref: '#/components/schemas/TravelClass'
fulfillmentOptions:
type: array
items:
$ref: '#/components/schemas/FulfillmentOption'
isTrainBound: - boolean
isReturnProduct: - boolean
serviceConstraintText: condition on the services to be used
carrierConstraintText: condition on the carriers to be used
combinationTags: governing the combination with other providers products
_links:
$ref: '#/components/schemas/Links'
| - $ref: ./Package.yaml | ||
| - type: object | ||
| properties: | ||
| status: |
There was a problem hiding this comment.
the status is at the packagepart. A package can be amended with new parts and then contains partsin different state.
| description: A list of travelling entities associated with this package element | ||
| items: | ||
| type: string | ||
| format: travelling-entity-ref |
There was a problem hiding this comment.
travelling-entity-ref must provide the provider and the consumer id of the travelling entity.
There was a problem hiding this comment.
warning is outdated, Problem structure needs to be nused.
There was a problem hiding this comment.
For Allocations you usually would select seats via graphical seat display. SEAT or BERTH would be different offers or at least different allocations to be selected beforehand. I don't see a use case for the place holder in the allocation.
3 participants
This is a large PR, we'll try to address the important parts one by one:
The package
the general idea is to have one
Packageconcept and theOfferedPackageconcept derives from it.The
Packageitself hasPackageElements (likeTravelRights,SpotAllocations,AssetAllocations andAncillarys).A (set of)
PackageElement(s) can haveGuarantees (specified later).The offer
The
Offeris actually a package, with additional information (the yellow/brown concepts):By doing so, the
Packagecan be reused and the specific items for anOfferPackageare only accessible in the offer part.It has a list of
RequiredInformation, clarifying which information is required to supply before the purchase can be done. Example: provide email address or mobile phone number of the traveller. Or the length of a PASSENGER VEHICLE.There is also
OptionalInformationthat can be supplied, like voucher codes. (specified later).Third part: the selectable elements. In the offer are optional elements (to specify with an offer element selection referring to that specific element), or choices (like choose from NORMAL SEAT, LUXURIOUS SEAT, BERTH, with minimum 0, and maximum 2 to select).
---- old ----
This pull request is a large one, and an important one. It contains the draft 'Package', with all details.
A short guideline to help you navigate through all files.
a) start with the
SEARCH OFFER DELIVERY. That is the 'main' concept.it contains
WARNINGs, and a list ofOFFERED PACKAGE(SALES OFFER PACKAGE)b) the
OFFERED PACKAGEinherits fromPACKAGE, and containsPACKAGE ELEMENTs,PRICE(FARE PRICE)SUMMARY DETAILs (describing e.g. (after-sales) conditions)c)
PACKAGE ELEMENTs refer to:travellers (INDIVIDUAL TRAVELLER),luggage,passenger vehicles,animals)TRIP SECTIONs.PRICE(FARE PRICE)PACKAGE ELEMENTis OR aTRAVEL RIGHT, OR anANCILLARY, OR anALLOCATION(for e.g. a seat or bike)d) TRIP has a sequence of LEGs (timed legs, continuous legs, transfer legs), being compliant to OJP. LEGs can be bundled into TRIP PATTERNs using the same trip pattern reference (e.g. 'outbound-P1')
The other concepts are supportive.
The
PACKAGE ELEMENTcan have 'REQUIRED INFORMATION', like a date of birth, license driver's number, address, and so on (x-enum). The requested information should be supplied in the PURCHASE PACKAGE REQUEST (due to GDPR).A 'PACKAGE ELEMENT' can be a TRAVEL RIGHT, an ANCILLARY or an ALLOCATION. And the ALLOCATION itself can be a SPOT ALLOCATION (seat, bike spots etc) or an ASSET ALLOCATION (a scooter, parking spot etc).
Each 'PACKAGE ELEMENT' has a 'TRIP SECTION' where it is valid. This allows that SPOT ALLOCATIONS can be used separately from the TRAVEL RIGHTS (in other words, within a single leg you can have multiple seats, to specify you have to change seats during the ride).