Neu Bei abweichender Lieferadresse diese automatisch in den Auftrag übernehmen

[nuesseonline]

Hallo,
heute habe ich nochmal eine Frage zur Auftragserstellung.
Dieses Thema wurde schon mehrmals diskutiert, aber außer den Hinweis auf Auftragsbearbeitung 2.0 habe ich nichts gefunden.

Folgendes Szenario:
Wir haben viele Kunden mit einer abweichenden Lieferadresse zu Ihrer Rechnungsadresse. Diese haben wir auch hinterlegt und auch als Standard gekennzeichnet (damit wir beim abhaken "Lieferadresse=Rechnungsadresse" nicht noch in die Adressen rein müssen um die Lieferadresse auszuwählen).

Nun kommen bei uns sehr viele Aufträge im Laufe des Tage telefonisch rein und wir gehen in der Kundenverwaltung auf "Auftrag erstellen". Leider übersieht man dann ab und zu mal, dass der Kunde eine abweichende Lieferadresse hat und erstellt den Auftrag, ohne dass man das Häkchen bei "Lieferadresse=Rechnungsadresse".
Dann haben wir den Salat und die Ware geht dann an die Verwaltung eines Marktes oder an den Hauptmarkt, obwohl die Ware an eine Filiale verschickt werden sollte.

Da man dieses Häkchen nicht dauerhaft entfernen kann, nun zu meiner Frage.

Könnte man dieses irgendwie mit einen Workflow lösen, und wann kann man mit "Auftrag 2.0" rechnen?

Bei den Ansatz mit einem Workflow bin ich schon am verzweifeln, denn wir haben bei uns die unterschiedlichsten Arten an Kunden und auch noch Vertreter und haben sehr vieles über Workflows gelöst und ich weiß nicht, wo ich das noch einschieben kann und wie.

Nur damit Ihr wisst was ich meine, hier noch ein paar Bilder der Workflows die bei uns laufen in der Auftragsabwicklung.

Ich danke schon mal für Eure Hilfe und eventuellen Ideen zu den Lösungsansatz.

 

[gnarx]

1. Eigentlich sollte JTL ja so schlau sein das der Hacken nicht gestezt wird wenn eine Lieferadresse vorhanden ist.
2. Wenn nicht kannst ja über einen Workflow abfragen ob eine Lieferdresse (Strasse oder so) vorhanden ist das er dir ein PopUp anzeigt.

Die Checkbox "Rechnungsadresse=Lieferadresse" kann man scheinbar nicht abfragen bzw. den Hacken rausnehmen lassen.
Man könnte es wohl auch über ein "Eigenes Feld" hin basteln.

 

[nuesseonline]

1. Eigentlich sollte JTL ja so schlau sein das der Hacken nicht gestezt wird wenn eine Lieferadresse vorhanden ist.

Leider ist es noch nicht so ;0(

2. Wenn nicht kannst ja über einen Workflow abfragen ob eine Lieferdresse (Strasse oder so) vorhanden ist das er dir ein PopUp anzeigt.

Naja, da wird mir wohl nichts anderes über bleiben. Habe schon einige eigenen Felder, da tut eines nun auch nicht mehr weh. Aber es ist schade, dass man eine so einfache rudimentäre Sache über Umwege gestalten muß.

Ich wünsche allen einen schönen Feiertag Morgen.

 

[Dalibor Josic]

Mit Powershell könnte man sich etwas basteln. Nachdem der Auftrag geschlossen/gespeichert wird fragt ein Workflow ab, Checkbox beim Kunden, ob eine Lieferadresse gesetzt werden soll, wenn ja dann per Dropdown Lieferadresse auswählen. So ungefähr. Die Checkbox ist nur notwendig, damit nicht bei jedem Kunden eine Lieferadresse ausgewählt werden muss.

 

[Maritimia]

Es ist unglaublich, dass das nicht einfach so funktioniert. Mir passiert das mit der Lieferadresse auch immer bei den Kunden, die sowieso empfindlich sind. Für den Sofortauftrag habe ich folgende Lösung:

Bedingung für Workflow bei Auftrag Erstellt:
1. Plattform enthält " JTL-Wawi"
2. Über Erweiterte Eigenschaften eine Abfrage bauen, die True liefert sobald mehr als 0 Lieferadressen beim Kunden angebenen sind.

Aktionen:
Wert setzen für Lieferung.Lieferadresse.Straße = Vorgang.Stammdaten.Kunde.Lieferadressen.ErstesObjekt.Straße ...für alle weiteren wie Ort, PLZ usw. äquivalent verfahren.

Wenn der Workflow die Lieferadresse setzt, nimmt die Wawi automatisch den Haken aus der Checkbox "Kundenadresse=Liefradresse".

 

[Enrico W.]

Mit Auftrag 2.0 sollte das Problem aus der Welt sein. In meinem Test wurde hier automatisch die erste Lieferadresse hinterlegt.
Vorsicht bei der manuellen Anlage müsst ihr dann aber dennoch walten lassen, da auch bei mehreren Lieferadressen nur die erste automatisch berücksichtigt werden kann.
Daher sollte bei der Anlage manueller Aufträge IMMER eine der ersten Fragen sein, wohin geliefert werden soll. Wenn man sich das angewöhnt, dann ist man auch auf der sicheren Seite.

 

[MichaelH]

@Enrico W.

Na, dann wäre es doch besser die WAWI würde Intelligenz beweisen und bei einem manuellen Auftrag würde ein Fester aufpoppen mit der Auswahl der Lieferadressen inkl. Button Lieferadresse = Rechnungsadresse ?

 

[Enrico W.]

mmhh - ja, ist nicht ganz von der Hand zu weisen. Ich fürchte aber, dass hier jeder andere Vorgehensweisen präferieren wird.
Der eine möchte gleich die erste Lieferadresse automatisch haben, der nächste eine Abfrage, der nächste ärgert sich dann darüber, dass etwas automatisch hinterlegt wird oder dass er jedes mal eine Abfrage wegklicken muss.

Ich geb das noch mal weiter, damit man das noch mal genauer prüft, meine Befürchtung ist aber, dass man es da nicht allen Recht machen kann.

 

[MichaelH]

Ja ja, das mag JTL nicht, wobei es so was wie Kennzeichen / Einstellungen gäbe wo das jeder selbst einstellen können dürfen täte.

Aber einfach Daten automatisch einfügen ohne dies ggf. zu bemerken ist nicht weniger kritisch als Daten die vorhanden aber gewünscht sind gar nicht einzufügen.

-> Abweichende präferierte Lieferadresse einfügen: Ja / Nein / Vorschlag anzeigen - klingt doch weder kompliziert noch aufwändig ?

-> Und einfach die 1. Lieferadresse zu verwenden ist ähnlich "unsinnig" wie die 1. Artikelkategorie beim Artikel als Hauptkategorie, weil man das nicht wirklich steuern bzw. ändern kann. Ein Kennzeichen "Standardlieferadresse" wäre klar.

 

[Enrico W.]

Das Problem bei Einstellungen ist halt immer, dass sich mit jeder Einstellung der Entscheidungsbaum verdoppelt, was mögliche Fehlerquellen mit jeder nachfolgenden Einstellung potenziert.
Gleichzeitig muss man versuchen, die Einstellungen so gering zu halten, dass sie den User nicht erschlagen.
Wie gesagt, ich finde Deine Bedenken durchaus angebracht und geb das zur Prüfung weiter. Meine Ausführungen zeigen nur halt meine Gedanken dazu und stellt keine Entscheidung dar.

 

[MichaelH]

Ja, ich bin mir der JTL-Abneigung gegen Einstellungen bewusst ... ... was aber immer noch im krassen Gegensatz zu moderner parametrierbarer Software steht.
Die Zeit in der man JTL einfach installiert und loslegt ist schon länger vorbei, es ist alles zusammen im Online-Handel zu komplex geworden.

Insofern ist diese Haltung nicht mehr so ganz "up-to-date".

 

[MichaelH]

So könnte es in jedem Programmteil (z.B. bei F5-Kunde) einen Button geben der mir ein Fenster mit Register anzeigt in dem ich die "Anzeigemöglichkeiten" und "Einstellmöglichkeiten" ggf. sogar bezogen auf den User finden kann. Da täten sich für User und auch Entwickler ganz neue Möglichkeiten der Flexibilisierung auf.

Hatte ich vor Jahren schon angeregt, Ergebnis ist bekannt.

Diskussionen wird es immer geben, egal wie man es macht, aber (grundsätzliche) Möglichkeiten schaffen ist selten falsch.
Und wenn man etwas nur aktivieren oder de-aktivieren muss oder kann, was soll daran schon falsch sein ?

 

[Enrico W.]

Nachdem ich kurz mit Manuel dazu Kontakt hatte hab ich das mal in dieses Ticket gepackt. Gern könnt ihr dort voten und kommentieren.
https://issues.jtl-software.de/issues/WAWI-55298

 

[Maritimia]

Die meisten Kunden mit abweichender Lieferadresse haben nur eine abweichende Lieferadresse. Wer tasächlich viele Kunden mit mehreren Lieferadressen hat, kann bei der Workflow Bedingung auf Anzahl Lieferadressen auf genau 1 testen. Dann passt der Workflow bei denen, die eine Lieferadresse haben und bei denen, die mehrere haben bleibt es wie es ist.
Als Lösung für mehrere Lieferadressen könnte man einen zweiten Workflow einrichten, der auf Lieferadressenanzahl > 1 testet und dann z.B. in das Lieferadressenfeld "Strasse" einen Text hineinschreibt wie "MEHRERE LIEFERADRESSEN" und in "Ort" reinschreibt "BITTE AUSWÄHLEN". Wichtig: bei PLZ das Feld mit einem Leerzeichen füllen. Nachteil an der Aktion ist, dass man das erst beim Versenden sieht. Damit nicht ein Unsinns-Etikett gedruckt wird, ist das Leerzeichen bei PLZ drin. Dann meckert die Versandlabel-Ausgabe und gibt kein Etikett aus.

 

[MichaelH]

Das erinnert mich an die Plausbilitätsprüfung der 1980er Jahre, bei der die Fehler der Eingabe am Drucker ausgedruckt wurden.
🤣

 

[Maritimia]

Noch etwas zu dem Thema "möglichst wenige Einstellungen". Ich glaube es muss möglichst viel und am besten alles einstellbar und konfigurierbar sein. Für Einstiegsnutzer der Wawi könnt ihr ja einen Satz Grundeinstellungen mitliefern. Dann kann jemand schon mal loslegen und mit der Wawi arbeiten. In Laufe der Zeit wird er merken, dass er vieles anders konfigurieren möchte, weil es zu seinen Abläufen besser passt. Profianwender programmieren sich heute die Workflows selber und passen Formulare an und möchten vor allem mit möglichst wenigen Klicks zum Ziel kommen. Ich hasse z.B. die Messageboxen, die nur ein OK haben und mir sonst keine Auswahl zulassen. Warum? Sie sind umsonst, weil ich kann eh nur OK klicken kann und habe wieder einen Klick mehr. Die Profi-User werdet ihr aber in Zukunft verlieren, wenn die sich nicht alles so konfigurieren können, wie sie es brauchen. Wenn ihr diese User verliert, werdet ihr nicht mehr besser mit der Wawi und das Produkt JTL-Wawi wird nur noch die Einstiegsklientel bedienen. Das ist der Anfang vom Ende ....

 

[Dalibor Josic]

Messageboxen sind nicht dazu da um nur auf OK zu klicken, sondern dir eine Info zu geben. Zumindest weisst du dann das dieser Kunde mehrere Lieferadressen hat und du kannst zumindest händisch eingreifen. Weiter oben habe ich eine Möglichkeit aufgezeigt, wie man es umsetzen könnte bis JTL es eventuell umsetzt.

 

[Enrico W.]

@Maritimia Diese Messagebox weist dich darauf hin, dass bei dem Kunden schon mal mindestens zwei Adressen vorhanden sind. Die Rechnungsadresse und die Lieferadresse.
Es spricht absolut nichts dagegen, dass dein Kunde die Ware auch mal an seine Rechnungsadresse gesendet haben möchte. Daher halte ich die letztliche Rückfrage durchaus für sinnvoll, sofern mindestens zwei Adressen vorhanden sind.

 

[Maritimia]

Hallo ihr zwei Dalibor & Enriko,
wer lesen kann ist glatt im Vorteil. Ich schribe eine Massagebox, die nur ein OK hat. Hat die oben vorgeschlagene Massagebox nur ein OK? Nein!
Versucht mal den Zusammenhang meiner Sätze geistig zu erfassen. Danke

 

[Dalibor Josic]

Ich hasse z.B. die Messageboxen, die nur ein OK haben und mir sonst keine Auswahl zulassen. Warum? Sie sind umsonst, weil ich kann eh nur OK klicken kann und habe wieder einen Klick mehr.

Wie kann man das falsch verstehen ?

wer lesen kann ist glatt im Vorteil.

Wir können lesen. Wie du siehst auch schreiben.

Versucht mal den Zusammenhang meiner Sätze geistig zu erfassen. Danke

Warum so agressiv ?