Bestellfunktion

1

Wie erfolgt die Produkteauswahl

Das Portal erhält einen neuen Aspekt für die Mengen-Auswahl, nennen wir ihn den Bestell-Aspekt. Dieser besteht aus zwei Spalten für die Anzahl Einheiten und Gebinde. Mit dem Verlassen eines der beiden Felder wird das andere gerechnet. In der Titelspalte sind zwei Iconen für Flaschen und Verpackungen. In der Aspekt-Definition lässt sich das Attribut für die Artikel-ID festlegen.

Analog zum Bestellvorschlag in VinX wird dieser Aspekt an verschiedenen Stellen hinzugefügt:

1. Bestellvorschlag aufgrund der Kundengeschichte. Hierfür ist alles schon vorhanden bei den Bezügen, welche lediglich noch um den Aspekt erweitert werden muss.

2. Artikel: In der normalen Artikelliste lässt sich ebenfalls der Bestell-Aspekt hinzufügen.

3. Promotionen: Bei allen Promotionen aufgrund von Aktionen, Spezialpreisen und Sortimenten wird der Bestell-Aspekt hinterlegt.

2

Wie soll der Warenkorb abgebildet werden?

Der Checkout kann wie im Beispiel von Encodo abgebildet werden.

Von uns muss hier die Liste der Attribute kommen aus dem Warenkorb, die angezeigt werden sollen plus ein Vorschlag für die Kostenübersicht. Auf der Position sind dies (aus BasketPosition):

• Artikel

• Jahrgang / Volumen

• Abfüllung

• Bestell-Aspekt, bestehend aus Menge und Anzahl Gebinde, so dass sich die Eingaben noch überarbeiten lassen

• Preis pro Stück (unitprice)

• Zeilentotal exkl. MWST( lineTotalAmount)

Auf der Übersicht zeigen wir (aus Basket):

• Total Positionen analog Bild (lineTotalAmount)

• Total Gebinde, sofern nicht leer (packagesTotalAmount)

• Total Gebühren, sofern nicht leer (chargeTotalAmount)

• Total Rabatt, sofern nicht leer (discountTotalAmount)

• Total MWST (taxTotalAmount)

• Total inklusive MWST (grandTotalAmount)

3

Wie wird die Bestellung mit der Adresse verbunden?

Die Bestellung kommt OHNE Online-Adresse, da die Adresse schon bekannt ist. Der ADM erhält Liefer-, Rechnungs- und Konditionenadresse vorgeschlagen und kann diese anpassen..

4

Wie wird die Online-Bestellung geschrieben.

Lediglich die Bestellung mit den Datum, Adressen, ADM. Für das Portal wird ein Provider mit eigenem Typ angelegt, damit sich die Bestellung dem Portal zuweisen lässt.

Die Bestellposition kommen je nach Option in folgender Form:

• A - mit VinX Online Warenkorb - vollständig durchgerechnet

• B - ohne VinX Online Warenkorb - mit dem korrekten Preis, aber noch ohne durchgerechnete Konditionen

Die Provider-Typisierung fehlt noch.

Am besten gleich ein Portal Provider mit Default-Adresse und BPE-Verbindung.

5

Wie rechnen wir den Preis im Portal?

Die Preisfindung steht in VinX als View zur Verfügung - einfach ohne abschliessende Konditionierung aus Rabatten etc. Von daher kann man dies als Richtpreis vor Rabattierung zur Verfügung stellen.

6

Wie rechnen wir Preise und Konditionen bei der Übernahme der Online-Bestellung?

Hier benötigen wir in VinX die Einstellung, dass die Preise in VinX gerechnet werden sollen. Dies ist aber ein Problem, da dies auf der E-Commerce-Gruppe fixiert ist. Wenn wir bereits bestehende Shop-Provider mit dem VinX Shop haben, dann ist auf der E-Commerce-Gruppe die Einstellung, dass die Preise aus dem Shop bereits gerechnet kommen. Hierzu ergänzen wir den Provider, dass sich dort einstellen lässt, ob ein bestimmter Provider bereits gerechnete Preise liefert oder ob die Einstellung aus der E-Commerce-Gruppe gelten soll.

Alternativer Lösungsweg: Auf dem Feld 'Preisermittlung' der OnlineBestellposition können wir eine neue Ermittlung hinterlegen, die besagt, dass der Preis von VinX gerechnet werden soll.

7

Was benötigen wir in der VinX Datenbank?

Der Provider-Typ wird ergänzt um eine zusätzliche Auswahl Aussendienst-Portal.

Basierend darauf kann das Portal den korrekten Provider den Aussendienst-Bestellungen zuweisen.

Ergänzend wäre der Vertriebsweg auf dem Provider zu hinterlegen. Dies ist jetzt eine Systemeinstellung, aber mit der zunehmenden Anzahl von Online-Anbindungen gilt es auch hier zu differenzieren.

8

Deployment

Hybrid Connection kann REST nicht direkt anzapfen, wäre mit einer zweiten Hybrid Connection machbar.

Möglich ist auch ein Azure IP Range whitelisten für den Produktiv-Einsatz.

AppSettings speichert Credentials für den Shop.

Direktanbindung nur, wenn der Kunde REST schon über Reverse Proxy offen hat, sonst zweite Hybrid Connection.

0

Konditionen durch ADM

Der Warenkorb ist jetzt ausgerichtet auf den Shop, wo der Kunde sich natürlich nicht selber einen Sonderrabatt oder Spezialpreis geben kann.

Wenn wir diesen nun im Portal einbaue, dann wird das eventuell nicht genügen und der ADM wird einen Sonderrabatt geben wollen oder einen Preis überschreiben. Wie sind Du hier die Eingriffsmöglichkeiten und deren Beschränkungen?

Abschluss-Screen

Abschlussscreen muss noch definiert werden. Per default wird heute einfach ein leerer Warenkorb angezeigt wenn die Bestellung erfolgreich war. ->Rückmeldung-Screen definieren

Default-Screen einsetzen

Verfügbarkeit im Warenkorb

Verfügbar / nicht verfügbar - aber immer erfassbar

Expression: Wenn verfügbarer Bestand > 0 then ‘Verfügbar’ else ‘Auf Bestellung’

Warenkorb-Adresse

Scope-Adresse - wenn keiner, dann Default des Warenkorbs

Wiedervorlage früherer Bestellungen

Separat in späterer Version

Kontext-Wechsel, also Wechsel der Adresse

Im Warenkorb die Adresse ändern und neu rechnen lassen

Warenkorb persistent pro User

Ok

Pro ADM und Adresse wäre schön, würde aber zu vielen unerledigten führen. In späterer Version an Messen denken, wo mehrere Kunden gleichzeitig offen sind.

Wie erfolgt die Gebindeumrechnung von Menge auf Gebinde und umgekehrt mit dem Shop API