Neu Gezielt Aufträge mit Kundennummern / Lieferadressen zurückhalten

[Huhugonzo]

Moin Moin,

wir haben das Problem, dass wir zwei / drei Kunden haben, die gezielt versuchen über Amazon Fälle zu öffnen für angebliche "Untermengenlieferungen" etc. Von 6 Bestellungen die jedesmal 3 gleiche Postionen enthielten, sollen angeblich bei jeder Bestellung immer nur zwei Artikel dem Kunden geliefert worden sein.

Ich habe gerade einen Workflow angelegt der gezielt Aufträge mit der Kundennummer 123456 zurückhält, sodass unsere interen Abteilung vor Auslieferung des Artikels die Bestellung einfach stornieren kann. Mir ist klar, dass wenn dieser Kunde über andere Plattformen wie Otto / Kaufland natürlich neue Kundennummern bekommt und das dieser Workflow hinfällig ist.

Am liebsten wäre es mir ein Workflow so zu definieren, dass geprüft wird, ob Kundennummer 1234, 4321, 6789 eine Bestellung abgibt, Zudem sollte sichergestellt werden, dass wenn Postleitzahl, Straße + Nummer als Lieferadresse definiert ist, dass der Auftrag ebenso zurückgehalten wird. Einige User machen sich den Spass daraus, immer wieder neue Kundenaccounts auch unter anderem in unseren Shop anzulegen, aber die Lieferadresse natürlich gleichbleibend ist.

Ich habe versucht den Workflow mit mehreren Kundennummern und dem RegEx Wert (mal mit, oder auch mit | getrennt) zu definieren, dann hat der Workflow leider nicht gegriffen.

Ich vermute mal, dass wenn ich es mit mehreren Kundennummern befüllen zudem die Lieferadresse berücksichtigt werden soll, das wir um ein CustomWorkflow nicht unhinkommen, oder?

Uns wäre es wichtig, dass wir die "Liste" bzw. den Workflow in Zukunft immer weiter mit unliebsamen Kundennummern sowie Lieferadressen erweitern können

Bin gespannt, wie ihr solche Sachverhalte via Workflowas abfangt.

Besten Gruß
Frank

 

[dapole]

Hi!

Also: -> Siehe Screenshot!

Und: Das ist keine Option? Ich mein, eigentlich ist es doch genau, was ihr sucht. und dort kann man unzählige Kunden hinzufügen.
Es ist ja einer 'Oder' Verknüpfung zwischen den kunden ....


Gruß

 

[Huhugonzo]

Moin Mon @dapole

Danke, das mit der Suchen und oder Funktion ist ein sehr guter Hinweis um gezielt nur nach Kundennummern zu suchen. Habe den bestehenden Workflow mal angepasst. Kann man das mit der Lieferadresse nicht auf eine Bedingung herunterbrechen mit dem Ziel, dass nur 1 Bedingung erfüllt sein muss, damit der Workflow greift. Hierzu müsste man aber die jetzigen 3 Bedingungen (Straße, Postleitzhal sowie Ort als eine Bedingung definieren können.

Das geht meines wissens nicht oder? Letzendlich soll der Workflow nur sicherstellen, dass explizit Lieferungen an bestimmten Adresse sowie Kundennummern vermieden werden sollen.
Lieben Gruß
Frank

 

[dapole]

Nun ja ....

Wahrscheinlich geht das schon, was du vor hast....

... Schau mal ganz oben: (Screenshot)

Du kannst oben sagen, ob alles zutreffen muss, oder nur eine dieser Bedingungen ...
Dein Screenshot sagt mir:

Alle Werte, die du oben konfiguriert hast, müssen 'stimmen'., damit deine Aktion ausgeführt werden kann.

Und du kannst ja mehrere Workflows für ein Ereignis machen, was spzusagen von oben nach unten abgearbeitet wird ....
Aber ich vermute, dass ich dir mit der Aussage oben, schon geholfen habe

 

[frankell]

Kann man das mit der Lieferadresse nicht auf eine Bedingung herunterbrechen mit dem Ziel, dass nur 1 Bedingung erfüllt sein muss, damit der Workflow greift.

Mit einer Erweiterten Eigenschaft sind Dir keine Grenzen gesetzt bei der Verkettung von Und-/Oder-Bedingungen. In der jetzigen Form ist es ja so, dass Du sowohl nach bestimmten Kundennummern suchst (innerhalb derer als "oder") als auch nach bestimmten Adressen. Der Sinn ist aber sicher, nach entweder Kundennummer oder Adresse zu suchen. Hier könnte man zwar auch mit mehreren verschachtelten Workflows arbeiten, aber eine Erweiterte Eigenschaft, in der mehr als eine Bedingung (Adressteile) geprüft wird, ist hier sicher die beste Wahl.

Weil Du oben von CustomWorkflows sprachst: Diese beziehen sich lediglich auf eine Workflow-Aktion, nicht auf eine Bedingung. Bei den Bedingungen (weil nur lesender und nicht schreibender Natur) kann man sich mit DotLiquid, ggf. ergänzt um SQL, voll austoben.

 

[wawi-dl]

Wir lösen so etwas über SQL-Abfragen in erweiterten Eigenschaften.

Wer das komfortabler will, kann das auch mittels CustomWorkflows machen, hier kann man bis zu 10 Parameter definieren, was ausreichen sollte.
Damit sollte man auf jeden Fall etwas lösen können, notfalls auch mit einer Art Levenhstein Funktion.