Neu Doppelt verbuchter Zahlungsabgleich

[ingosp2]

Ich habe einen merkwürdigen Fehler erlebt. Der liegt vermutlich in der Anbindung zur Bank - vielleicht aber auch irgendwo im Wawi (1.5.47.3).

Und zwar hatte ein Kunde eine Vorkasse ordnungsgemäß per Überweisung erledigt - am 10.11. Ordnungsgemäß zugeordnet vom Zahlungsabgleich.
Etwas später wurde dieselbe Zahlung (vom 10.11.) im Zahlungsmodul erneut registriert. Und vom Zahlungsmodul am 15.11. erneut derselben Bestellung zugeordnet. Wir haben den Betrag darum als Doppeltzahlung zurück überwiesen

Wenn man genau hin schaut, taucht die eine Zahlung vom 10.11. zweimal auf, aber das zweite mal fehlt im Namen des Senders der letzte Buchstabe.

Die Bankschnittstelle hat den Namen also 5 Tage später um ein Zeichen kürzer bekommen. Entweder hat die Bank das kürzer gesendet. Oder die Wawi-Schnittstelle hat ein Zeichen weniger abgenommen.
Und auf jeden Fall hat das Zahlungmodul dieselbe Zahlung als zwei Zahlungen gewertet, weil der Name um 1 Zeichen abgeschnitten war. Obwohl die Bankschnittstelle sicherlich jeweils nur eine Buchung geschickt hat. Auf dem Kontoauszug sieht man natürlich nur eine Zahlung.
So sieht's aus (Namen natürlich entfernt):

Das ist natürlich eine ernste Sache, weil man auf die Rückerstattung der Rückerstattung nur hoffen kann.

Was wäre da softwareseitig möglich? Mein Vorschlag:

1. mal checken, ob die Daten in der Zahlungsschnittstelle möglicherweise um 1 Zeichen abgeschnitten werden - beispielsweise ganz hinten im Datensatz. Das wäre das einfachste.
Hat die Datenschnittstelle eine Checksumme?

2. Zahlungen am gleichen Tag, mit gleichem Betreff, mit gleichem Betrag, auf dieselbe Bestellung sollten nicht neu eingestellt werden, wenn
a) die Zahlung schon da ist
b) ersichtlich ist, dass über die Bankschnittstelle die andere, schon verbuchte Zeile jetzt NICHT MEHR kommt

edit: Und jeder selber sollte vor Rückerstattungen vorher im Online-Banking prüfen, ob die Zahlung wirklich doppelt war

 

[Markus Hütz]

Hi,

wenn Deine Bank einen Umsatz tatsächlich 2x gesendet hat, also einmal an Tag 1 und einmal an Tag 2, dann wird das echt schwierig das zu verarbeiten. Der Zahlungsabgleich prüft nicht, ob ein vor 5 Tagen gemeldeter Umsatz jetzt auf einmal nicht mehr gemeldet wurde und entfernt diesen dann wieder.


Gruß,
Markus

 

[sjk]

Wir hatten denselben Bug auch schon sporadisch. Konnten aber kein eindeutiges Muster erkennen, wann dieser auftritt und haben es dann erstmal abgehakt. Hatten aber auch schon fälschlicherweise erstattet und prüfen seitdem Doppelzahlungen auch immer noch einmal im Onlinebanking.

Das Verhalten war genau gleich, d.h. ein Buchstabe hat beim Kundennamen gefehlt. Bei uns müsste das über mehrere Wawi-Versionen aufgetreten sein. Banking haben wir bei der GLS Bank.

 

[ingosp2]

Hi,

wenn Deine Bank einen Umsatz tatsächlich 2x gesendet hat, also einmal an Tag 1 und einmal an Tag 2, dann wird das echt schwierig das zu verarbeiten. Der Zahlungsabgleich prüft nicht, ob ein vor 5 Tagen gemeldeter Umsatz jetzt auf einmal nicht mehr gemeldet wurde und entfernt diesen dann wieder.


Gruß,
Markus

Hallo Markus,

der Umsatz ist nicht zweimal gesendet worden, sondern der selbe Umsatz, mit dem selben Tag, Betrag und Betreff kommt gelegentlich mit einem leicht abweichenden Namen des Kontoinhabers an - nur der letzte Buchstabe fehlt.

Wie Du am Post von Samuel gesehen hast, kommt das schon gelegentlich vor und es fehlte wieder nur 1 Buchstabe am Namen. An der Bank liegt's wohl nicht, da es auch bei einer ganz anderen Bank aufgetreten ist.

Bevor man den wirklichen Fehler in der Schnittstelle sucht, hätte ich einen Vorschlag für einen einfachen Workaround:
Wie wärs, wenn die Schnittstelle für den Zahlungseingang in der Wawi einfach den Namen nicht so wichtig nimmt?
Der Name in der Überweisung ist ja sowieso der Name des Kontoinhabers und der stimmt öfters nicht überein mit dem Besteller.
Also, wenn Betreff (mit Bestellnummer), Datum, Betrag gleich ist, dann bitte keine zwei Zahlungseingänge daraus machen!
Vielleicht den Namen komplett ignorieren oder nur die ersten 3 Zeichen davon vergleichen.

Dann könnte dadurch kein Geld mehr verloren gehen.

Das können wir aber nicht selbst machen, da muss ein Programmierer von JTL dran.

VG
Ingo

 

[Markus Hütz]

Hi,

ich werde das mal mit der Entwicklung abklären, ob es da irgendwie einen Weg gibt. Den bisherigen Erklärungen nach bezweifle ich das aber.

Sobald ich da was weiß melde ich mich.


Gruß,
Markus

 

[cashregisterstore]

Habe das Problem nun auch, doppelte Zahlungen im Zahlungsmodul. In meiner Bankingsoftware werden die Umsätze nicht doppelt angezeigt, insofern lässt sich das Problem nicht der Bank zuordnen, sondern dem Zahlungsmodul

 

[Markus Hütz]

Habe das Problem nun auch, doppelte Zahlungen im Zahlungsmodul. In meiner Bankingsoftware werden die Umsätze nicht doppelt angezeigt, insofern lässt sich das Problem nicht der Bank zuordnen, sondern dem Zahlungsmodul

Hi,

würdest Du da bitte einen Supportfall aufmachen, damit die Kollegen sich das genauer anschauen können? Dann wissen wir, ob das ein Fall ist den wir schon bearbeiten oder ob es sich hier um was anderes handelt. Danke!

Gruß,
Markus

 

[W.Pelich]

Wir haben auch das Problem.
Einige Zahlungen sind doppelt. Im Sender/Empfänger der Zahlung sind bei den Namen kleine Veränderungen.
Bei der Bank sind aber keine Doppelzahlungen.

Gestern hat der Worker sehr lange die Bestellungen und Zahlungen nicht abgerufen, obwohl laut History jede fünfte Minute ein Update durchgelaufen ist. Nachdem ein Mitarbeiter auf die fehlende Bestellungen hingewiesen hat, ich den Worker geöffnet habe, konnte ich erst keine Fehler feststellen und er hat alles planmäßig abgerufen.
Da sind dann auch einige Zahlungen doppelt eingetragen.
Wie kommt es dazu? Es sind ja nicht alle.

 

[mesh]

hier gleiches Problem. Heute früh beim ersten Abgleich der Zahlungen wurden plötzlich Zahlungen der letzten 7 Tage (ab nur einige) nochmals angezeigt obwohl schon verbucht in der Wawi.

 

[Verkäuferlein]

Wenn man genau hin schaut, taucht die eine Zahlung vom 10.11. zweimal auf, aber das zweite mal fehlt im Namen des Senders der letzte Buchstabe.

Das Verhalten war genau gleich, d.h. ein Buchstabe hat beim Kundennamen gefehlt. Bei uns müsste das über mehrere Wawi-Versionen aufgetreten sein. Banking haben wir bei der GLS Bank.

der Umsatz ist nicht zweimal gesendet worden, sondern der selbe Umsatz, mit dem selben Tag, Betrag und Betreff kommt gelegentlich mit einem leicht abweichenden Namen des Kontoinhabers an - nur der letzte Buchstabe fehlt.

Einige Zahlungen sind doppelt. Im Sender/Empfänger der Zahlung sind bei den Namen kleine Veränderungen.

Es scheint dort in der Banking-Schnittstelle Probleme zu geben, Zahlungen eindeutig zu identifizieren. Wir hatten vor einiger Zeit auch mal Probleme, bei uns war es allerdings etwas anders und im Namen waren Umlaute enthalten, die bei der Vormerkung z.B. als "ue" und bei der eigentlichen Buchung als "u" angezeigt wurden.

Es scheint also bei den Banken unterschiedliche Systeme zu geben, die den Namen und Verwendungszweck einer Zahlung unterschiedlich handeln und dementsprechend den Inhalt der entsprechenden "Felder" anders gestalten.

Gleiches gilt dann möglicherweise auch für Feld-Längen, etc.

Handelt es sich denn bei Euch jeweils um Vormerkungen und dann die eigentliche Buchung oder werden tatsächlich 2 Zahlungen angezeigt?
Gebt doch am Besten auch mal an, um welche Bank es sich jeweils handelt.

 

[SebastianB]

Es gibt bei HBCI/FinTS keine eindeutige "Id" der Zahlung. Es gibt leider auch keine garantierte Reihenfolge der Zahlungen. Wir fragen bei der Bank nach "Zahlungen der letzten X Tage". Dann schauen wir, welche Zahlungen wir schon "kennen" und die neu dazugekommenen nehmen wir hinzu. Warum fragen wir nun "die letzten X Tage ab" - na ja, weil die Banken leider auch Zahlungen "weiter hinten" erscheinen lassen. (idR laden wir die Zahlungen vom Datum der letzten uns bekannten Zahlung + 24 Stunden)
Somit hängt alles davon ab, dass wir erkennen ob wir Zahlungen schon "kennen".

Wenn jetzt die Bank heute die Zahlung mit Sender "Böhmermann" schickt und morgen die selbe Zahlung mit Sender "Boehmermann", dann sind das für uns leider zwei Zahlungen. Sprich, wenn das Banksystem "Schluckauf" hat und an einem Tag irgendetwas komisches sendet, und das dann am Tag (oder Stunden später) korrigiert - dann kommt es bei uns zu doppelten Buchungen.

Bei den Banken habe ich mittlerweile schon alles erlebt: Fehler in Verwendungszwecken, fehlende Verwendungszwecke usw. - manche Banken lassen sowas unkorrigiert, manche ändern einfach die Historie und manche korrigieren und schieben die Zahlung mit dem Datum nach vorne. All das führt dann bei uns zu Problemen.

 

[Verkäuferlein]

Es gibt bei HBCI/FinTS keine eindeutige "Id" der Zahlung. Es gibt leider auch keine garantierte Reihenfolge der Zahlungen. Wir fragen bei der Bank nach "Zahlungen der letzten X Tage". Dann schauen wir, welche Zahlungen wir schon "kennen" und die neu dazugekommenen nehmen wir hinzu. Warum fragen wir nun "die letzten X Tage ab" - na ja, weil die Banken leider auch Zahlungen "weiter hinten" erscheinen lassen. (idR laden wir die Zahlungen vom Datum der letzten uns bekannten Zahlung + 24 Stunden)
Somit hängt alles davon ab, dass wir erkennen ob wir Zahlungen schon "kennen".

Na ja, das mag ja auf der einen Seite richtig sein, auf der anderen Seite ist das bei einem so sensiblen Thema wie Geldbewegungen aber schon eine etwas laxe herangehensweise. Bei dem "schauen", ob Ihr die Zahlung schon "kennt", müsste ja vielleicht schon auffallen, dass da 2 recht ähnliche Zahlungen (gleicher Betrag, gleicher Buchungstag, Zuordnung auf gleiche Bestellung, obwohl Bestellung schon bezahlt) sind, die das gleiche Buchungsdatum (Wertstellungsdatum) haben und möglicherweise schon abgerufen wurden.

Gleichzeitig müsste ja auch auffallen, dass eine bereits "bekannte" Zahlung beim Umsatzabruf 24 Stunden rückwärts plötzlich fehlt.

Beispiel: Ich habe 10 Zahlungen von gestern, alle sind zugeordnet beim erneuten Abruf habe ich wieder 10 Zahlungen von gestern, nun sind aber nur 9 davon zugeordnet und in der Wawi habe ich plötzlich 11 Zahlungen für den Tag.
9 != 10 != 11 = Problem?

Spätestens wenn dann 2 Zahlungen zu 95% identisch sind, sollte die Alarmglocke dann endgültig schrillen.

Wenn jetzt die Bank heute die Zahlung mit Sender "Böhmermann" schickt und morgen die selbe Zahlung mit Sender "Boehmermann", dann sind das für uns leider zwei Zahlungen. Sprich, wenn das Banksystem "Schluckauf" hat und an einem Tag irgendetwas komisches sendet, und das dann am Tag (oder Stunden später) korrigiert - dann kommt es bei uns zu doppelten Buchungen.

"Never trust a banking system." oder so ähnlich... 😁

Das Problem ist ja scheinbar, dass die Banken mit unterschiedlichen Systemen bzw. System-Logiken arbeiten. Soll heißen, wenn eine vorgemerkte Zahlung angezeigt wird, hat diese vermutlich noch nicht das Buchungs- / Validierungs-System der Empfängerbank durchlaufen. Dass diese Zahlung dann nach dem Durchlaufen des Empfängersystems möglicherweise andere Parameter hat, mag zwar problematisch sein, muss dann aber trotzdem durch (Subsembly oder) Euer System validiert werden.

Bei anderen Bankingsoftwares und den betroffenen Banken gelingt dies ja auch.

Bei den Banken habe ich mittlerweile schon alles erlebt: Fehler in Verwendungszwecken, fehlende Verwendungszwecke usw. - manche Banken lassen sowas unkorrigiert, manche ändern einfach die Historie und manche korrigieren und schieben die Zahlung mit dem Datum nach vorne. All das führt dann bei uns zu Problemen.

Tja, leider hat mich das hier beschriebene Problem jetzt auch erwischt und ich würde fast vermuten, dass das Problem doch vielmehr in der Bankingschnittstelle und der Art des Abrufs liegt.

Bei uns war leider wieder mal - ohne dass irgendeine Fehlermeldung oder ähnliches auftaucht - der automatische Bank-Abgleich "gesperrt" und die Eingabe einer Photo-TAN zur Umsatzholung erforderlich (auch das könnte eine Bankingschnittstelle erkennen und proaktiv darüber informieren, zumal der Abgleich ja auch automatisch gesperrt wird.)

Wir haben jetzt eine doppelte (Ab-)Buchung über Kontogebühren in der Liste nicht zugewiesener Zahlungen, weil der Verwendungszweck abweicht. Das sollte ja eigentlich eine wiederkehrende gleichartige Buchung sein und ist zuvor bei den Kontogebühren nie passiert, also nur in Kombination mit der langfristigen Rückwärtsholung der Buchungen im aktuellen Kontext.

Kann es möglicherweise sein, dass es eine Art Cache (z.B. bei Subsembly) gibt, der kurzfristig (z.B. die Zahlungen der letzten 24 Stunden) zwischenspeichert und ggf. eine Validierung zur Duplikatsvermeidung durchführt, bei größeren Abgleichszeiträumen dann aber nicht mehr greift?

 

[Verkäuferlein]

Nach unserem Juni-Ausfall des Zahlungsmoduls, mit anschließender Neueinrichtung des Bankkontos haben wir jetzt auch einen Zahlungsausgang, welchen wir manuell über das Onlinebanking ausgeführt haben, der mit komplett identischen Daten (bis auf das Datum) 2x eingelesen wurde und dementsprechend auch 2x im Zahlungsmodul angezeigt wird.

Aktuell hatten wir dann jetzt den ersten Ausfall im Juli. Es wurde eine fehlerhafte PIN gemeldet, obwohl diese seit eh und je unverändert im SecureVault hinterlegt war und genutzt wurde. Durch die Fehlermeldung werden dann scheinbar die Credentials gelöscht und der Abgleich mangels Zugangsdaten dann nicht wieder aufgenommen. Wir mussten also den gleichen PIN erst erneut im SecureVault hinterlegen um den Abgleich wieder zum Laufen zu bringen.

Auch werden scheinbar tatsächliche Doppelzahlungen nicht zugeordnet (oder zumindest automatisch erkannt), obwohl die Rechnungsnummer im Verwendungszweck angegeben ist, sondern ein Auftrag mit "Wertung" 0,33 aus 2019 vorgeschlagen, der knapp 100 Euro unter dem Zahlbetrag liegt.

 

[mh1]

Nur als Anmerkung dazu (für den dns interessiert) und weniger zur Lösung des eigentliche Problems in diesem Thread...

Es gibt bei HBCI/FinTS keine eindeutige "Id" der Zahlung. Es gibt leider auch keine garantierte Reihenfolge der Zahlungen.

Die Umsätze wurden in FinTS bisher üblicherweise im Swift MT940-Format übertragen. Dort ist kein Identifier für einzelne Buchungen vorgesehen. Siehe https://de.wikipedia.org/wiki/MT940
Das Format ist steinalt - es stammt gefühlt ungefähr aus den 70ern.

Seit ungefähr SEPA gibt es zwar mit CAMT ein neues XML-basiertes Format, in dem es einige Stellen gibt, die eventuell als Transaktionsidentifier verwendet werden könnten.
Z.B. <Prtry><Ref> oder <AcctSvcrRef>
100%ig verlassen kann man sich darauf aber auch nicht, weil das sind keine Pflichtfelder.

Es soll aber sowieso auch noch Banken geben, die die SEPA-Daten mit dem großen Hammer wieder zu MT940 verwursten und damit werden ja sowieso viele Felder für SEPA-Neuerungen abgeschnitten.

 

[Verkäuferlein]

Nur als Anmerkung dazu (für den dns interessiert) und weniger zur Lösung des eigentliche Problems in diesem Thread...

Ist doch immer gut, auch was über die Hintergründe zu erfahren und was neues zu lernen.

Ansonsten behauptet sicherlich auch keiner, dass JTL das mit Absicht (oder besser gesagt Vorsatz) so macht oder das es nicht auch Schwierigkeiten in anderen Systemen gibt, die man da umschiffen muss.

Aber am Ende des Tages kostet das Zahlungsmodul knapp 240 Euro / Jahr, wenn ich mir dann Starmoney anschaue, den dort gebotenen Funktionsumfang und die dafür aufgerufenen Kosten, erwarte ich zumindest, dass es sich um einen wirlichen automatischen Zahlungsabgleich handelt, der die abgerufenen Zahlungen auch validiert bzw. auf Plausibilität prüft und nicht einfach nur irgendwelche Daten von irgendeinem Fremdsystem übernimmt.

Mir ist bisher auch noch kein Banking-Programm begegnet, welches Umsätze regelmäßig doppelt anzeigt.

Wie gesagt, fängt es ja dort an, dass es nicht sein kann, dass ich auf dem Bankkonto 10 Umsätze habe und in der Wawi 11 oder der Bankabgleich aussteigt und der Worker "Erfolgreich beendet" meldet.

 

[mh1]

Aber am Ende des Tages kostet das Zahlungsmodul knapp 240 Euro / Jahr, wenn ich mir dann Starmoney anschaue, den dort gebotenen Funktionsumfang und die dafür aufgerufenen Kosten, erwarte ich zumindest, dass es sich um einen wirlichen automatischen Zahlungsabgleich handelt, der die abgerufenen Zahlungen auch validiert bzw. auf Plausibilität prüft und nicht einfach nur irgendwelche Daten von irgendeinem Fremdsystem übernimmt.

Ich wusste gar nicht, dass das Modul so teuer ist. Ich bin auch der Meinung, dass es für diesen Preis mehr bieten müsste als einfach nur Daten bei der Bank abfragen.

Mir ist bisher auch noch kein Banking-Programm begegnet, welches Umsätze regelmäßig doppelt anzeigt.

Oh, das kommt aber schon vor.
Ist halt meistens dann, wenn die Bank plötzlich was ändert. In letzter Zeit kommt das z.B. häufig vor wenn die Bank von Girocard auf Debitcard umstellt. Vorher stand "Rewe-Markt" im Feld X und jetzt stehts in einem anderen.... Dann kommt es halt drauf an, wie schnell die Programmierer der BankingApp das anpassen können. ...und wen man dieses Forum über einen längerem Zeitraum mitliest, kann man zugegebenermaßen schon den Eindruck kriegen, dass die JTL Programmierer nicht immer ganz schell Dinge fixen

Wie gesagt, fängt es ja dort an, dass es nicht sein kann, dass ich auf dem Bankkonto 10 Umsätze habe und in der Wawi 11 oder der Bankabgleich aussteigt und der Worker "Erfolgreich beendet" meldet.

Da hast du recht.

 

[MarcoWue]

Hallo,
wir haben bei der Deutschen Bank das gleiche Problem. Wir müssen vorgemerkte Zahlungen nutzen, da die Wertstellung von Buchungen bei der Deutschen Bank zwar taggleich, aber erst nach Versandschluss erfolgt.

Hierbei gibt es bei den finalen Buchungen in einigen Fällen Abweichungen, diese betreffen aber ausschließlich den Absendernamen der Transaktion - alle anderen Felder sind 100% identisch:

• Endgültige Buchungen haben ein Limit von 50 Zeichen beim Absendernamen - mehr werden abgeschnitten. Vorgemerkte Buchungen haben dieses Limit nicht -> bei langen Absendernamen wird die Zahlung folglich doppelt gebucht.
  => Lösung: Zahlungsabgleich sollte beim Vergleichen der Absendernamen nur die ersten x Zeichen heranziehen - die ersten 20 wären hier sicher ausreichend
  
  
• Endgültige Buchungen enthalten u.U. weniger Leerzeichen als vorgemerkte Buchungen ("xy GmbH + Co KG" vs "xy GmbH + CoKG")
  => Lösung: Leerzeichen beim String-Vergleich grundsätzlich ignorieren ("xyGmbH+CoKG")

Wie ist hier der Stand? Gibt es eine Issue hierzu?

Da es JEDEN JTL Kunden mit Zahlungsabgleich über Konto bei der Deutschen Bank und Commerzbank (und potenziell anderen) betrifft, sollte hier eine gewisse Dringlichkeit gegeben sein.

Grüße,
Marco

 

[Markus Hütz]

Hallo,
wir haben bei der Deutschen Bank das gleiche Problem. Wir müssen vorgemerkte Zahlungen nutzen, da die Wertstellung von Buchungen bei der Deutschen Bank zwar taggleich, aber erst nach Versandschluss erfolgt.

Hierbei gibt es bei den finalen Buchungen in einigen Fällen Abweichungen, diese betreffen aber ausschließlich den Absendernamen der Transaktion - alle anderen Felder sind 100% identisch:

• Endgültige Buchungen haben ein Limit von 50 Zeichen beim Absendernamen - mehr werden abgeschnitten. Vorgemerkte Buchungen haben dieses Limit nicht -> bei langen Absendernamen wird die Zahlung folglich doppelt gebucht.
  => Lösung: Zahlungsabgleich sollte beim Vergleichen der Absendernamen nur die ersten x Zeichen heranziehen - die ersten 20 wären hier sicher ausreichend
  
  
• Endgültige Buchungen enthalten u.U. weniger Leerzeichen als vorgemerkte Buchungen ("xy GmbH + Co KG" vs "xy GmbH + CoKG")
  => Lösung: Leerzeichen beim String-Vergleich grundsätzlich ignorieren ("xyGmbH+CoKG")

Wie ist hier der Stand? Gibt es eine Issue hierzu?

Da es JEDEN JTL Kunden mit Zahlungsabgleich über Konto bei der Deutschen Bank und Commerzbank (und potenziell anderen) betrifft, sollte hier eine gewisse Dringlichkeit gegeben sein.

Grüße,
Marco

Hallo zusammen,

ich habe das (noch nicht öffentliche) Ticket WAWI-75555 erstellt. Wir werden uns das Problem nochmal genauer anschauen.

Danke für das Feedback!

Gruß,
Markus

 

[Markus Hütz]

Hallo zusammen,

ich habe mir die Problematik von der Entwicklung erklären lassen. Jede Bank stellt die vorgemerkten Umsätze anders zur Verfügung und/oder verarbeitet diese anders, wenn der Umsatz real wird. Einige Banken wandeln den vorgemerkten Umsatz um, andere löschen diesen und erstellen einen neuen Umsatz und wieder andere Banken belassen den vorgemerkten Umsatz und erstellen einen weiteren Umsatz.

Einige Banken stellen die Umsätze je nach Zugriff (FinTS, EBICS, ...) unterschiedlich schnell zur Verfügung. Hier bitte mit der Bank klären, ob ein Wechsel das "Problem" löst.

Bezüglich doppelter Zahlungen möchte ich nochmal auf einen vorherigen Kommentar von SebastianB und für vorgemerkte Umsätze auf unseren Hinweis zu verweisen:



Hier sind und aktuell leider die Hände gebunden.

Gruß,
Markus

 

[Verkäuferlein]

Hallo @Markus Hütz,

danke fürs Prüfen und die Rückmeldung.

Wie geht denn das Zahlungsmodul mit Blitz-Überweisungen um, wenn die vorgemerkten Umsätze nicht abgeholt werden?

Und wie schaut es mit der Zuordnung aus, wenn tatsächlich eine Doppelzahlung erfolgt?

Gruß
Verkäuferlein