hallo,
meinereiner stellt sich mit dem gleichen problem des recalculate bugs und der shopversion ce 4.7.3 auch gerne daneben, winkt freundlich und freut sich über eine angebotene lösung…
gruß
stefan
Ich habe mir das Modul mal angesehen und wollte es eigentlich für die 4.7 lauffähig machen. Dabei habe ich einen Blick auf die Logik geworfen und festgestellt dass der Prozess beim Speichern einer Rechnung in Oxid relativ kompliziert ist. Es wird aus allen Artikeln ein virtueller Warenkorb zusammengestellt, der wird dann durch die Maschinerie Versandkostenberechnung etc. gejagt und daraus eine neue Bestellung generiert, die wird dann gespeichert. Das ist teilweise sogar notwendig, wenn z.B. die Versandart geändert wird oder neue Artikel dazukommen. Aber warum sollte man etwas an der Bestellung ändern, schließlich hat der Kunde das so bestellt? Ich halte es für sinnvoll wenn man nach dem generieren der Rechnung bestimmte Dinge einfach nicht mehr ändern kann. Das habe ich dann so umgesetzt:
Bis die Rechnung erstellt ist kann alles geändert werden, dann wird aber auch neuberechnet. Nach der Erstellung der Rechnung können bestimmte Dinge nicht mehr verändert werden, und bei den Dingen die geändert werden können findet keine Neuberechnung statt.
Das Modul für 4.7. gibt es hier: https://github.com/leofonic/No_Recalc
Passend dazu gibt es hier https://github.com/OXID-eSales/oxideshop_ce/blob/b-dev-ce/source/modules/invoicepdf/myorder.php eine modifizierte myorder.php, die das Rechnungsdatum auf den Tag der ersten Erstellung fixiert und das Zahlungsziel auf 7 Tage danach.
sofort ausprobier…
Guten Morgen,
zunächst mal vielen Dank fürs Teilen dieses sehr wichtigen Moduls!
Mir fällt auf, dass die Abhängigkeit von der Rechnung bzw. dem Rechnungsdatum nicht ideal ist.
Wenn zB. nach einer Änderungen der Artikelpreise eine Rechnung erstellt werden soll, muss oft eine eigene Rechnungsnr. eingetragen werden. Sobald diese eingetragen und gespeichert wird, wird neuberechnet mit den neuen Artikelpreisen.
Aber das lässt sich ja ändern, man muss nur einen anderen “Auslöser” finden für das Aktiv-werden von norecalc.
Ich habe es mal mit des Ordner der Bestellung ausprobiert, da dieser unter Bestellung-Übersicht geändert werden kann, was ja dann noch keine Neuberechnung auslöst.
Befindet sich die Bestellung im Ordner “Neu”, kann noch neuberechnet werden. In jeden anderen Ordner wird nicht mehr neuberechnet. Das funktioniert bei mir scheinbar gut.
Ich sende zwar auch einen pull request, aber falls du lieber die ursprüngliche Version beibehalten willst, ist die von mir geänderte Version auch hier zu finden: https://github.com/ecomstyle/No_Recalc
Hi nickname, danke für den Input und den Pull Request. Mein erster Pull Request! 
So langsam finde ich Gefallen an Github.
Wenn zB. nach einer Änderungen der Artikelpreise eine Rechnung erstellt werden soll, muss oft eine eigene Rechnungsnr. eingetragen werden. Sobald diese eingetragen und gespeichert wird, wird neuberechnet mit den neuen Artikelpreisen.
Also wenn ich dich richtig verstanden habe, willst du eine neue Rechnung erstellen mit neuem Datum, neuer Rechnungsnummer und aktuellen Artikelpreisen? Die Anbindung an den Ordner finde ich etwas problematisch, das ist dann so eine Art “magic switch”, und man muss immer aufpassen in welchem Ordner man sich befindet. Die Logik wäre in dem Fall: Preise und Kosten immer vom Rechnungsdatum. Ich habe das mal so gelöst dass ich einen “Rechnung zurücksetzen”-Button eingebaut habe mit dem sich das Rechnungsdatum und die Nummer zurücksetzen lässt. Wenn dann Änderungen in “Stamm” oder “Artikel” vorgenommen werden, wird die Rechnung neu berechnet. Die neue Rechnungsnummer muss nicht eingetragen werden, weil beim Generieren eine neue erstellt wird.
Hi leofonic,
wenn man zB. noch weitere Onlineshops oder Verkaufskanäle hat, muss man evtl. eine eigene Rechnungsnr. eintragen.
Hier passiert dann halt der Fehler, wenn man vorher die Artikelpreise aktualisiert hat oder Rabattaktionen sich geändert haben.
Sobald man eine eigene Rechnungsnr. einträgt und auf Speichern klickt, wird neu kalkuliert. Ein Rechnungsdatum ist noch nicht vorhanden, also greift dein Modul nicht und man hat keine Möglichkeit, dies zu ändern.
Die Abhängigkeit von den Orderfolders bietet die Möglichkeit, selbst zu entscheiden, ob eine Bestellung neu kalkuliert werden muss, oder nicht.
Eine nagelneue Bestellung ist automatisch im Ordner “Neu” und kann noch bearbeitet und neukalkuliert werden, wenn zB. dem Kunden noch etwas einfällt und er nachträglich etwas dazu bestellen möchte.
Sobald man die Bestellung bearbeitet, legt man sie in einen beliebigen anderen Ordner, zB “in Arbeit” oder “bearbeitet”, trägt ggf. eine eigene Rechnungsnr. ein, das Modul verhindert eine Neu-Kalkulation und die Bestellung bleibt unverändert.
[QUOTE=nickname;127816]
Sobald man eine eigene Rechnungsnr. einträgt und auf Speichern klickt, wird neu kalkuliert. Ein Rechnungsdatum ist noch nicht vorhanden, also greift dein Modul nicht und man hat keine Möglichkeit, dies zu ändern.
[/QUOTE]
Dann habe ich dich falsch verstanden. Es geht also darum in weniger Fällen neu zu berechnen und nicht mehr.
[QUOTE=nickname;127816]
Die Abhängigkeit von den Orderfolders bietet die Möglichkeit, selbst zu entscheiden, ob eine Bestellung neu kalkuliert werden muss, oder nicht.
[/QUOTE]
Ja die Idee ist gut, allerdings sollte das imho der Nutzer nicht nur selbst entscheiden können, die Neuberechnung sollte meiner Ansicht nach auch automatisch verhindert werden. Nimm den Fall: Rechnung wird gedruckt, Zahlung kommt rein, gleich das Bezahldatum aktualisieren, Mist, vergessen den Ordner zu ändern, falsche Preise. Ich hab deshalb deinen Pull-Request noch ein bisschen erweitert, Neuberechnung wird jetzt verhindert:
- wenn die Bestellung nicht im Ordner “neu” liegt.
- wenn ein Rechnungsdatum oder eine Rechnungsnummer existiert
- wenn eine Rechnungsnummer eingegeben wird
Das Zuteilen einer Rechnungsnummer ist damit gleichbedeutend mit dem Erstellen einer Rechnung. Außerdem kann davon unabhängig eine Bestellung für die Bearbeitung gesperrt werden indem sie in einen Ordner verschoben wird.
Guten Morgen,
super, jetzt funktioniert das schon fast perfekt.
Eine weitere mögliche Situation:
Eine neue Bestellung liegt völlig unangetastet ein paar Tage im Ordner Neu, bis endlich die Vorauskasse-Überweisung eingeht. Als erstes setzt man dann natürlich das Bezahldatum, und falls sich zwischenzeitlich die Preise oder Rabatte geändert haben, hat man auf einmal die neuen Artikelpreise in der Bestellung, da rekalkuliert wird.
Ich habe deshalb im Modul die Neu-Kalkulation verhindert, wenn ein Bezahldatum eingetragen wird. Der zweite Pull Request ist unterwegs 
Danke für das Modul! Könnte noch eine Lizenz angegeben werden?
von mir auch ein großes Danke für das Modul, funktioniert perfekt !
Hallo liebe Oxidgemeinde,
wir haben nun das ursprüngliche “Backend Order” Modul für OXID ab Version 4.7 programmiert und dieses im Exchange-Bereich kostenlos zur Verfügung gestellt.
Der offizielle deutschsprachige Forumeintrag für Bugs und Anregungen befindet sich hier:
Viel Spaß mit dem Modul!
super - Danke!
Hallo,
ich verstehe nicht ganz. Ihr habt ein Modul genommen, dass gemeinsam hier und auf GitHub erarbeitet wurde, macht noch ein paar Änderungen, schreibt Euren Namen in die metadata und bietet das im eXchange zum Download an?
Gruß
Hallo Marco,
nein das haben wir nicht. Ich “jasonkx” bin der Urheber des Moduls, das unter
zu finden ist.
Ich wollte es eigentlich von Anfang an auch für 4.7 schreiben und dann im Exchange veröffentlichen, aber hatte dann keine Zeit mehr dafür.
Da ich mir dachte, daß andere es auch gerne benutzen würden, habe ich es vorab ins Github getan.
Nun brauchten wir es aber dringend für unsere eigene Shops und deshalb haben wir es für OXID ab Version 4.7 umprogrammiert, was zugegeben nicht ganz ohne war.
Gruß Jason
Ah okay 
Ist dann halt nur noch die Frage, ob es ganz grossen Sinn macht, die verschiedenen Entwicklungen zusammen zu führen.
Gruß
Wieso, welche verschiedenen Entwicklungen?
Du meinst für Version 4.6 und 4.7?
ich muß ja nun auch nicht ALLES verstehen, aber: danke fürs teilen. schon drauf gewartet
trotzdem: kann ich das neue drüberbügeln (4.7.3) oder was ist ist angeraten: ?
Also zum Verständnis:
Das in OXID Exchange angebotene Modul ist kompatibel mit Version 4.6, 4.7 und 4.8.
Es ersetzt das “Backend Order Modul” aus dem Github, da dieses nur mit Version 4.6 kompatibel war und ist aus technischer Sicht ein neues, eigenständiges Modul.
Es hat auch nichts mit dem für die Version 4.7 angepassten Modul von “leafonic”, welches unter
https://github.com/leofonic/No_Recalc
zu finden ist, zu tun.
Für Version 4.7 haben wir das Modul komplett eigenständig umprogrammiert.
Gruß Jason
@ frank: nö. ich hab dein modul auch drin, aber net aktiv. frag bloß net warum??? 
aktiviert!