Hallo, ich hab in der Tabelle orders Bestellungen drin, bei denen die Spalten customers_address_format_id delivery_address_format_id billing_address_format_id auf 0 stehen. Da es das Template 0 nicht gibt werden keine ISO-Codes für Liefer- oder Rechnungsadresse gesetzt. Der Shop selbst schein damit erstmal kein Problem zu haben, weshalb es mir jetzt erst bei der Anbindung an die JTL-Wawi aufgefallen ist. Die Wawi kann keine Bestellungen ohne ISO-Code bei Lieferadresse oder Rechnungsadresse übernehmen und genau diese Bestellungen haben oben genanntes Problem. Ich habe versucht es weiter einzugrenzen, aber es sind - Gast- und Endkundenbestellungen - verschiedenste Zahlungsmöglichkeiten - verschiedenste Versandmöglichkeiten Die einzige Gemeinsamkeit die ich bisher feststellen konnte ist dieses address_format. Mit dem Adress-Format hatte ich meines Wissens nach bisher nichts zu tun und wüsste auch gar nicht wo man dazu etwas einstellen könnte im Adminbereich, insofern ist das alles auf Standard. Hier wäre eine Info hilfreich an welcher Stelle das adress_format gewählt und gesetzt wird, damit ich einen Ansatzpunkt zum Testen habe. Noch ein Hinweis: Dieser Fehler ist wahrscheinlich kein direkter Version 3.3.xx Fehler, da ich ältere Bestellungen mit dem Problem in der Datenbank habe.
Eine 0 darf in der Spalte eigentlich per Definition nicht stehen, wenn es das gibt ist deine Shopdatenbank korrupt. Man könnte das relativ leicht per SQL ändern. Wenn du das nicht selbst tun willst wirf ein Ticket ein, dann sehen wir uns das an. Ne grobe Idee aus was für einem Shop oder was für einer Shopversion die Bestellungen kommen?
Also wie ich überall wo eine 0 ist per SQL eine Nummer eines gültigen adress-Templates hinbekomme weiß ich. Mir ist allerdings noch nicht der Unterschied der 5 Adress-Templates klar bzw. nach welchen Kriterien die vergeben werden. Also die Altbestellungen mit dem Fehler dürften aus einer Version vor 3.0.2.0 kommen, da ich im Zuge der Anbindung des neuen JTL-Connectors einen Umzug von Version x (weiß ich nicht mehr genau) auf 3.0.2.0 über den importer gemacht habe. Das Problem tritt aber im aktuellen 3.3.2.0er Shop auch auf, ich habe aktuell 15 Bestellungen seit 31.03.2017 mit dem Problem, finde aber den gemeinsamen Nenner nicht.
Da könnten wir also ein Problem haben, in Form von durch den Importer nicht übernommenen Daten, das wäre möglich und zu untersuchen. Das muss man dann echt mal untersuchen. Können wir machen, wenn ein Ticket da ist.
Hallo Wilken, ich hab mal etwas weitergeforscht und den Importer können wir sicher ausschließen. Vor dem Import sind in der alten Datenbank 2 Bestellungen mit dem Fehler aus 2013 und 2014 schon drin. In dem Datenbankbackup direkt nach dem Import sind die genannten 2 fehlerhaften Bestellungen drin, aber keine weiteren die fehlerhaft sind. Ich hab mal ein Ticket aufgemacht, da ich hier selbst nicht weiterkomme.