Zahlungsmodul Workflow

[feuershow.de]

Hallo, ich habe das Zahlungsmodul neu eingerichtet, da es in meinem teureren Paket eh enthalten ist. Es funktioniert gut soweit.
Manche Zahlungen können aber nicht zugeordnet werden, weil KundInnen den Betreff falsch ausfüllen.
Jetzt wollte ich mir einen Workflow machen, der mich darüber informiert per Email, wenn dies der Fall ist.
Ich habe aber nichts gefunden. Kann es sein, dass das Zahlungsmodul gar nicht in die Workflows integriert ist?
Das wäre ja absurd, da der Sinn von Automatismen wieder ausgehebelt wird, wenn ich jeden tag 2 x da reinschauen muss, ob alle zahlungen zugewiesen werden konnten?
Steh ich auf dem Schlauch, wie habt ihr das problem gelöst?
Merci Sam

 

[frankell]

Hallo, ich habe das Zahlungsmodul neu eingerichtet, da es in meinem teureren Paket eh enthalten ist. Es funktioniert gut soweit.
Manche Zahlungen können aber nicht zugeordnet werden, weil KundInnen den Betreff falsch ausfüllen.
Jetzt wollte ich mir einen Workflow machen, der mich darüber informiert per Email, wenn dies der Fall ist.
Ich habe aber nichts gefunden. Kann es sein, dass das Zahlungsmodul gar nicht in die Workflows integriert ist?
Das wäre ja absurd, da der Sinn von Automatismen wieder ausgehebelt wird, wenn ich jeden tag 2 x da reinschauen muss, ob alle zahlungen zugewiesen werden konnten?
Steh ich auf dem Schlauch, wie habt ihr das problem gelöst?
Merci Sam

Hallo Sam,

es ist tatsächlich so, wie Du es beschreibst. Einen eigenen Workflowbereich für Zahlungen bzw. den Zahlungsabgleich gibt es nicht. Lediglich wenn ein Auftrag vollständig bezahlt wird, kann daraufhin etwas vollautomatisch laufen. Aber was Du beschreibst, ist das genaue Gegenteil dessen.

Da bleiben Dir letztlich nur zwei Möglichkeiten:

1. Anlegen eines sog. CustomWorkflows, der in regelmäßigen Abständen (bspw. alle 8 Stunden oder täglich zu bestimmten Zeiten oder ...) überprüft, ob Zahlungen nicht zugeordnet wurden und diese dann per E-Mail auszugeben. Aber das setzt entsprechende SQL-Kenntnisse voraus.
2. Anlegen eines eigenen Triggers in der Datenbank, der dasselbe wie der CustomWorkflow macht, aber eben für jede eingegangene Zahlung. Setzt ebenfalls entsprechende SQL-Kenntnisse voraus.

Das Schöne an SQL ist, wenn man es denn beherrscht, dass man eine Prüfung noch granularer gestalten kann, was sinnvoll ist, wenn auf dem Konto nicht nur Zahlungen von Kunden für Aufträge eingehen.

Der Vorteil an Variante 2 ist, dass jede Zahlung nur einmal geprüft wird. Zumindest theoretisch. Denn manchmal - je nach Bank und von dieser genutzten Standards - führen Ankündigungen und Buchungen zu zwei Vorgängen im Zahlungsabgleich.

VG,
Frank

 

[intrinsicforce]

Einen eigenen Workflowbereich für Zahlungen bzw. den Zahlungsabgleich gibt es nicht.

Doch, scheinbar seit neuestem (1.9.5.2):


Ich habe das gleiche Problem und werd das mal versuchen über einen Workflow zu lösen. Momentan geht das eventuell nur über erweiterte Eigenschaft, indem geprüft wird, ob z.B. die Auftragsnummer des zugewiesenen Auftrags leer ist. Mal schauen ob das klappt.

Allerdings löst es nicht das viel größere Problem, dass man je nach Bank trotzdem täglich einen Kontenabruf über die Bankwebsite machen muss, wegen der von @frankell beschriebenen Problematik der Vormerkposten.

 

[frankell]

Doch, scheinbar seit neuestem (1.9.5.2):
Den Anhang 114292 betrachten

Ich habe das gleiche Problem und werd das mal versuchen über einen Workflow zu lösen.

Allerdings löst es nicht das viel größere Problem, dass man je nach Bank trotzdem täglich einen Kontenabruf über die Bankwebsite machen muss, wegen der von @frankell beschriebenen Problematik der Vormerkposten.

Ach, Du ahnst es nicht! Dass ich das noch erleben darf: Workflows für den Zahlungsabgleich...

Vielen Dank für den Hinweis, @intrinsicforce!

Gibt es denn nicht irgendein Merkmal in einer Vormerkung, das sich tatsächlich von einer Buchung unterscheidet und auch tatsächlich in der Datenbank landet, welches man mit einer Erweiterten Eigenschaft abfragen könnte?

 

[feuershow.de]

Dankeschön, das schaut interessant aus!
Ist die 1.9.5.2 schon stabil? Bin da etwas vorsichtig geworden.
Beim Zahlungsmodul gibt es glaube ich die Option, diese vormerkposten nicht zu nutzen.
Ich habe das gewählt und bisher das Problem nicht gehabt. Aber das habt ihr wahrscheinlich schon lange rausgefunden.

 

[frankell]

Dankeschön, das schaut interessant aus!
Ist die 1.9.5.2 schon stabil? Bin da etwas vorsichtig geworden.
Beim Zahlungsmodul gibt es glaube ich die Option, diese vormerkposten nicht zu nutzen.
Ich habe das gewählt und bisher das Problem nicht gehabt. Aber das habt ihr wahrscheinlich schon lange rausgefunden.

Hier im Forum gab es Berichte über Probleme mit PayPal-Zahlungszuordnungen nach dem Update von der 1.9.4.6 auf eine höhere. Deswegen bin ich da grad auch vorsichtig mit einem Update.

 

[intrinsicforce]

Gibt es denn nicht irgendein Merkmal in einer Vormerkung, das sich tatsächlich von einer Buchung unterscheidet und auch tatsächlich in der Datenbank landet, welches man mit einer Erweiterten Eigenschaft abfragen könnte?

Ja, für Vormerkposten gibt es einen Bool. Müsste aber mit SQL dann abgefragt werden, da diese Variable noch nicht für Zahlungs-Workflows verfügbar ist.

Anscheinend klappt auch die Prüfung mit leerer Auftragsnummer nicht ohne SQL. Die Variable lässt sich zwar auswählen (über "ZugewiesenerAuftrag"), aber ist immer leer, auch bei zugewiesenen Zahlungen. Der Workflow kann sich demnach scheinbar die Daten noch nicht richtig ziehen.

 

[frankell]

Ja, für Vormerkposten gibt es einen Bool. Müsste aber mit SQL dann abgefragt werden, da diese Variable noch nicht für Zahlungs-Workflows verfügbar ist.

Anscheinend klappt auch die Prüfung mit leerer Auftragsnummer nicht ohne SQL. Die Variable lässt sich zwar auswählen (über "ZugewiesenerAuftrag"), aber ist immer leer, auch bei zugewiesenen Zahlungen. Der Workflow kann sich demnach scheinbar die Daten noch nicht richtig ziehen.

Aha, also die allseits beliebte halbfertige Veröffentlichung. Nun denn.

Aber dann hat man ja immerhin schon mal etwas, was man abfragen kann. Die Frage ist nur, ob ein Workflow nach "Einlesen" tatsächlich etwas Unerwünschtes verhindern oder ob man sich nur selbst per Mail darüber benachrichtigen kann.

 

[feuershow.de]

Hier im Forum gab es Berichte über Probleme mit PayPal-Zahlungszuordnungen nach dem Update von der 1.9.4.6 auf eine höhere. Deswegen bin ich da grad auch vorsichtig mit einem Update.

Ja genau solche Sachen meinte ich, bin im Moment bei der 1.9.4.3 mit einigen Problemen (zb falsche bzw doppelte Ausgabe auf Lieferschein der tatsächlich gebuchten Anzahl an Stücklistenartikel (seit Mai!), Rechteproblematik die zum Einfrieren führt).
Würde gerne updaten und auch die Workflows hier mitnehmen, mir würde auch erst einmal eine Email reichen.
Aber mit den Problemen jetzt haben wir einen Umgang gefunden, neue müssen wir erst erkennen.
Früher fand ich das nicht schlimm, weil bei dem Preis klar war, wir sind Versuchskaninchen, aber inzwischen find ich das das nicht ok ist, so lange solche krassen Fehler wie doppelte Anzahl auf Lieferschein, die wirklich Geld gekostet haben, weil rausgeschickt und Kunden nicht auf Email reagiert haben, so lange nicht gefixt sind.
Aber ich denke, wir werden es probieren...

 

[feuershow.de]

Genau meine 2 Probleme scheinen gelöst, allerdings kommt das paypal Problem hinzu neu laut den comments auch dort beim Zahlungsmodul:

 

[intrinsicforce]

Update:

Über Ticket [WAWI-78660] könnt ihr nun dafür voten, dass über Workflows geprüft werden kann, ob Zahlungen verarbeitet worden sind.

https://issues.jtl-software.de/issues/WAWI-78660

 

[intrinsicforce]

Ich war wohl der einzige der ein Vote abgegeben hat. Wenn ihr nicht wollt, dann eben nicht. Abgewiesen.

 

[frankell]

Ich war wohl der einzige der ein Vote abgegeben hat. Wenn ihr nicht wollt, dann eben nicht. Abgewiesen.

Den Anhang 114652 betrachten

Ich hätte ja gevotet, aber ich kann mich nicht im Issue-Tracker einloggen. -> Verschwörung! 😂

 

[feuershow.de]

Ich hätte ja gevotet, aber ich kann mich nicht im Issue-Tracker einloggen. -> Verschwörung! 😂

Dito

 

[frankell]

Dito

Aha! Bin ich also nicht der Einzige. Bei mir ist das schon länger so, habe mich aber erst vor zwei Wochen oder so dazu bequemt, mal ein Ticket aufzumachen. Das erste wurde nicht beantwortet. Beim zweiten heißt es, sei an die Entwickler weitergegeben.
So kann man sich die lästigen Votes natürlich auch vom Leib halten. Also doch Verschwörung. 😂

 

[feuershow.de]

Jipie, habe gerade das update gemacht und alles scheint erstmal zu funktionieren.
Um wieder back zum ursprünglichen topic zu kommen, ich bin am Workflow, jetzt gibts ja neu als auslösendes Ereignis "Zahlungsabgleich" ganz hinten.
Teilzahlung/Überzahlung konnte ich abbilden.

Jetzt geht´s um nicht Zuordnung. Ich will, dass ich eine Email bekomme, wenn eine Zahlung nicht zugewiesen werden konnte, wenn z.B. der Betreff nicht korrekt war etc.
Als auslösendes Ereignis habe ich Eingelesen genommen, also prinzipiell jeder Zahlungseingang, der erkannt wird. Dann habe ich Ausschlusskriterien gemacht, nämlich eine zugewiesene Bestellnummer und (interne Überweisungen von dkb).
Mal schauen ob es klappt...

 

[intrinsicforce]

Jipie, habe gerade das update gemacht und alles scheint erstmal zu funktionieren.
Um wieder back zum ursprünglichen topic zu kommen, ich bin am Workflow, jetzt gibts ja neu als auslösendes Ereignis "Zahlungsabgleich" ganz hinten.
Teilzahlung/Überzahlung konnte ich abbilden.

Jetzt geht´s um nicht Zuordnung. Ich will, dass ich eine Email bekomme, wenn eine Zahlung nicht zugewiesen werden konnte, wenn z.B. der Betreff nicht korrekt war etc.
Als auslösendes Ereignis habe ich Eingelesen genommen, also prinzipiell jeder Zahlungseingang, der erkannt wird. Dann habe ich Ausschlusskriterien gemacht, nämlich eine zugewiesene Bestellnummer und (interne Überweisungen von dkb).
Mal schauen ob es klappt...

Bei mir hat das nicht geklappt. Und laut JTL geht es auch noch gar nicht (1.9.5.2.)
Problem war bei mir dabei erstmal, dass das Ereignis "Eingelesen" mit dem Worker mehr als nur einmal stattfindet. Ich konnte auch nicht prüfen, ob eine Bestellnummer zugewiesen wurde oder nicht (Ergebnis war immer false / nicht zugewiesen)

 

[feuershow.de]

Bei mir hat das nicht geklappt. Und laut JTL geht es auch noch gar nicht (1.9.5.2.)
Problem war bei mir dabei erstmal, dass das Ereignis "Eingelesen" mit dem Worker mehr als nur einmal stattfindet. Ich konnte auch nicht prüfen, ob eine Bestellnummer zugewiesen wurde oder nicht (Ergebnis war immer false / nicht zugewiesen)

Ok, das erklärt, dass alte Zahlungen gerade noch einmal per Workflow getriggert wurden.
Den Teil mit Bestellnummer geht aber glaube ich (1.9.5.4), zumindest war mein Testworkflow von alten Bestellungen je nach Einstellung getriggert oder nicht.

Ich geb Bescheid, wenn ein apar tage rum sind, aber vermutlich wird`s wie bei Dir sein