... public function roundPrice($price) { //4 Stellige Preise return round($price, 4); //return round($price, 2); } ... public function formatPrice($price, $includeContainer = true) { if ($this->getCurrentCurrency()) { return $this->getCurrentCurrency()->format(round($price,2), array(), $includeContainer); } return round($price,2); } ...
Ich habe aber jetzt das Problem, das bei der Preispflege im Backend die Ausgabe trotzdem nur 2 stellig ist. D.h. ich kann einen 4stelligen Preis angeben, der wird auch so in der DB gespeichert. Wenn ich das Produkt aber wieder aufrufe und z.B. die Beschreibung ändere, wird der 2 stellige Preis im Formular angezeigt. Wird jetzt gespeichert, so wird mein 4stelliger Wert wieder überschrieben.
[...]
Hi Christian,
das wird dich interessieren:
Damit im Backend in der Produktansicht die Preise mit vier Nachkommastellen angezeigt werden und somit beim Speichern das Produkts der Wert in der Datenbank nicht mit dem gerundeten Wert überschrieben wird, muss zusätzlich folgende Änderung im Code von app/code/core/Mage/Adminhtml/Block/Catalog/Product/Helper/Form/Price.php Zeile 82 gemacht werden:
public function getEscapedValue($index=null) { $value = $this->getValue();
Will man, dass im Backend unter “Produkte Verwalten” in der Listen Ansicht auch gleich die vierstelligen Preise angezeigt werden muss folgender Code in code/core/Mage/Adminhtml/Block/Widget/Grid/Column/Renderer/Price.php Zeile 59 geändert werden
da ich mich auch mehrere Monate immer mal wieder mit dem Thema Mehrwertsteuerberechnung im Magento-Shop auseinander gesetzt habe, möchte ich Euch kurz noch meine Erfahrungen mitteilen.
Ich entwickele meine Module bzw. das Layout für den Shop unter Windows mit einer WAMP-Installation von ApacheFriends.
Bei der Version, welche ich bis vor kurzem installiert hatte, rundete die Methode round falsch. Eine 5 als Nachkommastelle wurde nicht aufgerundet. Dies führte dazu das sich die Gesamtsummen falsch berechneten. Probiert einfach mal aus wie sich die Methode bei Euch verhält. Nach einem Update auf eine neuer Version von PHP war das Problem beseitigt. Weiter ist mir aufgefallen das Zend Currency nur die Stellen kürzt ohne jedoch aufzurunden. Es ist also erforderlich, bevor die Zahl als Währung in der entsprechenden Locale formatiert wird, zu runden.
Ich glaube das in dem von mir betreuten Shop nun alle Fehler in der Berechnung beseitigt sind. Allerdings bin ich mir noch nicht ganz sicher das ich auch alle Eventualitäten bedacht habe. Wer möchte kann gerne einmal versuchen. Die Adresse ist http://www.caweber-style.de.
Sollte jemand Interesse an den Änderungen haben, kann ich den Code gerne zur Verfügung stellen.
Gibt es eigentlich eine Möglichkeit Module ohne Magento Connect zu installieren? Hat sich das schon mal jemand angesehen?
Das wäre echt Klasse, wenn du den Code halbwegs verständlich kommentiert zur Verfügung stellen könntest.
Was Module angeht: So brauchst du vom Prinzip her nur das Modulverzeichnis unter app/code/local platzieren und unter app/etc/modules eine oder mehrere .xml Dateien die das Modul im System anmelden und das Modul wird wo auch immer sofern aktiviert funktionieren - oder meinst du etwas anderes?
Meines Wissens kann man direkt über den Connect-Manager nur Erweiterungen laden/installieren die auf Magento Connect veröffentlicht wurden weil ja diese Channels als Bezugsquelle dienen (diese sind entweder Core oder Community) - obwohl ja Kommerzielle Extensions nach dem Motto “Visit Page” ja auch irgendwie bereitgestellt werden müssen denke ich. Grübel, Grübel…
Ansonsten kenne ich noch im Backend von Magento auch über System->Magento Connect den Button “Paketerweiterungen” - mit dem habe ich aber noch nicht gearbeitet, da gibt es eine Möglichkeit “lokale Pakete laden”, jedoch kann ich nicht sagen ob man hier wirklich ein Lokales Paket (etwa ein tar.gz Paket vom Desktop) laden kann oder ob damit einer der 3 Codepools “core, community & local” gemeint ist.
So ich habe meine gesammelten Werke mal in ein Paket gesteckt und als community Extension zur Verfügung gestellt.
Ich muss allerdings darauf hinweisen, dass ich keine Garantie auf Richtigkeit der Berechnungen übernehmen kann. Also bitte nur mit Vorsicht in einer Live-Umgebung installieren.
2. Ansonsten kann an den bekannten Stellen in den Templates (app/design/frontend/default/XXXX/template/sales/order/**/items.phtml) die MwSt. hinzuaddiert werden
Die einzelnen Stellen bekomme ich leider im Moment nicht mehr zusammen.
Hier als Beispiel die 2 Stellen in der app/design/frontend/default/XXXX/template/sales/order/items.phtml Datei:
nach meinem letzten gespräch mit den entwicklern gibts 3 mögliche wege, preise zu berechnen. je nach steuersystem ist eines davon korrekt. es wird in einer der nächsten versionen dazu denke ich eine neue funktion geben.
stichwort: Berechnung erfolgt Element-basierend, Reihen-basierend oder Summebasieren (glaub ich) - hab’s nicht mehr ganz auf’m schirm!
Das Problem ist: Es funktioniert ja richtig - nur bei uns nicht so GANZ Ich versuche mal, von Yoav eine Erklärung zu bekomme, die auch ein nicht-Programmierer versteht und werde diese dann mal in den Blog posten.
perfekt, dann lass Dir bitte 2 Varianten Erklärungen geben.
Die Entwickler interessiert bestimmt auch die technische Variante
In meinen Augen ist das größte Problem, dass nicht überall die Summen aus den gerundeten Werten ermittelt werden.
Das Problem ist allerdings recht schwer zu Erkennen, da ein Entwickler nicht zwingend alle Variationen ausprobiert.
Wenn ein Artikel brutto 10 EURO kostet und man 2 Stück kauft, sieht alles gut aus. Doch ab einer bestimmten Menge summieren sich die Nachkommastellen zu sehr auf, dass dann später die Gesamtsumme bzw. der Steueranteil nicht mehr passt.
Kriminell wird es dann noch wenn die Rabattregeln noch mit ins Spiel kommen.
zusammengefasst gesagt machen bis dato in Netto eingepflege Preise Probleme, wenn Preise im Backend in Brutto eingegeben werden ist alles palleti, oder?
die Extension ist immer noch im Status pending.
Was eigentlich erst einmal auch gut ist, da mit gerade aufgefallen ist, dass es noch nicht zu 100% stimmt.
Irgendwie treten in meinem Shop immer noch Rundungsfehler auf.
Da muss ich heute Abend wohl oder übel danach sehen.
Das nervt irgendwie ganz gewaltig. Tausend mal getestet und bei bestimmten Preisen stimmt die Rabattberechnung nicht mehr.
Gesamt: 85,20
---------------------
2. Bei Rabatten (in diesem Fall 8 Euro auf den Warenkorb) kommen dann auch in der Summe Rundungsfehler raus (2. Screenshot)
Hier wird ein seltsamer Betrag vom Bruttopreis des Produkts abgezogen:
angezeigter Bruttopreis Produkt ohne Gutschein: 42,60
angezeigter Bruttopreis Produkt MIT Gutschein: 41,96
Kunde kauft zwei Produkte, dann sieht der Warenkorb so aus:
Gibt es hierfür Abhilfe ? Es kann doch nicht angehen, dass ein Shopsystem nicht richtig rechnet… das schaffen ja sogar die Billigsysteme…
Unser Finanzamt wird dafür sicher kein Verständnis haben und die Kunden halten uns auch für bekloppt…
Ich versuche mal, von Yoav eine Erklärung zu bekomme, die auch ein nicht-Programmierer versteht und werde diese dann mal in den Blog posten.
