Bestellungen teilweise mit Zahlart Empty

Hallo liebes Forum,

wie im Titel gesagt, wird bei Zahlungen sporadisch diese Zahlart im Backend hinterlegt. Zusätzlich bei Zahlungen mit Paypal (habe nicht Paypal Plus) noch der Status “not_finished” ausgewiesen.
Außerdem wird nur der Grundpreis, ohne die ausgewählten Optionen aus den Auswahllisten, im Backend angezeigt, somit sind die anschließenden Pdf-Rechnungen auch falsch. Die eingehende Mail-Bestellung
sowie die Zahlungen an Paypal oder Vorauskasse sind ebenfalls in Ordnung.
Dieses Phänomen tritt vllt. bei jeder 5.-7. Bestellung auf.
Die Grundeinstellungen Versandarten, Versandkostenregeln sind überprüft, alle Artikel sind entsprechend zugeordnet.
In der Tabelle oxorder stehen ebenfalls die falschen Daten.
Erstmals wurde das Problem am 3.8.19 festgestellt.
Ich habe die CE 6.1.4 mit einem child-theme, PHP ist 7.1

Hat jemand von euch eine idee? Vielen lieben Dank.

Tippe auf Zahlung nicht abgeschlossen.

Dies sagt der Status aus, jemand hat Zahlart gewählt wo er anschließend noch zahlen muss oder die Bestellung abgebrochen hat.

Ansonsten bleibt Dir nichts anderes übrig als dies näher unter die Lupe zu nehmen evtl. Kunde befragen, Logging aktivieren etc.

Die Idee hatte ich auch schon.
Das eigentliche Problem ist, dass die Bestellung nicht korrekt ins Backend übertragen wird.
So sieht die Bestellmail aus:

So sieht es im Backend aus, es wurde nur der Grundpreis übertragen. Nicht aber die zusätzlichen Auswahlfelder “Länge” und “Anzahl Schlüssel”

Entsprechend wird auch die Pdf-Rechnung falsch ausgegeben. Das ist eigentlich mein richtiges Problem.

Gruß Michael

Hey Michael :slight_smile:

das natürlich blöd…

Kannst Du es näher eingrenzen z.B. nur bei PayPal Express oder nur wenn Auswahlfelder da sein sollten?

Im zweiten Screenshot von Dir sieht man, dass Bezahlung mit Empty. Da scheint irgendwas nicht richtig verarbeitet zu werden. Dies deutet stark auf ein Fehler hin.

Sehr gut wäre es wenn dieses Problem reproduzieren kannst. Dann könntest Dir dies debuggen, indem selber Testbestellungen absetzt.

Grüße,
Tim

Hallo Tim,

das verzwickte ist ja, dass es sowohl beim Zahlungsdienstleister secupay, bei Vorkasse oder bei Papal auftritt. Zu 95% habe ich immer Auswahlfelder, meistens wird alles korrekt ins Backend übertragen.
Es lässt sich kein roter Faden erkennen, wo man ansetzen könnte.

Guten Morgen,

ich konnte die Fehler eingrenzen.

Es betrifft immer 2 Hersteller in den Kategorien, A und B. A stand für sich und B auch.
Dann habe ich Hersteller A unterteilt in Mechanik und Elektronik, ebenso auch Hersteller B. Zeitlich kann die Umstellung mit der ersten Empty-Zahlart passen.
Views wurden aktualisiert. “Seo-Url´s neu berechnen” habe ich nicht gemacht, da ich damit schon mal
ein Nichterreichen des Shops verursacht habe. Kategoriebaum wurde auch nicht neu indiziert.
Die Weiterleitung auf die neuen Kategorien erfolgt doch shopseitig, oder irre ich mich da? Was kann ich jetzt machen?

Gruß Michael

Ok das heißt der Fehler liegt anscheinend nicht an der Zahlart wenn neben PayPal eine weitere Zahlart betroffen ist.
Dort hilft nur eine individuelle Analyse inkl. Debbugging. Gibt es ein Testsystem? Wieviele Module kommen zum Einsatz?

Gerne kann ich Dir ein Angebot unterbreiten. Würde vorschlagen könnte es mir kostenfrei ca. 1-2 Stunden angucken. Falls ich Dir nach meiner Analyse sagen kann woran es liegt, dann kann ich Dir ein Angebot unterbreiten was ich für eine Behebung nehmen würde. Dazu würde ich die Zugangsdaten für Test oder Live Umgebung benötigen. Gerne weiter über eine private Nachricht. Mich findest unter https://bisweb.me telefonisch bin ich ab Mittwoch wieder erreichbar.

Guten Morgen,

ich habe den Fehler jetzt reproduzieren können.

Die Bestellung kommt mit der richtigen Zahlart, allen Kriterien aus den Auswahllisten und dem korrekten Endpreis im Backend an.

Ich nutze die Versender DHL (für Packstation) und GLS, wobei GLS voreingestellt ist. Ändere ich nun die Versandart von GLS auf DHL, trage den Tracking Code ein und speichere, erscheint als Zahlart “Empty”. Desweiteren steht dann nur noch der Grundpreis des Artikels in der Bestellung und auch in der Rechnung. Die Felder und zusätzlichen Aufpreise aus den Auswahllisten sind weg.

Im Demo-Shop konnte ich es nachvollziehen. Ich habe die Versandart von “Standard” auf “Beispiel Set1” geändert, schon ist die Zahlart nach dem Speichern “Empty”. Die Varianten sind natürlich noch da, weil die stehen ja in der DB.

Vorsichtig würde ich das mal als Bug bezeichen.

Gruß Michael

Guten Morgen @neuling2 :slight_smile:

ah okay kommen der Sache schon näher. Verstehe ich das richtig, jemand bestellt bei Dir mit gewählter Versandart GLS. Nach der Bestellung gehst Du in den Admin und änderst die Versandart manuell auf DHL und trägst den Tracking Code ein. Nachdem Du Deine Änderung gespeichert hast, stimmt die Zuweisung zur Zahlart nicht mehr und dort steht dann “Empty”?

Jau, so is et. Auch im Demo-Shop.

Im Prinzip bedeutet dies die Zuordnung der Zahlart zur Bestellung geht in der Datenbank verloren durch Deine Änderung. Dies hat dann zur Folge das Rechnung falsch etc.

Als Workaround wäre Dir dort geholfen, wenn bei Änderung der Versandart sichergestellt wird das die Zuordnung zur Bezahlart noch stimmt. Dies sollte zur Folge haben, dass Rechnung und Co. wieder stimmen sollten.

Eigentlich ja.

Noch einfacher wäre es, die Versandart nicht zu ändern. Ich sehe ja am Tracking Code, welcher Versender es ist.

Da ja standardmäßig für nur einen Versender eine Tracking-Mail erzeugt wird, bei mir GLS, muss ich bei Versand mit DHL eh eine Versand-Mail mit entsprechendem Link von Hand verfassen und senden.

Wichtig für mich war zu wissen, wo der Fehler liegt. Der Aufwand, immer neue Rechnungen von Hand zu erstellen, ist schon enorm. Ich belasse es jetzt dabei und werde die Versandart nicht ändern und gut ist.

Vllt liest ja jemand mit, der das Problem weitergeben kann.

Wenn Dies für Dich so passt. Ist das vollkommen okay.

Dort würde ich Dich bitten Dein Problem in den OXID Bugtracker Main - OXID eShop bugtrack einzureichen dafür ist dieser gedacht und dadurch leistest Du einen Beitrag um OXID besser zu machen.

Wünsche Dir noch ein schönes, sonniges Wochenende.

Habe es eingetragen, allerdings in deutsch. Glaube, es muss in englisch sein.

1 Like

Dankeschön, da wird sich bestimmt jemand vom OXID Team finden welcher es für seine Kollegen in Ungarn übersetzt :slight_smile:

Suaheli und Hindu hätte ich hinbekommen, englisch kann ich nicht.

:thinking:

@marco.steinhaeuser verwechsel ich das nun? Ungarn ist mir im Kopf geblieben. Kann auch Emarsys Marketing Suite sein :smiley: