Während des diesjährigen Magento Developer Paradise auf Ibiza wurde an einem Abend ein Hackathon veranstaltet, bei dem Teams innerhalb von 4 Stunden kleine Magento Projekte umsetzen konnten.

Zusammen mit Karsten haben wir als Team 2Boys1Shop die Extension Twoboysoneshop_Configr realisiert. Dabei handelt es sich um eine Übersicht über die Konfigurationen aller Stores einer Installation, um diese dann einfach miteinander vergleichen zu können.

Gerade bei Installationen mit 5 oder mehr Websites/StoreViews ist es nahezu unmöglich den Überblick zu behalten, wie welcher Shop konfiguriert ist, vor allem wenn für diese unterschiedliche Sprachen, Währungen, Ländern, Zahlungsarten etc eingestellt sind. Zudem hat der Kunde oftmals die Möglichkeit direkt auf dem Produktionssystem die Konfiguration zu verändern und bei der Fehleranalyse ist es dann hilfreich sofort die getätigten Änderungen identifizieren zu können.

Die Extension bietet bislang folgende Features:

Übersicht:
- alle Werte aller Stores anzeigen
- Stores auswählen, die man miteinander vergleichen möchte
- farbliche Hervorhebung der überschriebenen Werte (konfigurierbar)
- Suche nach Config Keys
- Tooltips für die Werte aller Scopes
- Optionale Berechtigungsprüfung, um nur erlaubte Configbereiche anzuzeigen

Verlauf:
- Konfigurationsänderungen aufzeichnen
- Alle Änderungen in einer Übersicht anzeigen (wer hat wann welchen Werte worauf geändert)

Das Feedback nach der Vorstellung unseres Projektes auf der Konferenz hat gezeigt, dass viele Agenturen Interesse an solch einer Extension haben, was uns ermutigt diese weiter auszubauen.

Link zur Extension auf Github: Twoboysoneshop_Configr

Wir hatten kürzlich das Problem, dass wir einen Magento Shop so konfigurieren sollten, dass sich der Steueranteil abhängig vom Steuersatz des Lieferlandes ändern soll.

Wenn man die Produktpreise als Netto im Admin pflegt ist dies kein Problem (wie z.B. in den USA), aber wenn man Wert auf ordentliche Preiswerte legt, sollte man diese in Brutto anlegen. Im Warenkorb sollen ebenfalls ausschließlich Bruttopreise angezeigt werden, wie dies in Deutschland üblich ist.

Problem

Wenn man nun für die diversen Zielländer eigene Steuersätze definiert macht Magento folgendes:
1. Vom Bruttopreis des Produktes den Steuersatz des als Steuer-Ursprung des Shops definierten Landes (hier Deutschland, also 19%) abziehen um den Nettopreis zu erhalten
2. Den Steuersatz des Ziellandes aufrechnen (z.B. 21% für Belgien)

Daraus ergibt sich beispielsweise für einen vorherigen Bruttopreis von 24€ nach der Umrechnung ein Bruttopreis von 24,40€ für Belgien.
Dies ist natürlich völlig korrekt, wenn man den gleichen Nettopreis beibehalten möchte, so dass für alle Lieferländer der Umsatz nach Steuerabzug gleich bleibt.

In unserem Fall aber sollte der Bruttopreis immer gleich bleiben und nur der enthaltene Steueranteil sollte dem Lieferland angepasst werden, ungeachtet der Tatsache, dass sich dadurch der Nettopreis und damit auch der Umsatz ändern kann.

Lösung

Um dies zu erreichen muss Magento dazu gezwungen werden (im o.g. Schritt 1.) statt dem Prozentsatz des Steuer-Ursprungs den Prozentsatz des Ziellandes für die Nettoberechnung zu verwenden, damit beim anschließenden Aufrechnen des neuen Steuersatzes wieder der ursprüngliche Bruttobetrag herauskommt.

Um dies zu erreichen kann man die Methode Mage_Tax_Model_Calculation::getStoreRate() wiefolgt überschreiben:



Zunächst wird standardmäßig der Steuersatz des Steuer-Ursprungs ermittelt.

Wenn nun
1. für den Store die Steuerberechnung anhand des Versandlandes konfiguriert ist
2. eine Versandadresse und damit ein Zielland vorhanden ist
3. die Preise für den Store in Brutto gepflegt werden
4. der vorher ermittelte Steuersatz nicht 0% ist
wird der Steuersatz des Ziellandes ermittelt um diesen für die Berechnung des Nettopreises zu verwenden.

Die 4. Bedingung hat den Grund, dass bei Ländern oder Bedingungen, wo keine Umsatzsteuer ausgewiesen wird (z.B. bei der Schweiz oder B2B Bestellungen) weiterhin der Steuersatz des Steuer-Ursprungs für die Nettoberechnung verwendet werden soll.

Wie handhabt ihr solche Besonderheiten bei der Steuerberechnung?

Einer der großen Schwachpunkte von Magento ist, dass es trotz damaliger Ankündigung offensichtlich nicht Unit-getestet ist.
Wer bereits das Vergnügen hatte sich etwas länger mit dem Code von Magento zu befassen wird feststellen, dass es äußerst unwahrscheinlich ist, dass Varien (bzw. Magento Inc.) wenigstens intern über eine Testsuite verfügt. Die Masse an Bugs und die Softwarearchitektur lassen zumindest nicht darauf schließen.

Nun möchte man aber durchaus selbstgeschriebene Module durch UnitTests abdecken, die exzessive Verwendung von Singletons macht dies allerdings weitestgehend unmöglich.

Da die Businesslogik der Applikation meist ordentlich in Models oder Helper gekapselt ist, möchte man diese z.B. durch vorkonfigurierte Objekte oder MockObjects ersetzen um diverse Szenarien abzubilden und automatisiert zu testen.

Hierfür habe ich kürzlich das Nutwerk_MageTestable Modul auf github veröffentlicht, welches schlichtweg gepatchte Mage.php Klassen für verschiedene Magento Versionen bereitstellt, mit denen UnitTests zumindest ermöglicht werden. Die Mage-Klasse wird dabei um folgende Methoden erweitert:

- Mage::setStoreConfig($path, $value, $store = null)
- Mage::setModel($modelClass, $model)
- Mage::setResourceModel($modelClass, $model)
- Mage::setResourceSingleton($modelClass, $model)
- Mage::setHelper($name, $helper)

Diese Methoden tun nichts weiter, als Objekte unter dem angegebenen Namespace in einer Registry zu hinterlegen, um sie dann bei der Verwendung der entsprechenden Getter Methoden bevorzugt zurückzugeben und dadurch Magentos eigenen Classloader zu umgehen.

Um die Rundungsfehler zu beheben, die vor allem dann auftreten, wenn man einen Shop mit Bruttopreisen konfiguriert und im Warenkorb oder zusätzlich einen Gutschein einlöst, muss man einfach nur die Rundungsgenauigkeit erhöhen.

Da alle Datenbankfelder, die Preise speichern, ohnehin als Decimal(12,4) angelegt sind, kann man dies auch nutzen und die standardmäßig eingestellte Rundungsgenauigkeit von "2" auf "4" erhöhen. Bei nur zwei Nachkommastellen kommen recht schnell Rundungsfehler zustande wenn mit mehreren gerundeten Werte gerechnet wird, wie man sich leicht vorstellen kann.

Lösung:
In der Klasse Mage_Core_Model_Store den zweiten Parameter verändern:

public function roundPrice($price)
{
//return round($price, 2);
return round($price, 4);
}


Im Frontend werden ohnehin alle Preisangaben durch den formatPrice() Filter auf zwei Nachkommastellen gerundet, so dass der Kunde nichts davon mitbekommt. Das einzige, was eventuell problematisch sein kann ist, dass Preise, die direkt aus der Datenbank oder über das Model exportiert und an Schnittstellen übergeben werden Fehler verursachen, wenn nun plötzlich vier Stellen nach dem Komma ausgegeben werden.
Allerdings sind mir bis jetzt keine Fehler diesbezüglich in den gängigen Extensions oder Zahlungsschnittstellen begegnet.

Dies ist lediglich eine Notiz an mich, falls es mal wieder partout nicht funktioniert sich in der lokalen Entwicklungsumgebung im Adminbereich einzuloggen.

Das Problem tritt meistens auf, wenn man Magento in einem Unterverzeichnis des Document Roots betreibt. Auf Grund der Cookie Domain ist es dann unter Umständen nicht möglich sich einzuloggen. Man erkennt es daran, dass man keine Fehlermeldung erhält und einfach wieder auf das Loginformular zurückgeleitet wird.

Variante1:
In der Methode Mage_Core_Model_Session_Abstract_Varien::start() ein paar Cookie Parameter leeren

// session cookie params
$cookieParams = array(
'lifetime' => $cookie->getLifetime(),
'path' => $cookie->getPath(),
'domain' => '', //$cookie->getConfigDomain(),
'secure' => '', //$cookie->isSecure(),
'httponly' => '', //$cookie->getHttponly()
);


Variante2:
In der Datenbanktabelle core_config_data die entsprechenden Werte setzen

path: web/cookie/cookie_domain | value: -leer-
path: web/cookie/cookie_httponly | value: -leer-