Hallo liebes Forum Team,
ich hoffe, einer von euch kann mir helfen. Da ich das Forum duchsucht habe und diesen Beitrag noch nicht gefunden habe, eröffne ich ein neues Thema!
Problem:
Einige Artikelpreise wurden geändert. Bei Bestellungen, die vor der Preisänderung getätigt wurden, ändern sich nach der Preisänderung die Artikelpreise, wenn man im “Stamm” das Bezahltdatum setzt und dann den Button “Speichern” drückt. Eigentlich ist auch egal, ob man das Bezahltdatum einträgt oder nicht. Sobald der Button “Speichern” gedrückt wird, zieht es die aktuellen Preise an. Es sollen jedoch bei den alten Bestellungen die alten Preis in der Rechnung bestehen bleiben.
Somit ändert es rückwirkend die Rechnungen ab und der bezahlte Betrag stimmt nicht mehr mit der vorherigen, ausgedruckten Rechnung überein.
Ein Bug?
Verwendete Version 4.6.1 Oxid CE.
Was kann ich tun? Wo liegt der Fehler?
Eine Einstellung falsch?
War es schon immer so? Ich meine nicht…
Bitte gebt mir eine Rückmeldung!
Vielen Dank!
Gruß
Flo
Hallo,
normales Verhalten, etwas ungünstig, aber kann man nichts machen.
Moin zusammen,
das ist dann definitiv ein Bug!
Wozu gibt es denn die oxorderarticles mit hinterlegten Preisen?
Preisänderungen sind ja nun nichts Exotisches und wie soll ich dann die Verkäufe hinterher auswerten können?
Beste Grüsse
Thomas
Vielen Dank für die Antworten.
Ja, ich denke, daß unbedingt dieses Thema angegangen werden muß.
Sobald Preisänderungen ins Spiel kommen, verwirren wir unsere Kunden.
Es gibt ja auch Kunden, die Ihre Rechnung verloren haben… dann nach zwei Wochen anfragen… und dann habe ich eine völlig andere Rechnung mit anderen Preisen als vorher…
Da ich die Option “Zahlung auf Rechnung” anbiete, wird immer ca. 2 Wochen nach dem Versand der “Bezahlt-Status” gesetzt. Somit ändert sich dann auch auf einmal die Rechnung im Oxid, wenn eine Preisänderung in diesen zwei Wochen gemacht wurde.
Papierrechnungen habe ich ja sowieso - Gott sei Dank.
Leider ist mir dies erst gestern aufgefallen, da größere Preisänderungen vor ein paar Tagen anstanden… bei Check “Geldeingang” zu “Rechnung” hat dann garnichts mehr gestimmt. Denn es gab ja auch viele Bestellungen VOR der Preisänderung oder in diesem Zeitraum.
Die Preise müßten doch fest “eingefroren” werden bei einer Bestellung.
Die Frage ist nun:
Gibt es dann wenigstens in der Zukunft ein “Zurück”? d.h. sind nun viele Rechnungen, die ich im System habe nun irreparabel geschädigt? Oder kann das System auf Stichtage zurückgreifen mit den alten Peisen?
Ihr kennt euch sicherlich besser aus als ich in der Programmierung. Vielleicht gibt es eine schnelle Lösung…
Ich bedanke mich für eure Bemühungen und die Tips!
Flo
Das heißt, wenn ich Glück habe, wird es in der 4.6.3 CE behoben, oder?
Es wundert mich, daß nicht schon mehr reklamiert haben.
Falls es eine schnelle Lösung geben sollte, gebt bitte bescheid!
Danke!
[QUOTE=oxid-flo;97397]Das heißt, wenn ich Glück habe, wird es in der 4.6.3 CE behoben, oder?
[/QUOTE]
Du hast heute kein Glück. https://bugs.oxid-esales.com/changelog_page.php?version_id=142
Gibt es denn bei diesem Thema Neuigkeiten? Wir haben das Problem leider noch immer.
da es ein recht komplexes Thema ist, steht die Lösung noch aus, hier ist der Sammel-Bug:
https://bugs.oxid-esales.com/view.php?id=4624
wenn sich Preise bei einer bestehenden Bestellung ändern würde ich das nicht als komplexes Thema, sondern als groben Designfehler bezeichnen. 
Moin zusammen,
das hat nichts mit Design zu tun sonder ist schlicht und ergreifend ein MEGAKAPITALER Systemfehler!
Und SO schwer ist der nicht zu beheben…
Bei meinen Kunden läuft das schon länger richtig!
Beste Grüsse
Thomas
Design = Softwaredesign und nicht Layout
das liegt einfach daran, dass jedesmal beim Klick auf “Speichern” die Bestellung anhand der aktuellen Gegebenheiten neu berechnet wird anstatt die Gegebenheiten vom Bestellzeitpunkt zu verwenden
so werden also damals gültige und jetzt nicht mehr aktuelle Rabatte oder Sonderpreise nicht berücksichtigt etc…
und diese Neukalkulation passiert sogar, wenn man das Bezahl- oder Versanddatum eingibt und dann speichert
Wobei dieses Thema nur dann relevant ist, wenn man diese Geschichten direkt im Shop-Admin macht und nicht mittels Schnittstelle in einer angeschlossenen Warenwirtschaft erledigt.
Tom - Du könntest Deine Lösung ja mal der Entwicklung durchreichen, dann gehts vielleicht schneller mit der Umsetzung. Am einfachsten ein Diff der betreffenden Dateien an Marco schicken, der reichts dann entsprechend weiter.
Moin zusammen,
viele kleine und mittlere Shops scheuen sich einfach, eine “riesige” Warenwirtschaft an den Shop ranzuhängen so lange es auch irgendwie “so” geht.
Und mit dem beiliegenden Rechnungsmodul werden die Kunden dazu ja quasi eingeladen.
Und das Problem bekommt dann eine ganz andere Brisanz, wenn man auf unterschiedlichen Platformen (Shop, Ebay, Amazon) zu unterschiedlichen Preisen verkauft und die Bestellungen hinterher in den Shop importiert.
Da man dann z.B. bei Vorkasse den Zahlungseingang manuell setzen muss, wird die Bestellung dann irgendwann angefasst. D.h. die (richtig) übergebenen Preise von Ebay und Amazon werden dann mit den aktuellen (dann falschen) Shoppreisen ersetzt.
Das führt dann dazu, dass Kunden beim automatisierten Rechnungslauf (Shopmodul) auf der Rechnung die falschen Preise wiederfinden und Amok laufen.
Über eine Veröffentlichung des Fixes werden wir hier einmal diskutieren…
Ein “bisschen” Arbyt steckte da ja doch drin sich in die Tiefen des Shops hereinzuwühlen.
Allerdings wundert es mich sowieso, dass noch kein Herausgeber von Amazon- oder Ebaymodulen über den Bug gestolpert ist.
Beste Grüsse
Thomas
Hi,
ich glaube, das ist alles andere als trivial. Man müsste ja die komplette Preishistorie (inklusive Marktplätze) mitführen und zur Zeit der jeweiligen Order matchen. Dabei entsteht wahrscheinlich irrsinniger Datenmüll. Ich bin da für jeden Ansatz dankbar.
Gruß
Moin Marco,
das siehst du, glaube ich zumindest, etwas zu kompliziert.
Die Preise werden von den Portalen bzw. den Schnittstellen ja korrekt an den Shop übergeben.
Meistens sind die dann auf Grund der aufgeschlagenen Provisionen teurer als im Shop direkt.
Wenn ich dann beigehe und die Bestellung auf bezahlt setze würde der Shop jetzt den höheren Portalpreis mit dem niedrigeren Shoppreis ersetzen.
Das würde dann dazu führen, dass der Kunde einen niedrigeren Preis auf der Rechnung bekommt als bei der Bestellung (und führt zu o.g. Amokläufen).
Ich muss also nur das recalculate (<- Stichwort) des Einzelpreises verhindern.
Und schon stimmen die Preise wieder für die Portale 
Beste Grüsse
Thomas
Es gibt doch die ganzen oxorder… - Tabellen, wo genau liegt da jetzt das Problem, die Konditionen zum Zeitpunkt des Kaufs wie Preise, Rabatte,Gutscheine, Währung etc mit abzulegen? Dazu noch die Neuberechnung des Warenkorbs auf das Nötigste reduzieren und nicht automatisch zum Beispiel beim Eintragen des Versand- oder Zahlungseingangsdatums auslösen - oder am Besten gleich nur manuell auszulösen via Button.
Damit dürfte das meiste an diesem “Problem” bereits erledigt sein.
Und Tom - (kleiner Exkurs…), Open Source funktioniert anders. Du verdienst mit lizenkostenfreier Software Deine Brötchen, kleine Gegenleistung ist ein Brocken Code, der allen zugute kommt. So steuert jeder nach seinem Vermögen und Talent einen kleinen Teil zum Großen und Ganzen bei und die OXID-Familie wächst und gedeiht!
Moin Ray,
ich glaube, ich bin der letzte, der hier nicht schon des öfteren Leutchen unter die Arme gegriffen hat, ohne bei mir danach die Faktura anzuwerfen.
Wenn es allerdings um “Codebröckhen” geht, deren Entwicklung doch einige Stunden intensive Arbyt gekostet hat (ist nicht so trivial, sich in die Tiefen der Berechnung reinzudenken) dann sei mir bitte nicht böse, wenn ich das nicht sofort auf Github stelle.
Wie ich Ray schon weiter oben schrieb, werden wir das Thema hier noch diskutieren und ich sag dann “Bescheid!”.
Übrigens hast du Recht! Die Konditionen, Preise etc. etc. WERDEN zum Zeitpunkt des Kaufs in den “ganzen oxorder… - Tabellen” abgelegt, nur leider hinterher immer wieder neu berechnet und aktuallisiert. Völliger Quatsch!
Beste Grüsse
Thomas
Hallo Tom,
vielen Dank für den Hinweise auf diesen Thread! Jetzt bleibt nur eine Frage, soll ich warten, bis du dich entschieden hast, ob du dein Wissen freigibst und ich dann den Bug mit deiner Hilfe fixen kann. Oder soll ich mich selber ran setzen und versuchen das in den Griff zu bekommen (wo ich ehrlich gesagt schwarz sehe). Aber wie sagt man so schön, versuch macht klug.
Beste Grüße! TIM
