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

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

2017-02-08T16:19:30Z

‎Example container with a package and extrq rental car

Holtermp am 6. Februar 2017 um 14:37 Uhr

2017-02-06T14:37:13Z

Holtermp am 6. Februar 2017 um 12:59 Uhr

2017-02-06T12:59:39Z

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.

@@ 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.
 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.
+* Generally the usage of references to containers and items is considered a good idea.

@@ Zeile 34: / Zeile 34: @@
 ** Rental car (BOOKED)
-== Example container with a package and extrq rental car ==
+== Example container with a package and extra 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.

@@ Zeile 34: / Zeile 34: @@
 ** 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:
 ** Package (Flight FRA-PMI/PMI-FRA, Hotel PMI)

← 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.