Unterstützung bis 26.09.2019

Da jede Minor-Version (das heißt 2.0.x, 2.1.x, 2.2.x, …) zwei Jahre lang nach Erscheinen unterstützt wird, können HändlerInnen die ihren Shop auf dieser Vesion laufen haben bis September 2019 mit Updates rechnen.

Viele Fehler-Behebungen in Magento 2.2

Magento hat die Zeit genutzt, um unter tatkräftiger Mithilfe der Community viele Fehler zu beheben. Insgesamt 428 Bugfixes zählte Ryan Hoerr in der Änderungsliste für die kommerzielle Version Magento Commerce. Davon steuerte die Community 71 Fixes bei.

Einbindung von externen Services

Wie ich bei meinem Besuch auf der Imagine-Konferenz berichtet habe kündigte Magento dieses Jahr Features an, die über externe Services realisiert werden.

Diese Dienste sind nun mit Magento 2.2 verfügbar bzw. werden es bald sein:

• Social (der Produkt-Katalog kann einfach auf Facebook veröffentlicht werden),
• Business Intelligence (auch als Advanced Reports bezeichnet),
• Shipping (in 2.2.2)

Details zu den Services finden Sie in meinem Blogpost bei LimeSoda.

Weiters kann mit Magento Commerce 2.2 der Betrugs-Erkennungs-Service Signifyd eingebunden werden.

B2B-Modul

Wahrscheinlich die wichtigste Verbesserung von Magento 2.2 neben der höheren Stabilität ist das B2B-Modul. Es steht Commerce-Kunden ohne zusätzliche Kosten zur Verfügung. Dabei handelt es sich um ein Modul, das Magento Inc. programmiert hat. Man bindet es direkt in den Code am eigenen Server ein.

Die Erweiterung reichert Magento mit typischen B2B-Features an:

• Beliebig verschachtelbare Hierarchien von Firmen- und User-Subaccounts mit Rechteverwaltung
• Firmenspezifische Preislisten und Produktkataloge
• Preisanfragen („Request for Mode“) mit Abwicklung der Korrespondenz direkt in Magento 2
• Schnellbestellungen
• Und vieles mehr

Erhöhte Sicherheit

Magento verbesserte die Code-Basis in einigen Bereichen, um die Sicherheit zu erhöhen und potentiellen Sicherheitslücken vorzubeugen. Aufrufe der PHP-Funktion unserialize() wurden entfernt. Die ProgrammiererInnen weiteten zudem den Schutz gegen Cross-Site-Scripting-Attacken (auch bekannt als XSS) aus.

Bessere Geschwindigkeit und Skalierbarkeit

Das Team arbeitet regelmäßig an Verbesserungen in der Performance.

In diesem Release tragen folgende Änderungen zu einer besseren Geschwindigkeit bzw. Skalierbarkeit bei:

• Indexing ohne Auswirkungen auf das Frontend
  Wenn Magento so genannte Indizes berechnet, führte das oft dazu dass Kunden die Seite langsamer präsentiert bekamen. Das soll nun nicht mehr der Fall sein.
• Unterstützung von saint & grace mode in Varnish
  Wer Varnish in seinem Shop im Einsatz hat, darf sich über eine höhere Hit-Ratio und die Unterstützung der Modi saint & grace freuen.
  Ersteres heißt, dass mehr Anfragen vom schnellen Varnish bedient werden und der Request seltener vom langsameren PHP/Magento-Teil bedient werden muss.
  Zweiteres bedeutet, dass Varnish den KundInnen weiterhin eine Seite anzeigen kann – selbst wenn der PHP/Magento-Part im Hintergrund gar nicht funktioniert. Zudem kann Varnish noch eine (vielleicht leicht veraltete) Seite anzeigen kann, falls PHP/Magento nicht schnell genug die aktuelle Seite liefert. Das tut man, weil es im Zweifelsfall besser ist dem Kunden eine alte Version zu zeigen als ihn ganz ziehen zu lassen. Im Hintergrund fordert Varnish trotzdem die neue Seite an und cacht sie. Beim nächsten Aufruf sieht ein Kunde dann die neue Seite.
• Größere Warenkörbe / Bestellungen
  Bestellungen mit 300 Bestellposten oder mehr konnten bisher in Magento 2 Probleme bereiten. Die Bestell-Abschlüsse von solch großen Orders wird nun schneller durchgeführt.

Aktualisierter Technologie-Stack

Magento 2.2 verwendet nun neuere Versionen der zugrunde liegenden Technologien:

• PHP 7.1 wird nun unterstützt. Der Support für PHP 5.6 wurde hingegen eingestellt. So kann man von den neuen Sprach-Features von PHP 7 profitieren.
• Varnish 5 ist jetzt kompatibel mit Magento. Dafür musste der Support für Varnish 3 gehen.
• MySQL 5.7 und (in der Commerce-Version) Redis 3.2 sind neu in der Palette der unterstützten Versionen.
• Die in Commerce eingebaute Suche stellt den Support für Solr ein. Der Code befindet sich momentan noch im Produkt. Man soll aber nur noch ElasticSearch verwenden.
• Composer und die Packages von Zend Framework 2 und 1 wurden aktualisiert. Community-Beiträge reduzierten auch die Verwendung von Zend Framework 1. Mit der Zeit soll es komplett aus dem Core verschwinden.

Pipeline Deployment

Mit Magento 2 ist es komplizierter als in Magento 1, Code auf Kunden-Server auszuliefern ohne dass die Seite dabei längere Zeit im Wartungsmodus ist. Damit Integratoren es wieder leichter haben, implementierte Magento mit dem Pipeline-Deployment einen neuen Deployment-Prozess.

Ziel ist, denjenigen die einen Shop programmieren eine gute Standard-Prozedur an die Hand zu geben. EntwicklerInnen müssen nicht mehr ihr eigenes Süppchen kochen. Somit kann man auf diese Basis zurück greifen und mit geringer Downtime Änderungen am Webshop online zu bringen.

Das Posting Was ist neu in Magento 2.2? erschien zuerst in Matthias Zeis.

• Die Umsatzsteuer-Identifikationsnummer (UID bzw. UST-IdNr.) kann automatisch überprüft werden.
• Je nach Ausgang der UID-Prüfung kann eine automatische Kundengruppenzuordnung des Kunden erfolgen.

Für die Validierung kommt die offizielle Schnittstelle der Europäischen Union (VIES VAT number validation) zum Einsatz.

Hinweis: Dieser Artikel entstand während der Entwicklung von Magento 1.7 (Version alpha1). Es ist daher möglich, dass sich in der stabilen Version Änderungen ergeben.

Konfiguration

Um die automatische Überprüfung zu aktivieren, meldet man sich im Magento-Backend an und navigiert zum Menüpunkt System > Configuration > Customer > Customer Configuration > Create New Account Options (siehe Screenshot).

Wenn man die unscheinbare Option „Enable Automatic Assignment to Customer Group“ auf „Yes“ setzt, erscheinen die Konfigurationsmöglichkeiten:

Wir können nun die Optionen Schritt für Schritt durchgehen:

• Enable Automatic Assignment to Customer Group
  Aktiviert die automatische Überprüfung der Umsatzsteuer-Identifikationsnummer und die automatische Zuordnung zu Kundengruppen.
• Default Group
  Die Kundengruppe, der neue Kunden standardmäßig zugeordnet werden.
• Group for Valid VAT ID – Domestic
  Die Kundengruppe, der inländische Kunden mit gültiger UID zugeordnet werden.
• Group for Valid VAT ID – Intra-Union
  Die Kundengruppe, der Kunden innerhalb der EU mit gültiger UID zugeordnet werden.
• Group for Invalid VAT ID
  Die Kundengruppe, der Kunden ohne gültige UID zugeordnet werden.
• Validation Error Group
  Die Kundengruppe, der Kunden zugeordnet werden, wenn keine Validierung vorgenommen werden konnte (z.B. weil das Validierungsservice nicht erreichbar ist.)
• Validate on Each Transaction
  Legt fest, ob die Gültigkeit der UID bei jeder Bestellung überprüft werden soll.
  
• Disable Automatic Group Changes Based on VAT ID Default Value
  Soll die Option „Disable automatic group change“  bei der Anlage neuer Kunden im Backend standardmäßig angehakt sein? (Siehe weiter unten für eine Erklärung dieser Funktion.)
  

Funktionsweise & Details

Sehen wir uns an, wie das neue Feature funktioniert und welche Details mir beim Testen aufgefallen sind.

Wie sieht eine Beispielkonfiguration aus?

Ich habe für meine Tests folgende Kundengruppen unter „Customers > Customer Groups“ erstellt:

• B2C
  Die normalen Endkunden.
• Händler Österreich verifiziert
  Kunden aus Österreich, die eine gültige UID angegeben haben (B2B).
• Händler EU verifiziert
  Kunden aus der EU, die eine gültige UID angegeben haben (B2B).
• Händler UID ungültig
  Kunden, die eine ungültige UID angegeben haben.
• Händler UID nicht verifiziert
  Kunden, bei denen die UID nicht überprüft werden konnte (z.B. weil die Überprüfungsstelle nicht erreichbar war).
• NOT LOGGED IN
  Gruppe für nicht registrierte Kunden (eine Standardgruppe in Magento).

Die Konfiguration für die Kundengruppenzuordnung sieht dann folgendermaßen aus:

Wo werden die Ländereinstellungen für den Shopbetreiber und den Kunden vorgenommen?

Der Shopbetreiber stellt das Land, in dem sich der Shop befindet, im Backend unter dem Menüpunkt „System > Configuration > Configuration > General > General > Store Information > Country“ ein. In unserem Fall wird hier „Österreich“ ausgewählt.

Achtung: wenn die automatische Zuordnung der Kundengruppen bereits aktiviert war, muss nach einer Änderung des Landes die Option erneut aktiviert werden. Bei mir wurde sie nach der Umstellung des Shop-Landes deaktiviert.

Für den jeweiligen Kunden gilt das in der Standard-Rechnungsadresse angegebene Land.

Wo muss die UID eingegeben werden?

Für die Überprüfung wird einzig die UID der Standard-Rechnungsadresse verwendet.

Es wird zwar bereits beim ersten Registrierungsschritt ein UID-Feld eingeblendet, wenn man das im Magento-Backend so einstellt. Diese Eingabe wird aber ignoriert – unabhängig davon, ob das Feld als optionale oder als Pflichtangabe definiert wird.

Nach der Registrierung wird der Hinweis angezeigt, dass für die korrekte Preisdarstellung eine UID bei der Rechnungsadresse hinterlegt werden muss.

Wenn man die neue Adresse anlegt, erscheint im Formular ein UID-Feld. Diese Eingabe wird für die Überprüfung verwendet und auch nur dann, wenn es sich um die Standard-Rechnungsadresse handelt (z.B. bei der Anlage der ersten Adresse überhaupt oder wenn man später beim Bearbeiten / Erstellen von Adressen das entsprechende Häkchen setzt).

Welche unterschiedlichen Fälle gibt es und wie werden die Kunden informiert?

Wird eine UID angegeben, dann kann zwischen 4 Fällen unterschieden werden. Das Beispiel verwendet die oben angegebenen Beispiel-Kundengruppen:

1. Inländischer B2B-Kunde (Österreich)
   Ein österreichischer Händler gibt eine korrekte UID an.
   
   Die UID ist gültig, Steuern werden verrechnet. Der Kunde wird in die Gruppe „Händler Österreich verifiziert“ verschoben.
2. Ausländischer B2B-Kunde (EU)
   Ein ausländischer Händler innerhalb der EU gibt eine korrekte UID an.
   Die UID ist gültig, Steuern werden nicht verrechnet. Der Kunde wird in die Gruppe „Händler EU verifiziert“ verschoben.
3. UID-Validierungs-Service nicht erreichbar
   Die Überprüfung der UID kann nicht durchgeführt werden.
   Die UID konnte nicht verifiziert werden, Steuern werden verrechnet. Der Kunde wird in die Gruppe „Händler UID nicht verifiziert“ verschoben. Eine eigene Kundengruppe für diesen Fall macht Sinn, damit man leicht sieht, um welche Kunden man sich getrennt kümmern muss (z.B. um in Kontakt zu treten, die Überprüfung manuell vorzunehmen, …).
4. UID ist ungültig
   Es wurde eine falsche UID angegeben.
   
   Die UID ist ungültig, Steuern werden verrechnet. Der Kunde wird in die Gruppe „Händler UID ungültig“ verschoben.

Können einzelne Kunden von der automatischen Überprüfung ausgenommen werden?

Ja. Der Kunde wird im Backend über dem Menüpunkt „Customers > Manage Customers“ bearbeitet. Im Abschnitt „Account Information“ kann bei der Kundengruppenauswahl das Häkchen „Disable automatic group change“ gesetzt werden.

Kann die UID des Kunden direkt über das Backend manuell überprüft werden?

Soweit ich gesehen habe: im Moment nicht. Allerdings gibt es eine Überprüfungsmöglichkeit für die eigene UID unter „System > Configuration > General > General > Store Information“, die zweckentfremdet werden könnte.

Kann für das eigene Unternehmen eine UID angegeben werden?

Ja, es kann für den Shop eine UID unter „System > Configuration > General > General > Store Information“ definiert werden. Dort ist auch eine Überprüfung der UID möglich.

Achtung: wenn der Validierungsservice nicht erreichbar ist, wird die Meldung „VAT Number is invalid“ angzeigt. Falls man sicher ist, dass die Nummer richtig eingegeben wurde, könnte die Meldung also auch dadurch zustande kommen.

Fazit

Das neue Feature kann Shop-Betreibern mit vielen B2B-Kunden einiges an Arbeit abnehmen. Ein paar kleine Funktionen (manuelle Überprüfung der UID direkt beim Kundenmanagement möglich, leichtere Editierbarkeit der Erfolgs-/Fehlermeldungen, …) wären wünschenswert, doch vielleicht kommen diese Features noch dazu.

Das Posting Automatische Überprüfung der UID und Kundengruppenzuordnung in Magento 1.7 erschien zuerst in Matthias Zeis.