Artikelpreise auf 0 Euro!

Ich habe hier einen Shop (OXID 4.8.1.und PayPal 3.1.0), der korrekte Bestellbestätigungen versendet - in der Bestellübersicht gibt es aber einige Bestellungen bei denen alle Artikel der Bestellung mit 0 € aufgeführt werden, ebenso wenn ich mir die PDF-Rechnung generieren lasse.

(finde hier keine Zusammenhänge, außer dass das nur bei Vorauskasse-Bestellungen auftritt, aber nicht bei allen)

Beim Blick auf die betreffenden OXORDERARTICLES sehe ich in der Datenbank die Werte der OXNETPRICE, OXBRUTPRICE, OXBPRICE und OXNPRICE alle auf 0. Gesetzt ist hier lediglich OXPRICE. Wie gesagt wurde jedoch die Bestellbestätigung mit den richtigen Preisen versandt.

Hat jemand eine Idee?

Wenn eine Bestellung storniert wurde sind die Preise “genullt”.

OK, jetzt hab ich es etwas genauer:

Unmittelbar nach der Bestellung ist alles OK. Wenn ich die Bestellung im Administrationsbereich aber nochmal abspeichere (zum Beispiel um die Lieferadresse zu ändern), springen die Artikelpreise der Bestellung auf 0 €.

Hhm, ich glaub ich mal mal das Update auf die neueste Version… Oder hat jemand eine Idee?

Bei jeder Änderung einer Bestellung wird ein “virtueller Warenkorb” gefüllt und alle Werte erneut berechnet. Eventuell sind die Artikel als nicht mehr bestellbar markiert oder gar nicht mehr vorhanden, so das diese Neuberechnung fehlschlägt und die Artikel als storniert markiert werden.
Das ist jetzt aber alles nur konstruiert.

Danke schon mal für die Hilfe bei der Fehlersuche!

Also ich hab mir von dem Ganzen nun eine Kopie gezogen und auf 4.8,7 geupdated - leider ohne Erfolg.

Das Problem tritt bei allen Bestellungen auf, die Artikel sind auf Lager und bestellbar. Ich kann irgendeine Bestellung aufrufen, speichern und die Preise der Bestellung springen auf 0 €.

[ul]
[li]Alle Module sind deinstalliert.[/li]
[li]Die Versionsprüfung sagt, “Dieser OXID eShop wurde nicht verändert und ist original”[/li]
[li]Nichts zu sehen in den Log-Dateien.[/li][/ul]

Hat jemand noch eine grobe Richtung? Mal die DB mit einer Original-Version vergleichen?

[ol]
[li]Deine Benutzer sind in den Gruppen Preis A, Preis B und Preis C?
[/li][li]Du hast dafür keine Preise hinterlegt?
[/li][*]In den Grundeinstellungen unter Artikel die Option "Den normalen Artikelpreis verwenden, wenn keine A, B, C Preise vorhanden sind " nicht aktiviert?[/ol]

Hallo, vielen Dank für den Tipp.

Nein, diese Gruppen sind leer, keine Preise hierfür hinterlegt und Einstellung 3. ist aktiviert.

Habe nochmal etwas herausgefunden.

Bei der Neuberechnung des Warenkorbs werden immer die Variantenpreise herangezogen, die in der Regel leer gelassen wurden und somit auf 0 stehen. Gebe ich hier den Preis des Vaterartikels bei der Variante ein ist alles OK.

[B]Scheinbar funktioniert die Logik hier nicht, bei nicht vorhandenen Variantenpreisen automatisch den Preis den Vaterartikels zu holen.[/B]

Workaround: Neuberechnung deaktivieren: https://github.com/leofonic/No_Recalc

Vielen Dank Frank,

die Funktionalität, den Warenkorb neu zu berechnen, wäre aber schon wichtig. In diesem Fall geht es auch nicht darum, das sich Artikel in der Zwischenzeit geändert hätten, sondern, dass OXID sich weigert, den Preis des Vaterartikels in der Berechnung zu verwenden…

Ich werde jetzt mal auf dem gleichen Server eine parallele Neuinstallation aufsetzen. Dann mal testen… Und dann mit der importieren DB des Live-Systems. Ach herrje… :-/

Ich habe das jetzt nochmal getestet:

Auch bei einer unangetasteten Neuinstallation 4.8.7 tritt das Problem auf:

[B]Auf 0 belassene Variantenpreise ziehen sich zwar im Frontend den Preis den Vaterartikels - nicht aber bei der Neuberechnung im Backend beim erneuten Speichern der Bestellung. Hier wird die 0 herangezogen…[/B]

Ich glaube es ist an der Zeit, das böse Wort mit “B” auszusprechen…

https://bugs.oxid-esales.com/main_page.php
:wink:

jep, kann ich bestätigen.
Nachvollziehbar unter http://demoshop.oxid-esales.com/professional-edition mit einer Version 4.8.7

Erbt eine Variante den Preis vom Vaterartikel, wird der Preis bei einem recalculate im Admin nicht wieder korrekt geholt, sondern es werden die 0 EUR der Variante gespeichert.

In früheren Shopversionen hatten Vaterartikel überhaupt keine Preise. Dort musste eine Variante immer ihren eigenen Preis haben. Ich kann jetzt nicht sagen, wann das geändert wurde. Offensichtlich wurde dabei das recalculate nicht korrekt angepasst.

Kannst Du das eintragen?

Ich? Nein!
Das Privileg wollte ich dem TO überlassen :slight_smile:

Danke fürs bestätigen, Thomas.

Ich kümmere mich gleich mal darum - vielen Dank für eure Anteilnahme :wink:

Gibt es einen Bucktrack Eintrag dazu bzw. ist das Problem schon gelöst? In CE 4.9.0 besteht das Problem immer noch.
Danke und Grüße

Ja, stimmt.
Der Bug ist in 5.0.14 / 4.7.14, 5.1.8 / 4.8.8 und 5.1.9 / 4.8.9 sowie in allen Versionen >= 5.2.4 / 4.9.4 behoben.