Diskussion:Shopping cart functionality - Versionsgeschichte

Holtermp: /* Example container with a package and extra rental car */

2017-02-08T16:20:14Z

Example container with a package and extra rental car

← Nächstältere Version		Version vom 8. Februar 2017, 16:20 Uhr
Zeile 40:		Zeile 40:

	The whole container/reservation/shopping cart stuff should be an optional feature. Clients could query the the implementing systems via the configuration service, whether they support the feature or not.		The whole container/reservation/shopping cart stuff should be an optional feature. Clients could query the the implementing systems via the configuration service, whether they support the feature or not.

	Note after experts meeting on 08.02.2017:		Note after experts meeting on 08.02.2017:

	-- Generally the usage of references to containers and items is considered a good idea.		* Generally the usage of references to containers and items is considered a good idea.
	-- Details will be examined more closely when dealing with the BookingContainer element.		* Details will be examined more closely when dealing with the BookingContainer element.

Holtermp: /* Example container with a package and extrq rental car */

2017-02-08T16:19:30Z

Example container with a package and extrq rental car

← Nächstältere Version		Version vom 8. Februar 2017, 16:19 Uhr
Zeile 34:		Zeile 34:
	** Rental car (BOOKED)		** Rental car (BOOKED)

	== Example container with a package and ~~extrq~~ rental car ==		== Example container with a package and extra rental car ==
	* Example Container 2:		* Example Container 2:
	** Package (Flight FRA-PMI/PMI-FRA, Hotel PMI)		** Package (Flight FRA-PMI/PMI-FRA, Hotel PMI)
	** Rental Car		** Rental Car


	The whole container/reservation/shopping cart stuff should be an optional feature. Clients could query the the implementing systems via the configuration service, whether they support the feature or not.		The whole container/reservation/shopping cart stuff should be an optional feature. Clients could query the the implementing systems via the configuration service, whether they support the feature or not.
			Note after experts meeting on 08.02.2017:
			-- Generally the usage of references to containers and items is considered a good idea.
			-- Details will be examined more closely when dealing with the BookingContainer element.

Holtermp am 6. Februar 2017 um 14:37 Uhr

2017-02-06T14:37:13Z

← Nächstältere Version		Version vom 6. Februar 2017, 14:37 Uhr
Zeile 34:		Zeile 34:
	** Rental car (BOOKED)		** Rental car (BOOKED)

	== Example container with a package and ~~an extr~~ rental car ==		== Example container with a package and extrq rental car ==
	* Example Container 2:		* Example Container 2:
	** Package (Flight FRA-PMI/PMI-FRA, Hotel PMI)		** Package (Flight FRA-PMI/PMI-FRA, Hotel PMI)

Holtermp am 6. Februar 2017 um 12:59 Uhr

2017-02-06T12:59:39Z

← Nächstältere Version		Version vom 6. Februar 2017, 12:59 Uhr
Zeile 4:		Zeile 4:
	Peter Holtermann:		Peter Holtermann:
	This requirement is about the implementation of a shopping cart in the ''the inventory system of the tour operator''. But to make that accessible through the String-Interface, we need to expose some kind of reference, which is called '''BookingRef''' in the use case. The other additional field '''BookingMode''' is something we need anyway in some way or another.		This requirement is about the implementation of a shopping cart in the ''the inventory system of the tour operator''. But to make that accessible through the String-Interface, we need to expose some kind of reference, which is called '''BookingRef''' in the use case. The other additional field '''BookingMode''' is something we need anyway in some way or another.

			I do not really care about the wording: We could call the container "Shopping Cart" as well as "Reservation" or "Booking Container".

			The important parts are:
			* The interface has to '''contain a reference''' to a container that can contain more than one product. Products could be single products or packages.
			* The Products in the container may have different states.

			== Example workflow:==

			Find and add a flight
			* Container 1
			** Flight FRA-PMI/PMI-FRA (ADDED)

			Find and add a hotel
			* Container 1
			** Flight FRA-PMI/PMI-FRA (ADDED)
			** Hotel PMI (ADDED)

			Find and add a rental car
			* Container 1
			** Flight FRA-PMI/PMI-FRA (ADDED)
			** Hotel PMI (ADDED)
			** Rental car (ADDED)

			Everythings fine? Ok, book all the stuff in the container
			* Container 1
			** Flight FRA-PMI/PMI-FRA (BOOKED)
			** Hotel PMI (BOOKED)
			** Rental car (BOOKED)

			== Example container with a package and an extr rental car ==
			* Example Container 2:
			** Package (Flight FRA-PMI/PMI-FRA, Hotel PMI)
			** Rental Car


			The whole container/reservation/shopping cart stuff should be an optional feature. Clients could query the the implementing systems via the configuration service, whether they support the feature or not.

Holtermp: Die Seite wurde neu angelegt: „Michael Althoff remarked: ''Question/Remark: The project is about the definition of an interface - shopping carts can either be a function of the front end or…“

2017-01-09T09:25:13Z

Die Seite wurde neu angelegt: „Michael Althoff remarked: ''Question/Remark: The project is about the definition of an interface - shopping carts can either be a function of the front end or…“

Neue Seite

Michael Althoff remarked:
''Question/Remark: The project is about the definition of an interface - shopping carts can either be a function of the front end or the inventory system of the tour operator. The interface itself does not provide an own shopping cart. Pls check the use case''

Peter Holtermann:
This requirement is about the implementation of a shopping cart in the ''the inventory system of the tour operator''. But to make that accessible through the String-Interface, we need to expose some kind of reference, which is called '''BookingRef''' in the use case. The other additional field '''BookingMode''' is something we need anyway in some way or another.