Content Comparison

1

Wie werden die Adressen markiert

Analog zum Produktzyklus auf dem Artikel gibt es einen Kundenstatus auf der Adresse. Hier sind frei definierbare Einträge möglich

2

Bestehende Felder für Aktiv und Kunde

Diese werden neu durch den Status befüllt. Ob eine Adresse aktiv und Kunde ist, lässt sich auf dem Adressstatus hinterlegen.

3

Wie lässt sich der Adresstatus in VinX Auswertungen nutzen?

Der Adressstatus ist ein Selektionskriterium auf allen Auswertungen mit Adresselektion, darunter auch Mailings.

4

Welche Adressstati dürfen die ADM nutzen

Dies wird auf dem Adressstatus fixiert. Hier lässt sich definieren, welche Art von Änderungen die ADM durchführen dürfen.

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.

• Neue Adressen erfassen

• Begrenzte Änderungen - Status, Anschrift, Kontaktpersonen

• Vollständige Änderungen