[FEATURE REQUEST] Create bookings with multiple assets of the same assetType

[matt-wirtz]

Use Case

A TO offers shared bikes of different types. The TO only accepts bookings for specific assetTypes but not individual assets.
A user wants to book two bikes of the same bike type.

In v1.5 the desired bike type can be specified but not the quantitiy. The assetType in /planning/offers is an array but the provided assetTypes are meant as a set of alternatives (OR) and not as a set of a collection (AND).

Using multiple calls to /planning/offers will not work: Assume there is only one bike of the desired bike type left. If this use case is handled by multiple calls to /planning/offers, one probably gets back the same option for both of them. Of which only one is bookable but this will not be clear to the MP before actually booking them.

Additional context

This use case is probably only relevant in bike sharing systems. Here different types of bikes in the same system are very common and are often significant and priced differently. For e.g. car sharing systems this use case doesn't seem to have any practical relevance.

Describe alternatives you've considered

• The nrOfTravelers could be used as quantity. But that seems to be rather ambigous if more than one assetType is given.
• If the TO supports a two-phase-commit the MP could try to book the assets one by one. If all requested assets can be booked succesfully then the MP could commit all bookings. If one booking fails than all bookings are canceled.

Possible Implementation

• Support multiple planningRequest objects when calling /planning/offers. I.e. replace the planningRequest object with an array of planningRequests and indicate whether these are alternatives or one composition.
• Extend the array of assetTypes to include the quantity that is requested for each assetType

[eborremans]

Note that for most of the cases the nrOfTravelers can be used. However, if the customer wants small variations for the same assettype, for instance one bike of type A with a child seat and one without they should be able to define two slightly different requests for the same assettype. In that case the proposed solution would allow the TO to correctly return that only 1 bike of that type is left.

[edwinvandenbelt]

In v2.0 you'll be able to specify per (anonymous) person the requirements:
parameters: [
{ usage: [ { type: USER_PROFILE, ageGroup: ADULT } ]
, validities [ { type: EQUIPMENT, id: CHILD_SEAT }, { type: SERVICE, product: BIKE_TYPE_A } ]
},
{ usage: [ { type: USER_PROFILE, ageGroup: ADULT } ]
, validities [ { type: SERVICE, product: BIKE_TYPE_B } ]
} ]

Using this approach, you'll have a request for 2 anonymous travellers (otherwise you should use INDIVIDUAL_TRAVELLER instead of USER_PROFILE), with both different requirements ('requested validities' in Transmodel terminology).