Tach zusammen.
Es kann an sich nichts mit der Zahlungsart zu tun haben, da wir es auch in einem B2B
Shop ohne Zahlungsmodule haben (rein auf Rechnung).
Tritt auf seit Update von 27.3 auf 33.0 und hängt wohl am Sync (oder den internen Prozessen nach dem Sync).
Sporadisch und aktuell nicht nachvollziehbar betrifft es Kunden, die bereits in der DB sind (also Wiederbesteller)
Es sieht so aus, das
vereinzelt bei diesen Kunden (deshalb bei einigen wohl auch verstärkt bei
Ama Pay (also Zahlungsarten wo auch eine Adresse mitkommen kann) die Standardrechnungsadresse in tAdresse auf 0 gesetzt wird.
Wenn der Auftrag dann geöffnet und/oder von Trigger greifbar bearbeitet wird, stellt die
Wawi fest, das der Kunde keine Standardadresse hat und entfernt die Bindung zum Auftrag (nett von ihr)
In tBestellung steht dann in tKunde_kKunde eine 0 - die restlichen Angaben zum Auftrag und auch zum Kunden sind da und
nicht verloren.
Ab dem Moment greifen bei diesen Aufträgen keine Einstellungen zur Kundengruppe oder andere über den Kunden gesteuerten Prozesse mehr. Bei Neukunden wurde das Verhalten noch gar nicht festgestellt. MAn könnte also vermuten, das der Prozess des Syncs daran Schuld hat, der Prüft ob der Kunde bereits eine Standradrechnungsadresse hat (also bereits vorhanden ist).
Da die Kundennummer im Auftrag (Frontend Wawi) noch zu sehen ist, kann man mit 3 Abfragen das Ganze händisch in der DB korrigieren. Es scheint da nichts verloren zu sein. Da das aber halt erst dann ausgelöst wird, wenn mit einem Auftrag was passiert, kann man es aber eben auch ganz schlecht Monitoren.
Was wir in jedem Fall schon gefunden haben, sind neue Gutschriften in der Datenbank, die bei kkunde bugbedingt ebenfalls 0 haben. Der Auftrag hat den Status gutgeschrieben aber es gibt keinen Bezug zum Kunden. Dort wird die Gutschrift in der 360 auch nicht angezeigt. Wichtig zu korrigieren, bevor es am Monatsanfang in den Export in Richtung
Datev geht!
Ob und wie es sich verhält, wenn nicht dem Kunden zugeordnete Aufträge ausgeliefert wurden und Rechnungen generiert wurden (was ohne Zuordnung über kkunde an sich gar nicht geht) das prüfen wir auch erst im Block wenn das Problem hoffentlich schnell gefixed ist.
Ein kleiner Workaround hilft bei uns in der Verwaltung, die vor Versand erstmal zu blockieren und zu reparieren bevor sie zum Versand kommen und da vielleicht Probleme machen (oder danach):
Workflow: Auftrag erstellt
Zeitgesteuert: 0h und 0 min
Bedingung = erweiterte Eigenschaft:
Löst aus, das der Auftrag mit einem Rückhaltegrund BUG-Kontrolle - zurückgehalten wird. Durch einfaches Öffnen stellt der Kollege dann fest ob der Auftrag i.o oder korrumpiert ist.
Grüße Olli
