Bestellstatus in Magento setzen/verändern

Eine Bestellung kann in der Standardinstallation von Magento die folgenden Statuswerte haben:

  • Canceled (abgebrochen, d.h. storniert oder Zahlung vom Kunden abgebrochen),
  • Closed (geschlossen, d.h. berechnet und gut geschrieben),
  • Complete (berechnet und versendet),
  • Suspected Fraud (Betrugsverdacht),
  • On Hold (zurückgestellt),
  • Payment Review (Zahlung wird überprüft),
  • Pending (wartend, d.h. Nachnhahme oder Vorkasse),
  • Pending Payment (warte auf Zahlung, Zahlung nicht abgeschlossen, wenn der Status länger besteht),
  • Pending PayPal (noch nie gesehen),
  • Processing (Verarbeitung, d.h. Ware bezahlt und/oder Rechnung erstellt).

In der Bestellübersicht erscheinen diese auch mit der deutschsprachigen Administrationsoberfläche in Englisch:
Status von Bestellungen in Magento

Einsteiger vermissen oft die Möglichkeit, den Status direkt zu verändern, z. B. selbst auf „Bezahlt“ oder „Versendet“ zu setzten. In Magento ist der Bestellstatus an den Zustand der Bestellung gebunden und deshalb nicht direkt veränderbar, sondern wird automatisch gesetzt. Dies ist abhängig davon, was mit der Bestellung geschehen ist.

In System > Bestellstatus & Zustand können eigene Statuscodes definiert und Zuständen zugewiesen werden. In diesem Artikel erläutere ich die Statuswerte, die eine Bestellung standardmäßig in Magento haben kann.

Pending

Diesen Status erhält eine neue Bestellung. Bei Offline-Zahlungsmethoden wie Vorkasse oder Nachnahme behält die Bestellung diesen Status bis zur manuellen Bearbeitung. Bei Online-Zahlungsmethoden wechselt der Bestellstatus meistens automatisch auf einen anderen Wert.

Der Status Pending ist deshalb problematisch, weil Nachnahmesendungen von Sendungen gegen Vorkasse in der Bestellübersicht nicht unterschieden werden können. Nachnahmesendungen sind sofort zu versenden, während bei der Vorkasse erst nach Zahlungseingang versendet wird.

Mögliche Vorgehensweise hierbei ist die Zurückstellung der Bestellungen, die der Kunde per Vorkasse bezahlen möchte. Zurückgestellte Bestellungen bekommen den Status On Hold und können danach gefiltert werden. Mit dieser Erweiterung ist es in Magento möglich, die Zahlungsmethode in einer zusätzlichen Spalte anzeigen zu lassen und danach zu filtern.

On Hold

Durch den Klick auf die Schaltfläche „Zurückstellen“ in der Detailansicht einer Bestellung bekommt sie den Status On Hold. Der Kunde wird dabei nicht über die Änderung des Status seiner Bestellung benachrichtigt, sieht aber im Kundenbereich, dass seine Bestellung den Status „zurückgestellt“ hat.

Dieser Status kann für Bestellungen verwendet werden, bei welchen der Kunde die Vorkasse als Zahlungsmethode gewählt hat. Die Bestellung wird zurückgestellt und bekommt den Status On Hold. So können Bestellungen, bei welchen auf Zahlungseingang gewartet wird, leicht gefiltert werden.

Nach Zahlungseingang wird die Bestellung wiederaufgenommen und bekommt den Status, den sie vorher hatte (wurde vorher die Rechnung erstellt, wechselt der Status zurück auf Processing, sonst bleibt er auf Pending).

Processing

Diesen Status erhält die Bestellung, nach dem eine Rechnung oder eine Sendung (ohne Rechnung) erstellt wurde. Auch bekommt eine Bestellung diesen Status, wenn (unabhängig davon, ob eine Rechnung oder Sendung erstellt wurde) Magento eine Zahlungsbestätigung von einem Online-Zahlungsanbieter erhalten hat.

Standardmäßig wird bei PayPal-Zahlungen automatisch eine Rechnung nach Erhalt der IPN erstellt. Bei Sofortüberweisung wird keine Rechnung erstellt, doch nach Erhalt der IPN wechselt der Bestellstatus ebenso auf Processing. Wenn eine Bestellung diesen Status automatisch erhalten hat, kann sie also versendet werden.

Tipp: Soll bei Sofortüberweisung die Rechnung automatisch nach Empfang der IPN generiert werden, ist die Einstellung Generiere Rechnung nach Zahlung in System > Konfiguration > Verkäufe > Zahlungsarten > sofortüberweisung.de auf Ja zu setzen.

Complete

Eine Bestellung bekommt den Status Complete (Vollständig), nach dem sie berechnet und versendet wurde, d. h. nach dem eine Rechnung und ein Lieferschein erstellt wurden.

Wird für eine vollständige Bestellung eine Gutschrift erstellt, bekommt sie den Status Closed unter der Voraussetzung, dass der gesamte berechnete Betrag gutgeschrieben wurde. Der Status einer teilweise erstatteten Bestellung bleibt auf Complete.

Hinweis: Einige Zahlungsmodule verändern den Zustand der Bestellung unabhängig von den in diesem Artikel beschriebenen Standardereignissen. So kann eine Bestellung den Status Complete sofort nach Empfang einer Zahlungsbestätigung erhalten, ohne dass eine Rechnung und/oder Sendung erstellt wurde.

Payment Review

Dieser Status zeigt typischerweise, dass der Kunde eine PayPal-Zahlung (oder eine andere Instant Payment Methode mit ähnlichem Verhalten) veranlasst hat, aber diese aus irgendeinem Grund (noch) nicht abgeschlossen wurde. Von PayPal bekommt der Shop-Betreiber in diesem Fall eine begleitende E-Mail, die weitere Informationen zu dieser Transaktion liefert.

Oft ist dieser Status ein Indiz dafür, dass der Kunde ein PayPal-Konto extra angelegt hat, um seinen Einkauf in Ihrem Shop zu bezahlen. Bei einem neuen PayPal-Konto kann eine sofortige Zahlung nicht durchgeführt werden, da der Kunde noch sein Bankkonto validieren muss, von dem der Kaufbetrag abgebucht wird. Für die Validierung muss der Kunde die zwei zufälligen Eurocent-Beträge eingeben, die auf das angegebene Bankkonto überwiesen werden. Da die Überweisung 2-3 Tage dauern kann, wird auch der Status der Bestellung für diese Zeit unverändert bleiben. Nach dem die Zahlung erfolgreich abgeschlossen wurde, sendet PayPal eine IPN an Ihren Shop, und der Status wechselt automatisch auf Processing (Verarbeitung).

Suspected Fraud

Den Status Suspected Fraud (Betrugsverdacht) bekommt eine Bestellung, wenn PayPal (nach eigenen Kriterien) ein Betrugsmuster erkennt. Dies ist beispielsweise dann der Fall, wenn die IPN unverändert aber stark verzögert empfangen wird.

Canceled

Wird die Bestellung im Backend storniert oder vom Kunden im Bezahlvorgang abgebrochen, bekommt sie den Status Canceled. Sollten sich Bestellungen mit diesem Status häufen, muss dringend das Angebot der Zahlungsmöglichkeiten überprüft und ggf. erweitert werden!

Eine Bestellung wird angelegt, nachdem der Kunde auf die Schaltfläche „Bestellung abschließen“ im Checkout klickt. Hat er eine Online-Zahlungsmethode (z. B. PayPal) gewählt, wird er zur Bezahlseite weitergeleitet. Bricht er die Bestellung ab, in dem er auf der Bezahlseite auf die Schaltfläche „Abbrechen“ klickt, wird die Bestellung automatisch storniert und bekommt den Status Canceled.

Der Kunde sollte nach Abbruch zurück zum Shop weitergeleitet werden. Nach dem die Bestellung angelegt wurde, wird der Inhalt des Warenkorbs gelöscht. Bei einigen Bezahlschnittstellen wird nach Abbruch der Bestellung auf der Bezahlseite der Warenkorb mit dem Inhalt der Bestellung gefüllt.

Pending Payment

Eine Bestellung wird angelegt, nachdem der Kunde auf die Schaltfläche „Bestellung abschließen“ im Checkout klickt. Hat er sich für eine Instant Payment Methode entschieden, erhält die Bestellung diesen Status, solange die Zahlung nicht erfolgreich abgeschlossen wurde. Nach dem Abschluss der Zahlung sendet der PSP (= Payment Service Provider) eine IPN (= Instant Payment Notification) an Magento. Der Status wechselt daraufhin automatisch auf Processing.

Sollte der Kunde auf der Bezahlseite die Browserschaltfläche „Zurück“ anklicken (z.B. mit dem Wunsch eine andere Bezahlmethode zu wählen), kommt er zum Shop zurück und bekommt die Meldung, dass sein Warenkorb leer sei. Das Gleiche passiert, wenn ein Kunde die Bezahlseite schließt (ohne die Bezahlung abzuschließen oder auf Abbrechen zu klicken) und den Shop im Browser erneut aufruft. Er wird seinen Einkauf mit dem leeren Warenkorb komplett neu starten.

Bleibt der Status Pending Payment länger stehen (d.h. einige Stunden oder Tage), ist das ein Indiz dafür, dass der Kunde mit dem Bezahlvorgang des Dienstleisters nicht klar gekommen ist.

Bei PayPal ist das typischerweise der Fall, wenn der Shop-Betreiber damit wirbt, dass über PayPal auch mit Kreditkarte und Lastschrift bezahlt werden kann. Der Kunde möchte per Kreditkarte oder Lastschrift bezahlen, besitzt aber kein PayPal-Konto und kennt/vertraut PayPal nicht. Kreditkarte und Lastschrift ist über PayPal grundsätzlich möglich, ist aber etwas umständlich, und oft wird der Kunde gezwungen gleich ein PayPal-Konto zu eröffnen. Später wird der Kunde gezwungen direkt mit PayPal zu bezahlen, da ein Bankkonto oder Kreditkarte, die bereits mit einem PayPal-Konto verbunden sind, nicht für eine direkte Zahlung über PayPal verwendet werden können (aus Sicherheitsgründen, wie PayPal angibt). Einige Kunden lassen sich es nicht gefallen und schließen verärgert die PayPal-Bezahlseite.

Bei Sofortüberweisung ist das typischerweise der Fall, wenn der Kunde diese Zahlungsmethode noch nicht verwendet hat und sich vom Namen her eine sofortige Überweisung verspricht. Einige Kunden brechen den Bezahlvorgang ab, sobald ihnen klar wird, dass sie dem Unternehmen hinter Sofortüberweisung einen Zugang zu Ihrem Konto ermöglichen, bei dem nicht nur der Kontostand, sondern sämtliche Kontobewegungen abgefragt werden können. Ferner können Sofortüberweisung nur die Kunden verwenden, die Online-Banking bereits nutzen.

Pending PayPal

Eine Bestellung, die mit PayPal bezahlt wurde, erhält den Status Processing bei erfolgreich abgeschlossener Zahlung, den Status Canceled bei abgebrochener Zahlung und den Status Pending Payment bei (noch) nicht abgeschlossener Zahlung. Der Status Payment Review bedeutet, dass der Kunde die PayPal-Zahlung abgeschlossen hat, PayPal sie aber noch nicht freigegeben hat (d.h. der Händler hat das Geld noch nicht erhalten).

In der Auswahlliste des Filters wird der Status Pending PayPal angeboten. Da dieser Status keinem Zustandscode zugewiesen ist, ist davon auszugehen, dass dieser Status nicht (mehr) genutzt wird (vermutlich ein Überbleibsel aus einer früheren Magento-Version).

Closed

Diesen Status erhält die Bestellung, wenn sie dem Kunden in Rechnung gestellt wurde (d.h. die Rechnung wurde erstellt) und dann gut geschrieben (d.h. eine Gutschrift wurde erstellt).

Dies ist z.B. der Fall, wenn der Kunde Gebrauch von seinem Widerrufsrecht macht und die Ware zurückgibt.

Eine Bestellung bekommt auch den Status Closed, wenn der Kunde seine Bestellung nachträglich ändern lassen möchte, nach dem er die Rechnung dafür erhalten hat. In Magento wird vom Kundenservice dazu die zu ändernde Bestellung storniert und eine neue angelegt. Wurde für die betroffene Bestellung bereits eine Rechnung erstellt, kann sie nicht mehr storniert werden, sondern muss durch die Erstellung einer Gutschrift geschlossen werden. Wurde noch keine Rechnung erstellt, kann die Bestellung einfach storniert werden. Sie bekommt dann den Status Canceled.

Bezahlung per Vorkasse/Überweisung

Die Vorkasse gehört in Deutschland zu einer gern gewählten Zahlungsmethode und sollte deshalb grundsätzlich angeboten werden. Die Einrichtung der Vorkasse gestaltet sich mit der Erweiterung BankPayment von allen Zahlungsschnittstellen am einfachsten. Doch was bei anderen Zahlungsschnittstellen ein einmaliger Einrichtungsaufwand ist, entwickelt sich bei der Vorkasse die manuelle Prüfung der Zahlungseingänge zum wiederkehrenden Zeitaufwand.

Manchmal versagt die Texterkennung der Bank bei der Verabreitung von Überweisungsträgern, sodass der Verwendungszweck etwa so aussehen könnte: I3 ET EL L.N1 1 980b l04 (was soviel heißen soll wie BESTELLNR 19806104)

Durch die manuelle Abwicklung auf der Seite des Kunden kommt es hin und wieder zu Kuriositäten. Einige Kunden nutzen aus Versehen eine alte Überweisungsvorlage inklusive des alten Betrages, andere erlauben sich die Beträge zu runden (statt 9,99 € werden z.B. 10,00 € überwiesen). Auch gibt es Kunden, die die Änderung Ihrer Bestellung darin verkünden, dass sie einfach eine komplett neue Bestellung aufgeben (ohne um Storno der vorigen Bestellung zu bitten) und dann den übrigen Differenzbetrag abzüglich Verstandkosten überweisen, sodass alle Überweisungen des Kunden in der Summe hoffentlich den Wert der neuen Bestellung ergeben. In einem solchen Fall würde jeder Automatismus versagen. Und spätestens bei der Steuererklärung gäbe es hier zusätzlichen Aufwand.

Eine Automatisierung ist über ein Warenwirtschaftssystem möglich, mit dem das Bankkonto über die HBCI-Schnittstelle abgefragt wird.

Fazit

+ Einfache Einbindung und Konfiguration in Magento
+ Transaktionsgebühren i. d. R. niedriger als bei anderen Schnittstellen

– Wiederkehrender Zeitaufwand durch manuelle Prüfung der Zahlungseingänge
– Automatisierung sehr aufwändig

Zahlungsabwicklung mit MoneyBookers

MoneyBookers ist, neben PayPal, von Haus aus in Magento integriert. MoneyBookers scheint sehr vielseitig zu sein, da gleich alle wichtigen Zahlungsmethoden abdeckt werden: Lastschrift, Kreditkarte, Sofortüberweisung und giropay. Doch was nützt eine vielseitige Zahlungsschnittstelle, wenn sie in so vielen Fällen nicht funktioniert und dadurch zahlungswillige Kunden verärgert?

In Magento wird die Zahlungsseite von MoneyBookers in einem iFrame von einem externen Server geladen. Der Händler hat auch hier keinen Einfluss auf die Gestaltung und Funktionen der Zahlungsseite von MoneyBookers.

Nach dem Test aller Zahlungsmethoden von MoneyBookers hat nur die Lastschrift erfolgreich funktioniert (die Lastschrift ist übrigens erst ab einem Betrag von 0,50 € möglich).

Bei der Zahlung mit Kreditkarte über MoneyBookers musste ich für meine Kreditkarte ein weiteres Passwort anlegen (Haftungsumkehr mit 3-D Secure), bei einer weiteren Kreditkarte, die sonst funktioniert, wurde ein Fehler gemeldet. In beiden Fällen wurde ein neues Fenster geöffnet mit einer sehr einfach gestalteten Maske eines weiteren mir unbekannten Anbieters, die von der Gestaltung her bei einem Kunden kein Vertrauen erwecken dürfte.

Bei Sofortüberweisung und giropay sollte nach Eingabe der BLZ und Kontonummer ein neues Fenster geöffnet werden. Dies passierte weder automatisch (Pop-Up-Blocker inaktiv) noch durch Klick auf eine entsprechende Schaltfläche! Bei aller Geduld habe ich es nicht geschafft über MoneyBookers eine Zahlung über die genannten Methoden durchzuführen. An dieser Stelle will ich keine Ausreden und Versprechungen vom Kundenservice hören, sondern ziehe das Fazit, dass MoneyBookers nur bedingt funktioniert.

Die Zahlungsabwicklung ist eine der wichtigsten Funktionen eines Online-Shops. Wenn diese nicht zuverlässig und einfach funktioniert, gehen zahlungswillige Kunden verloren. Von der Verwendung von MoneyBookers rate ich deshalb ab.

Fazit

+ einfache Konfiguration in Magento

– technische Umsetzung schlecht: im Test hat nur die Zahlung per Lastschrift funktioniert

Zahlungsabwicklung mit Sofortüberweisung

Die Sofortüberweisung ermöglicht Online-Banking über die eigene Weboberfläche und ist nur möglich, wenn der Kunde bereits Online-Banking nutzt.

Im Gegensatz zur Vorkasse über Online-Banking prüft Sofortüberweisung den Kontostand des Kunden zum Zeitpunkt der Überweisung und sendet eine Zahlungsbestätigung an den Shop, sobald die Zahlung durchgeführt wurde. So kann die Ware sofort versendet werden, ohne auf die Gutschrift auf dem eigenen Bankkonto zu warten, wie es bei der Vorkasse der Fall ist.

Nachteil von Sofortüberweisung ist die Tatsache, dass der Kunde dem Unternehmen hinter Sofortüberweisung den Zugang zu dem eigenen Konto ermöglicht. Das bedeutet, dass Sofortüberweisung nicht nur den Kontostand abfragen kann, sondern auch sämtliche Kontobewegungen einsehen und auf eigenen Servern speichern kann. Sofortüberweisung macht es geschickt: erst muss der Kunde die Bankverbindung eingeben. Erst in der nächsten Eingabemaske wird er zur Eingabe seiner Online-Banking-PIN gebeten. Vermutlich steigen viele Kunden an dieser Stelle aus und brechen den Bezahlvorgang ab.

Rückzahlungen über Sofortüberweisung sind nicht möglich. Bei Erstattung muss der Kaufbetrag über die eigene Bank auf das Konto des Kunden überwiesen werden. Bei Rückbuchungen zahlt Sofortüberweisung die Transaktionsgebühr grundsätzlich nicht zurück, da die eigene Leistung in der Überprüfung der Zahlungsfähigkeit des Kunden und Abwicklung der Zahlung sieht, die nicht erstattet werden kann.

Weiterhin ist zu beachten, dass zusätzlich zu den Transaktionsgebühren der Sofortüberweisung noch die Gebühr der eigenen Bank für jede Transaktion fällig wird.

Eine Alternative zu Sofortüberweisung ist giropay mit dem extrem wichtigen Unterschied, dass die Abwicklung der Zahlung direkt durch die eigene Bank erfolgt. Die Eingabe der Online-Banking-PIN erfolgt auf einer speziellen Online-Banking-Oberfläche der eigenen Bank, und nicht, wie bei der Sofortüberweisung in der Eingabemaske eines Unternehmens, das mit der eigenen Bank nichts zu tun hat. Die Einrichtung von giropay ist allerdings aufwändiger und wird nicht von allen Banken unterstützt.

Fazit

+ sehr einfache Einbindung und vollautomatische Konfiguration in Magento
+ nach PayPal relativ hohe Akzeptanz bei Kunden

– zusätzliche Gebühr der eigenen Bank für jede Transaktion
– keine Rückzahlung der Transaktionsgebühren bei Erstattungen
– Bedenklicher Konzept: Kunde ermöglicht der Sofortüberweisung Zugang zum eigenen Bankkonto

Zahlungsabwicklung mit PayPal

In Deutschland gehört PayPal bei vielen Kunden zu der beliebtesten Zahlungsmethode für Online-Zahlungen. Auch bei Händlern ist PayPal aufgrund der einfachen Einbindung in diverse Shop-Systeme sehr beliebt. Für Händler ist PayPal aber eine der teuersten Schnittstellen! PayPal nimmt neben einer festen Gebühr pro Transaktion noch Prozente vom Transaktionswert. Jeden Monat kommt da eine ordentliche Summe zusammen. Im B2B-Bereich werden PayPal-Gebühren oft auf den Kunden verlagert. Im B2C-Bereich ist es unüblich und kann Kunden abschrecken.

Rückzahlungen sind über PayPal einfach möglich. Dem Händler wird dabei die Transaktionsgebühr anteilig erstattet. Im Falle von z. B. Wertminderung der Ware kann der Betrag teilweise erstattet werden.

Fazit

+ hohe Akzeptanz bei Kunden
+ einfache Einbindung und Konfiguration in Magento (siehe Anleitung)

– kostenintensiv für Händler
– für Zahlungen mit Kreditkarte oder Lastschrift nicht geeignet

Weiterlesen: Einrichtung von PayPal in Magento

Bestellung in Magento löschen

Im Live-Betrieb durchgeführte Testbestellungen sind störend und verfälschen die Statistik. Doch das Löschen einer Bestellung ist in Magento nicht vorgesehen.

Mit der kostenfreien Erweiterung Seamless Delete Order ist dies möglich.

Aber Vorsicht: Die Erweiterung verdeckt rücksichtslos die Bestelltabelle mit der eigenen Spaltendefinition, sodass Anpassungen anderer Erweiterungen (z.B. Status-Symbole von DHL-Intraship) nicht sichtbar werden! Wird das Modul über System > Konfiguration > Erweitert > Erweitert > Modulausgaben deaktivieren deaktiviert, wird aus dem gleichen Grund die gesamte Bestelltabelle nicht mehr angezeigt.

Nach dem die Testbestellungen gelöscht wurden, muss die Erweiterung deshalb vollständig entfernt werden!

Die Erweiterung tut was sie verspricht, kommt jedoch aufgrund unsauberer Programmierung und der damit verbundenen Notwendigkeit der Löschung nach Anwendung nicht auf die Empfehlungsliste.

Versand-Automatisierung mit DHL Intraship

DHL Intraship ist eine Erweiterung, die die Erstellung von Paketmarken für den Versand über die DHL automatisiert. Bis auf einige Macken funktioniert die Erweiterung einwandfrei. Die Voraussetzung für die Nutzung von DHL Intraship ist die Unterzeichnung des Geschäftskundenvertrags zwischen DHL und dem Shop-Betreiber, der u. a. zum Versand von mindestens 300 Paketen pro Jahr verpflichtet.

Dieser Artikel basiert auf meiner Erfahrung mit folgender Kombination der Softwareversionen:

  • DHL Intraship Erweiterung Version 0.3.1
  • Versandsoftware Intraship 5.7 (die Online-Benutzeroberfläche von DHL Intraship)
  • Magento 1.5.1

Vorgehensweise

  1. Unter DHL für Geschäftskunden sich über Konditionen informieren und Vertragsunterlagen telefonisch anfordern.
  2. Nach Unterschrift des Vertrags erhält man den Zugang zum Geschäftskundenportal und ein Login zum DHL Intraship. Dort empfehle ich jeweils einen neuen Benutzer für jeden Shop einzurichten, der Intraship nutzen soll. Dies sorgt für höhere Sicherheit und im Nachhinein lässt sich einfach nachvollziehen, welcher Shop welche Sendung erstellt hat.
  3. DHL Intraship Erweiterung in Magento installieren und einrichten.

Einrichtung von DHL Intraship in Magento

Nach erfolgreicher Installation von DHL Intraship ist in System > Konfiguration > Verkäufe der neue Menüpunkt DHL Intraship  zu finden.

Basiskonfiguration

  • Aktiviert: Ja
  • Testmodus: Nein
  • Webservice-Anfragen und -Antworten protokollieren: Nein

Etiketten-Einstellungen

  • Papierformat der Etiketten: A5
  • Linker Rand: 2
  • Oberer Rand: 0

Von DHL erhält der Shop-Betreiber nach Vertragsunterzeichnung DIN-A5-Aufkleber gratis, die sich mit vielen Laser- und Tintenstrahldruckern bedrucken lassen.

Der eigentliche Inhalt des Etiketts hat die Maße 95 mm x 180 mm, doch auch dieses Format lässt sich nicht mit jedem Etikettendrucker bedrucken.

Bei der Auswahl der Versandkartons sollte das DIN-A5-Format der DHL-Etiketten berücksichtigt werden. Ist die größte Fläche des Kartons kleiner als DIN-A5, so kann das Etikett um die Ecke geklebt werden, sodass die Versandadresse auf der einen und die Strichcodes auf der anderen Kartonseite zu sehen sind.

Stammdaten

  • Intraship-Kennung: der Benutzername für den Zugang des Shops zu DHL Intraship
  • Intraship-Passwort: das Passwort des Shop-Benutzers in DHL Intraship
  • EKP: die DHL-Kundennummer, die nach der Unterzeichnung des Geschäftskundenvertrags vergeben wird.

Für jeden Shop, der DHL Intraship nutzen soll, empfehle ich, jeweils einen neuen Benutzer einzurichten. Dies sorgt für mehr Sicherheit. Außerdem lässt sich im Nachhinein nachvollziehen, welcher Shop welche Sendung erstellt hat.

Logen Sie sich in DHL Intraship ein und erstellen Sie einen neuen Benutzer unter Stammdatenverwaltung > Benutzerverwaltung. Das Passwort muss genau 8 Zeichen lang sein.

Neben dem Administrator wird ein zweiter Benutzer mit einem kryptischen Namen angezeigt. Dieser Benutzer wird von DHL verwendet und darf nicht gelöscht werden.

DHL Intraship Benutzerverwaltung

Automatische Sendungserstellung

  • Aktiviert: Nein

Die halbautomatische Sendungserstellung ist automatisch genug. Da DHL Intraship, wie oben erwähnt, einige Macken hat, ist manueller Eingriff ohnehin notwendig.

Halbautomatische Sendungserstellung

  • Aktiviert: Ja

Versandoptionen

  • Zahlungsarten für Nachnahme: Cash On Delivery

Wird im Shop die Zahlung per Nachnahme angeboten, muss DHL Intraship wissen, welche es ist. Bei Verwendung dieser Erweiterung taucht sie unter der Bezeichnung „Cash On Delivery“ in der Liste auf.

  • Produktgewicht als Standard verwenden: Ja
  • Maßeinheit des Produktgewichts: kg

Die Summe der Produktgewichte im Warenkorb wird an DHL übermittelt. Das Gesamtgewicht lässt sich bei halbautomatischer Sendungserstellung vor der Übermittlung anpassen.

  • Standardprodukt: DHL Paket
  • Nachnamegebühr von 2 Euro vom Gesamtbestellwert abziehen (nur Nachname-Bestellungen): Ja/Nein

Das Übermittlungsentgelt zahlt der Kunde dem Paketboten zusätzlich zu dem Gesamtbetrag, der auf dem Paketaufkleber angegeben ist. Dies lässt sich vermeiden, in dem der Gesamtbetrag um 2 EUR reduziert wird (siehe auch: Bezahlung per Nachnahme).

Versandoptionen – Nationale Sendungen

Auswahl nach Wunsch.

Versandoptionen – Sendungen in das europäische Ausland

Auswahl nach Wunsch.

Absenderdaten

Firmenname, Kontaktperson, Straße, Hausnummer, Postleitzahl, Stadt und Land erscheinen auf dem Versandaufkleber als Absender.

Tipp: Als Kontaktperson kann „Versandabteilung“ eingetragen werden.

Die Bankverbindung ist für Nachnahmesendungen relevant. Sie kann später eingetragen werden.

Benachrichtigungen

  • Nachricht mit Sendungsverfolgungsnummer an den Kunden senden?: Ja/Nein

In der Standardeinstellung von Magento erhält der Kunde den Lieferschein per E-Mail, sobald die Sendung erstellt wurde. Wird die Sendungsverfolgungsnummer an den Kunden gesendet, bekommt er den Lieferschein ein zweites Mal per E-Mail mit der Sendungsnummer. Dies ist nicht unbedingt notwendig, da der Kunde die Tracking-Nummer im Kundenbereich einsehen kann.

Zur Kasse

Auswahl nach Wunsch.

Sendungen mit DHL Intraship erzeugen

Nach der erfolgreichen Konfiguration können nun Sendungen erstellt werden. Eine vorbereitete Sendung wird in der Bestellübersicht von Magento durch das graue DHL-Symbol (Status: Wartend) gekennzeichnet.

Im halbautomatischen Modus müssen die Daten durch ein Klick auf das Menü Verkäufe > Sendungen > DHL-Intraship-Labels manuell erzeugen übermittelt werden. Je nach Anzahl vorbereiteter Sendungen kann dieser Vorgang einige Sekunden in Anspruch nehmen. Anschließend wechselt das Symbol DHL-Symbol in ein farbiges (Status: Erfolgreich) oder ein durchgestrichenes graues (Status: Fehlgeschlagen):

DHL Intraship States

Die erfolgreich erstellten Versandetiketten werden im Menü Verkäufe > Sendungen > DHL Intraship Dokumente angezeigt. Dort können mehrere Etiketten (maximal 20 Etiketten) in einem PDF-Dokument zusammengefasst und auf einmal zum Drucker gesendet werden. Wählen Sie dazu die gewünschten Einträge in der Liste und im Pull-Down-Menü die Aktion Intraship-PDF-Labels herunterladen und anschließend Ausführen.

Problembehandlung in DHL Intraship

Fehlgeschlagene Sendungen können in der Ansicht der Sendung innerhalb der betroffenen Bestellung untersucht werden.

In der Ansicht der Sendung wird der Fehler im Block Versandprotokoll unten auf der Seite angezeigt. Im Block Versand- und Trackinginformationen können die an DHL übermittelten Daten eingesehen und bearbeitet werden.

Nach der Behebung des Fehlers muss der Status der Sendung durch den Klick auf die Schaltfläche Versand wiederaufnehmen auf Wartend gewechselt werden, damit sie bei der erneuten Übermittlung an DHL (Verkäufe > Sendungen > DHL-Intraship-Labels manuell erzeugen) berücksichtigt wird.

Bekannte Probleme von DHL Intraship

Für diesen Artikel wurde DHL Intraship Version 0.3.1 und Magento 1.5.1 verwendet.

  • DHL Intraship ist nicht in der Lage, die Hausnummer von Straße zu trennen, wenn kein Leerzeichen dazwischen eingegeben wurde. Nach einem manuellen Eingriff ist die halbautomatische Sendungserstellung über Magento möglich.

    Eine bessere Trennung von Straße und Hausnummer ist mit dieser Modifikation möglich und wird in dem kommenden Release (d.h. 0.3.5) von Intraship eingebaut.
  • DHL Intraship unterstützt keinen Versand an Packstationen. In diesem Fall muss die Sendung komplett manuell erstellt werden.
  • Selten, aber dennoch kommt es zu Störungen auf der Seite von DHL. Als Fehler wird z.B. Anmeldung fehlgeschlagen angezeigt. In diesem Fall die Übertragung nach einigen Stunden erneut versuchen.

Verzeichnisrechte für DHL Intraship

Wird das erste Etikett mit DHL Intraship erzeugt, versucht die Erweiterung im folgenden Verzeichnis ein PDF-Dokument zu erzeugen:

/magento/var/intraship/documents

Ohne Schreibrechte kommt es zum Fehler. Nach dem die Schreibrechte auf das genannte Verzeichnis vergeben wurden, müssen die Daten nochmals an DHL gesendet werden.

Daten vor der Übertragung and DHL bearbeiten

DHL Intraship ist nicht in der Lage, die Hausnummer von Straße zu trennen, wenn kein Leerzeichen dazwischen eingegeben wurde. Um den Fehler zu beheben, müssen die Daten vor der (erneuten) Übertragung an DHL manuell bearbeitet werden.

Dazu die Sendung in der betroffenen Bestellung aufrufen und im Block Versand- und Trackinginformationen auf die Schaltfläche Bearbeiten klicken. Diese Daten werden unabhängig von der vom Kunden angegebenen Lieferadresse gespeichert. Die Straße mit der Hausnummer landet im Feld Adresszusatz und muss manuell auf die Felder Straße und Hausnummer verteilt werden:

DHL Intraship Problembehebung: Hausnummer von Straße trennen

Nach der Speicherung der Sendungsdaten muss der Versand wieder aufgenommen und die Daten an DHL erneut übermittelt werden.

Sendungen an Packstation über DHL Intraship

DHL Intraship Problembehebung: Packstation

DHL Intraship unterstützt in der aktuellen Version (0.3.1) keinen Versand an Packstationen. DHL Intraship meldet den folgenden Fehler:

at least one shipment has errors | please enter ‚customer id number‘ into field company name 2 or contact. | your order could not be processed your order could not be processed

Sendungen an Packstationen müssen komplett manuell erstellt werden.

In DHL Intraship im Menü Versandabwicklung Paket > Neuer Auftrag wird das Wort „Packstation“ im Feld Straße und die Nummer der Packstation im Feld Hausnummer eingetragen. Im Feld Firmenname wird der Vor- und Nachname des Empfängers eingetragen. Im Feld Firmenname2 wird die Postnummer eingetragen. Die Postnummer ist eine achtstellige Zahlenkombination und wird bei der Bestellung vom Kunden angegeben.

DHL Intraship Problembehebung: manueller Versand an Packstation

Bezahlen per Nachnahme in Magento – Cash on Delivery

Die Erweiterung Cash On Delivery ermöglicht Ihren Kunden per Nachnahme zu bezahlen, d. h. der Empfänger bezahlt die Ware in bar direkt beim Empfang an seiner Tür.

Wenn die Nachnahmegebühr in die ausgewiesene Mehrwertsteuer einfließen soll, muss eine Einstellung an zwei Stellen in System > Verkäufe > Steuer vorgenommen werden: Tax Class for Cash on Delivery Fee und Cash on Delivery fee include tax.

Weiterlesen: Bezahlung per Nachnahme

Magento Checkout Optimierung

Der Checkout-Bereich (die Kasse) sollte bestmöglichst optimiert sein. Hat der Kunde sich zum Kauf eines Produkts entschlossen, sollte der Checkout-Prozess so einfach, übersichtlich und selbsterklärend wie möglich gestaltet sein, damit es sicher zu einem Kauf kommt.

Dieser Tutorial ist die Zusammenfassung der bisherigen Tutorials zum Thema Checkout-Optimierung.

Anforderungen an den Checkout

  • Selbsterklärend: der Kunde soll zu jeder Zeit wissen, was als nächstes zu tun ist, woher er als nächstes klicken soll.
  • Übersichtlich: der Kunde soll in jedem Schritt wissen, was er jetzt eingeben muss und wie viele Schritte noch vor ihn liegen.
  • Schnell und einfach: es sollen keine unnötigen und/oder doppelten Eingaben dem Kunden abverlangt werden.

Optimierung des ersten Schritts und der Adresseingabe

  1. Klare Trennung zwischen Gast-Checkout und Kunden-Login
  2. Eine Zeile für die Straße
  3. Auswahl des Bundeslandes deaktivieren
  4. Telefonnummer optional

Erster Schritt und Adresseingabe nach der Optimierung

 

Checkout Optimierung: Wie möchten Sie zur Kasse gehen?

Erster Checkout-Schritt vor der Optimierung

Der Kunde sieht ein großes Feld mit Auswahl Gast/Registrieren, zwei Eingabefeldern und zwei Schaltflächen Weiter/Anmelden.

Es ist nicht sofort erkennbar, dass es sich um zwei separate Bereiche handelt. Aus Versehen klicken unregistrierte Kunden nach der Auswahl Gast/Registrieren auf die Schaltfläche Anmelden und werden als Nächstes mit einer Fehlermeldung beschäftigt:

Ohne in das Template eingreifen zu müssen, lässt sich die visuelle Trennung der beiden Bereiche durch ein passendes Hintergrundbild erreichen, welches als Style Cheet angegeben wird.

Hierzu analysieren wir die Seitenstruktur mit dem FireFox-PlugIn FireBug:

Der betroffene DIV-Element ist eindeutig über id=’checkout-step-login‘ identifiziert, was die Zuweisung eines anderen Hintergrunds einfach macht:

#checkout-step-login {
   background: url('../images/bkg-login.png') 0 0 no-repeat;
}

Dieser Eintrag kann nach der letzten Zeile in die Datei styles.css in dem Skin-Ordner (z.B. /skin/frontend/default/default/css/) hinzugefügt werden.

Erster Checkout-Schritt nach der Optimierung

Optionale Telefonnummer beim Checkout

Der Checkout-Bereich sollte bestmöglichst optimiert sein und dem Kunden keine unnötige Eingaben abverlangen. Während in anderen Ländern die Angabe der Telefonnummer zwecks Zustellung Sinn macht, ist sie in einem Deutschen Shop überflüssig. Magento verpflichtet den Kunden zur Eingabe der Telefonnummer, und dies lässt sich im Administrationsbereich nicht ändern.

Die folgenden Schritte beschreiben, wie die  Telefonnummer zu einer optionalen Eingabe geändert werden kann.

1. Anpassung in der Datenbank

UPDATE eav_attribute
  SET is_required = 0
  WHERE attribute_code = 'telephone';

2. Anpassung im Code

local-Codeverzeichnis anlegen:

mkdir -p /htdocs/magento/app/code/local/Mage/Customer/Model/Address/

Betroffene Datei in das local-Codeverzeichnis kopieren:

cp /htdocs/magento/app/code/core/Mage/Customer/Model/Address/Abstract.php
   /htdocs/magento/app/code/local/Mage/Customer/Model/Address

Im Code-Editor nach getTelephone suchen und die Zeilen zur Prüfung der Telefonnummer auskommentieren:

/*
    if (!Zend_Validate::is($this->getTelephone(), 'NotEmpty')) {
      $errors[] = $helper->__('Please enter the telephone number.');
    }
*/

3. Anpassung im Template

Betroffene Dateien:

/htdocs/magento/app/design/frontend/default/mytheme/
   /template/checkout/onepage/billing.phtml
   /template/checkout/onepage/shipping.phtml
   /template/customer/address/edit.phtml
   /template/customer/form/register.phtml

Hinweis: Ist die Erweiterung NoRegion installiert, verwendet Magento die o. g. Dateien aus dem Template-Verzeichnis der Erweiterung:

/htdocs/magento/app/design/frontend/default/default/template/noregion

Vor der Anpassung sollte das Verzeichnis von NoRegion inkl. aller Unterverzeichnisse und Dateien in das eigene Template-Verzeichnis kopiert werden:

/htdocs/magento/app/design/frontend/default/mytheme/template/noregion

In den drei Dateien müssen jeweils alles mit „require“ rund um das telephone-Textfeld entfernt werden:

<label for="shipping:telephone" class="required"><em>*</em>
<?php echo $this->__('Telephone') ?></label>
<div class="input-box">
<input type="text" name="shipping[telephone]"
value="<?php echo $this->htmlEscape($this->getAddress()
->getTelephone()) ?>"
title="<?php echo $this->__('Telephone') ?>"
class="input-text required-entry" id="shipping:telephone"
onchange="shipping.setSameAsBilling(false);" />
</div>

Bundesland im Magento Checkout deaktivieren

Während in den USA die Auswahl des Staates Sinn macht, ist die Auswahl des Bundeslandes in Deutschland überflüssig. Zur Optimierung des Checkout-Prozesses in einem Deutschen Shop sollte deshalb das Menü zur Auswahl des Bundeslandes ausgeblendet sein.

Dies ist sehr einfach mit der Erweiterung NoRegion von mxperts.

SSL Fehler: Ungültiges oder selbst signiertes Zertifikat

Mit der im Titel genannten Fehlermeldung bin ich beim Upload von Produktbildern im Administrationsbereich konfrontiert.

Fehlerursache

Im Web werden verschiedene Ursachen und Lösungen für das Problem genannt. Bei mir lag es daran, dass das Online-Verzeichnis von Magento mit einem HTTP-Passwort über .htaccess geschützt war. Zwar wurde nach der Passworteingabe der Zugang gewährt, doch davon bekommt das Flash-Upload-Plug-In von Magento anscheinend nichts mit.

Lösung

Die Abhilfe ist der (vorübergehende) Wechsel auf den Internet Explorer unter Windows.

Meiner Erfahrung nach ist das die einzige (!) Umgebung, in der der Bilder-Upload in Magento nach dem Login in das passwortgeschützte Verzeichnis einwandfrei funktioniert. Bei den Browsern FireFox, Chrome und Opera sowohl unter Ubuntu 10.04 als auch unter Windows 7 kommt es zum Fehler!

Alternativ ist die vorübergehende – und mit entsprechenden Risiken verbundene – Deaktivierung des HTTP-Passworts möglich. Für einen besseren Schutz könnte die Startseite des Shops dabei durch eine leere Seite mit Layout „Leer“ ersetzt werden. Möchte man mit dieser Lösung länger arbeiten, sollte konsequenterweise auch für die 404-Fehlerseite das Layout „Leer“ gewählt werden!

Lokale Testumgebung für Magento

Entwicklungsarbeiten am Shop (Template-Änderungen, Update, Installation von Erweiterungen) sollten in einer Testumgebung stattfinden und erst danach auf die Produktivumgebung übertragen werden.

Die Testumgebung sollte der Produktivumgebung möglichst ähnlich sein. Wird auf dem Webserver ein Unix-System verwendet (z.B. Debian), sollte auch lokal auf einem Unix-System gearbeitet werden (z.B. Debian oder Ubuntu Server).

Für Web-Entwicklungen ist ein Linux grundsätzlich besser geeignet und bietet folgende Vorteile:

  • Nahtlose Integration von SSH/SFTP in das Betriebssystem, die ein bequemes und sicheres Arbeiten mit Dateien auf dem Server erlaubt
  • Verweise, die aufgrund der Groß-/Kleinschreibung auf dem Server ungültig werden, werden bereits auf der lokalen Testumgebung erkannt
  • MySQL-Server läuft schneller und stabiler (trotz identischer Hardware)
  • FireFox, Chrome, Opera für Linux verfügbar
  • Tolle Organisationsmöglichkeiten durch multiple Workspaces
  • Symbolische Links, besonders interessant für den Modul Manager (modman)
  • GREP, ein schnelles und mächtiges Suchwerkzeug, unverzichtbar bei Code-Analyse
    (Abhilfe unter Windows: Funduc Search & Replace)

Nachteile von Web-Entwicklung unter Linux gegenüber Windows:

  • Kein Internet Explorer. Trotz wachsender Beliebtheit anderer Browser ist der Internet Explorer nach wie vor sehr verbreitet und deshalb eine wichtige Testumgebung. Abhilfe: Emulation von Windows in dem kostenlosen VMWave Player, Virtual Box oder browsershots.org
  • Angebot von Grafiksoftware eingeschränkt. Mit GIMP und Inkscape kann man viel erreichen, aber oft gestaltet sich der Weg zum Ergebnis als relativ umständlich.

Als vorkonfigurierter Webserver kann, sowohl unter Windows als auch unter Linux, XAMPP bzw. LAMPP verwendet werden.

ACHTUNG: Magento muss lokal unbedingt über die IP http://127.0.0.1 aufgerufen werden. Versucht man es mit http://localhost, kommt es zu Fehlern.

Noch besser ist es die lokale Installation über eine ähnliche Domain wie z.B. http://magento-trainer.com/magento aufzurufen, während die Produktivumgebung öffentlich unter http://magento-trainer.de/magento erreichbar ist. Die lokalen Domains sind in die hosts-Datei einzutragen. Unter Ubuntu ist diese Datei unter /etc/hosts zu finden (siehe auch Hosts-Datei bei Wikipedia). Der entsprechende Eintrag könnte wie folgt aussehen:

127.0.0.1             magento-trainer.com

Nach dem Überschreiben der lokalen Testumgebung mit den Daten der Produktumgebung müssen einige Anpassungen durchgeführt werden, damit die Testumgebung schnell einsatzbereit ist:

  • Domainadressen zur Kontrolle anzeigen:
SELECT * FROM core_config_data
  WHERE path = 'web/unsecure/base_url'
  OR path = 'web/secure/base_url';
  • Domainadressen umstellen:
UPDATE core_config_data
  SET value = REPLACE(value, 'magento-trainer.de', 'magento-trainer.com')
  WHERE path = 'web/unsecure/base_url'
  OR path = 'web/secure/base_url';

ACHTUNG: Wenn Sie die Basis-Adressen einzeln in Textfelden eines GUI-Datenbankeditors bearbeiten, achten Sie darauf, dass Sie die geänderte Adresse mit einem Slash abschließen, d. h. als Wert in der Value-Spalte muss z. B. http://local.xonu.de/ statt http://local.xonu.de (ohne Slash am Ende) eingetragen sein. Gleiches gilt beim Umzug Ihres Magento-Shops auf einen anderen Server, in ein anderes Verzeichnis des gleichen Servers oder beim Wechsel der Shop-Domain.

  • HTTP Secure (SSL/TLS) deaktivieren (oder SSL in XAMPP aktivieren):
    • Secure Connection für Administrationsbereich deaktivieren:
UPDATE core_config_data
  SET value = 0
  WHERE path = 'web/secure/use_in_adminhtml';
    • Secure Connection für sensible Shop-Bereiche (Login und Benutzerkonto, Warenkorb und Kasse) deaktivieren:
UPDATE core_config_data
  SET value = REPLACE(value, 'https://', 'http://')
  WHERE path = 'web/unsecure/base_url'
  OR path = 'web/secure/base_url';
  • Noch müssen die Zugangsdaten für Datenbankzugriffe in magento/app/etc/local.xml angepasst werden. Einfacher ist es lokal eine gleichnamige Datenbank mit gleichen Zugangsdaten zu verwenden.

Mit der lokalen Testumgebung können Zahlungsschnittstellen wie PayPal nicht getestet werden, da sie aus dem Web nicht erreichbar ist und folglich keine Zahlungsbestätigungen empfangen kann. Abhilfe schaffen hierbei Anbieter von Managed DNS.

Weiterlesen: SSL in der lokalen Testumgebung aktivieren

 

Statische Blöcke in CMS-Seiten, Template, Layout verwenden

Statischen Block in einer CMS-Seite verwenden (CMS-Code)

{{block type="cms/block" block_id="my_block"}}

Wenn die Extension Static Blocks Everywhere installiert ist, funktioniert der CMS-Code nicht nur in CMS-Seiten und anderen statischen Blöcken, sondern auch in Produktbeschreibung, Kategoriebeschreibung und in Bestellbedingungen.

Statischen Block in Kategoriebeschreibung verwenden

Der o. g. Code wird in der Kategoriebeschreibung nicht unterstützt, kann aber über Kategorie-Einstellungen unter der Kategoriebeschreibung angefügt werden. Dazu ist auf dem Register Anzeige Einstellungen als Display Mode „Statischer Block und Artikel“ zu wählen und im Menü CMS Block darunter den Statischen Block:

Um statische Blöcke direkt in Beschreibungstext einer Kategorie verwenden zu können, muss die Extension Static Blocks Everywhere installiert sein.

Statischen Block im Layout verwenden (XML-Code)

<block type="cms/block" name="my_block_name">
  <action method="setBlockId">
     <block_id>my_block</block_id>
  </action>
</block>

In diesem Beispiel ist my_block der Seitenbezeichner (engl.: Identifyer) des statischen Blocks, während my_block_name der Name des Layout-Elements ist.

Statischen Block im Template verwenden (PHP-Code)

<?php echo $this->getLayout()->createBlock('cms/block')->setBlockId('my_block')->toHtml() ?>

Leere DIV-Elemente in CMS-Seiten

Zur Gestaltung einer CMS-Seite können DIV-Elemente (z.B. mit einem Hintergrundbild) verwendet werden. Leere DIV-Elemente werden allerdings von Magento nach dem Speichern der Seite gelöscht!

Dieses Problem kann durch das Einfügen eines geschützten Leerzeichens &nbsp; umgangen werden:

<div class="...">&nbsp;</div>

 

CSS und JavaScript in eine CMS-Seite oder Kategorie-Seite einbinden

Soll die Startseite oder eine kundenoptimierte Landeseite ein spezielles Design bekommen, muss ein eigenes CSS und ggf. JavaScript eingebunden werden. Dies ist mit einem XML-Code im Seiten-Layout möglich:
<reference name="head">
  <action method="addCss">
    <stylesheet>css/landing-page.css</stylesheet>
  </action>

 <action method="addJs">
   <script>custom/landing-page.js</script>
  </action>
</reference>
Dieser XML-Code produziert die folgenden Code-Zeilen im Head-Bereich:
<script type="text/javascript"
src="http://magento-trainer.de/magento/js/custom/landing-page.js">
</script>

<link rel="stylesheet" type="text/css"
href="http://magento-trainer.de/magento/skin/frontend/
 default/mytheme/css/landing-page.css" media="all" />
Zu beachten ist dass die relative Pfadangabe verschieden interpretiert wird: Während das JavaScript ist in das globale JS-Verzeichnis zu kopieren ist, gehört die CSS-Datei in das Theme-Verzeichnis.

Anzahl von Produkten pro Zeile einstellen

In der Raster-Ansicht (engl. Grid View) zeigt Magento standardmäßig 4 Produkte pro Zeile. Möchte man die Anzahl von Produkten pro Zeile einstellen, ist dies über Layout mit dem folgenden XML-Code möglich:

<reference name="content">
<action method="setColumnCount"><columns>5</columns></action>
</reference>

Der Beispiel sorgt dafür, dass 5 Produkte pro Zeile angezeigt werden. Der XML-Code kann entweder in der entsprechenden Layout-Datei für alle Kategorien oder für eine spezielle Kategorie in dem Tab „Eigene Gestaltung“ im Feld „Custom Layout Update“ eingetragen werden:

Telefonnummer beim Checkout optional

Kasse (engl. Checkout) ist ein sehr wichtiger Bereich eines Online-Shops und sollte bestmöglich optimiert sein, damit der Kunde in diesem Schritt nicht abspringt.

Unnötige Eingaben und zu viele Schritte sollten deshalb vermieden werden. In Deutschland ist die Angabe der Telefonnummer bei der Bestellung meistens überflüssig, aber bei Magento Pflicht! Der Kunde lässt sich ungerne zu etwas nötigen, dessen Zweck er nicht erkennt. So bekommt man oft als Telefonnummer 123123 o. ä. übermittelt.

In Magento ist keine Einstellung vorgesehen, die Eingabe der Telefonnummer auf Optional zu setzen. Auch gibt es keine Erweiterungen, das Feld für die Eingabe der Telefonnummer ausblenden. Dies ist nur mit etwas Aufwand möglich: Optionale Telefonnummer beim Checkout (Tutorial).

Eine entsprechende Erweiterung würden viele Shop-Betreiber in Deutschland begrüßen!

Statische Blöcke in Produkt- und Kategoriebeschreibungen und Bestellbedingungen verwenden

Statische Blöcke (static blocks) in Magento ist eine sehr praktische Funktion, mit der die Wiederverwendbarkeit von Inhalten vereinfacht wird. Wird ein Block mit dem Namen my_block definiert, kann er auf eine CMS-Seite mit dem folgenden Code eingefügt werden:

{{block type="cms/block" block_id="my_block"}}

Leider unterstützt Magento von Haus aus die statischen Blöcke nur in CMS-Seiten. In Artikelbeschreibungen und in Kategoriebeschreibungen wird der Block-Code nicht interpretiert. Auch in Bestellbedingungen werden statische Blöcke nicht unterstützt.

Dies lässt sich beheben, in dem betroffene Objekte mit einer zusätzlichen Methode erweitert werden.

Im ersten Schritt sind die folgenden Dateien in den Ordner magento/app/code/local zu kopieren.

  • magento/app/code/core/Mage/Catalog/Model/Product.php
  • magento/app/code/core/Mage/Catalog/Model/Category.php
  • magento/app/code/core/Mage/Checkout/Model/Agreement.php

Tipp: mkdir kann unter Linux mit dem Paramter -p alle Unterverzeichnisse in einem Befehl erzeugen:

mkdir -p magento/app/code/local/Mage/Catalog/Model/

Im nächsten Schritt werden folgenden Dateien bearbeitet:

  • magento/app/code/local/Mage/Catalog/Model/Product.php
  • magento/app/code/local/Mage/Catalog/Model/Category.php
  • magento/app/code/local/Mage/Checkout/Model/Agreement.php

Im zweiten Schritt ist in die Datei Agreement.php die folgende Funktion vor der letzten „}“ einzufügen:

function getContent()
 {
   $content = $this->getData('content');
   $templateFilter = Mage::getModel('cms/template_filter');
   $cms = $templateFilter->filter($content);
   return $cms;
 }

In die Dateien Product.php und Category.php wird eine ähnliche Funktion vor der letzten „}“ eingefügt, die sich im Namen und in dem Parameter der ersten Codezeile unterscheidet:

function getDescription()
 {
   $content = $this->getData('description');
   $templateFilter = Mage::getModel('cms/template_filter');
   $cms = $templateFilter->filter($content);
   return $cms;
 }

Damit statische Blöcke auch in der Kurzbeschreibung von Produkten verwendet werden können, muss in Product.php zusätzlich  die folgende Funktion eingefügt werden:

function getShortDescription()
 {
    $content = $this->getData('short_description');
    $templateFilter = Mage::getModel('cms/template_filter');
    $cms = $templateFilter->filter($content);
    return $cms;
 }

Nachtrag vom 29.06.2012: Diese Modifikation wurde getestet und funktioniert mit Magento 1.4 / 1.5.1 / 1.6.2 / 1.7.0.

Nachtrag vom 01.08.2012: Die kostenfreie Extension Static Blocks Everywhere, verwendet die Überschreibungslogik von Magento, um die betroffenen Klassen mit den Methoden sauber zu erweitern und die Nutzung statischer Blöcke überall in Magento zu ermöglichen.

Banner-Erweiterung für Magento

In Magento Connect sind einige Banner gelistet und doch konnte ich weder unter den kostenlosen und noch unter den kostenpflichtigen Bannern keinen finden, der die Grundfunktionen und Effekte bietet, die man heute von einem Banner erwartet.

Ein Banner (auch Carousel, Slider, Slide Show genannt) sollte heute folgende Funktionen bieten:

  • Übergangseffekte
    • Minimal: Langsames Überblenden und langsames Einfahren/Ausfahren
    • Einstellbare Übergangszeit
  • Navigation
    • Thumbnails oder Bullets über die einzelne Banner erreicht werden können
  • Sinnvolle Integration mit Magento

Multiple Banner Extension

Von den wenigen Bannern, die in Magento Connect gelistet sind, hat die kostenlose Erweiterung Multiple Banner Extension in Bezug auf Integration mit Magento am besten funktioniert.

Im Magento Administrationsmenü erscheint ein neuer Eintrag „Banner“ über den Bannergruppen und einzelne Bilder verwaltet werden können. Bilder können in mehreren Gruppen verwendet werden.

Die Effekte, die Multiple Banner Extension mit sich bringt sind notdürftig und nicht zeitgemäß. Doch diese lassen sich über die Modifikation des Templates nachbessern. So kann die Erweiterung mit einem überschaubaren Entwicklungsaufwand mit dem kostenlosen Nivo-Slider oder einem Slider aus dieser Liste erweitert werden.

Nachtrag vom 26.10.2012:

Diese Banner-Erweiterung kommt mit einer Skalierungsfunktion, die die Bannergrafik für jede Gruppe auf die dort eingestellte Größe skaliert abspeichert. Auch wenn die Originalgrafik bereits die richtige Größe hat, wird die Grafik trotzdem neu berechnet. Dies führt leider in vielen Fällen zu einem beträchtlichen Qualitätsverlust des angezeigten Bilds.

Ferner werden alle hochgeladenen Bilder in File-123456789.jpg umbenannt, wobei die lange Zahl von der PHP-Funktion time kommt. Die für die Suchmaschinenoptimierung vorteilhafte Dateibenennung wird so leider zerstört.

Fooman Jirafe Analytics

Eigentlich eine gute Erweiterung, weil sie auf Anhieb funktioniert und gute Statistikfunktionen bietet, die auf einem schönen und bequemen Dashboard auf AJAX-Basis dargestellt werden.

Doch diese Funktionalität kommt zu einem Preis über den der Anbieter kein Wort verliert: Jirafe Analytics speichert sämtliche Besucher- und Verkaufsstatistiken Ihres Shops auf der eigenen Piwik-Installation (eine Open Source Alternative zu Google Analytics), zu der Sie als Shop-Betreiber selbst keinen Zugang haben. Aus diesem Grund kommt Jirafe Analytics auf die schwarze Liste!

Weder in der Beschreibung der Erweiterung bei Magento Connect, noch in der Magento-Administration gibt es Hinweise darüber, wo Jirafe die Daten speichert. Erst im Code der Erweiterung findet wenn die Links api.jirafe.com und data.jirafe.com. Bei der Installation erzeugt Jirafe über https://api.jirafe.com einen neuen Piwik-Benutzer und Site-IDs, die man in der Datenbank in der Tabelle admin_user in zusätzlichen Spalten findet. Alle Ihre Besucherstatistiken und Verkaufszahlen in Ihrem Shop sendet Jirafe an die eigene Piwik-Installation unter https://data.jirafe.com, zu der Sie keinen Zugang haben. Der Piwik-Benutzer wird aus Ihrer im Shop hinterlegten Administrator-Email und einem Prefix (jirafe_123_admin@magento-trainer.de) kombiniert, sodass Jirafe-Betreiber bereits über den Benutzernamen auf die Herkunft der Statistiken schließen können. Als Site-ID habe ich eine Zahl über 23000 zugewiesen bekommen – so viele Seiten überwacht Jirafe schon auf der eigenen Piwik-Installation.

Der Jirafe-Dashboard ist die einzige Möglichkeit, Ihre eigenen Statistiken einzusehen. Dies bedeutet auch, dass wenn Sie sich entscheiden sollten Ihren Shop neu aufzusetzen, sie einen neuen Benutzernamen und neue Site-IDs von Jirafe bekommen würden, und damit keinen Zugang zu Ihren alten Statistiken.

Meine Frage, wie man Jirafe einstellen kann, sodass die Daten an meine eigene Piwik-Installation gesendet werden, wurde wie folgt beantwortet:

„Thanks for the message. Jirafe automates placing the analytics tags in pages, as well as adding new sites and users when stores and users are modified in Magento.  If you want to do this to your own version of Piwik, I would install Jirafe on your site, and make a note of the tags that are used.  Then, you can remove the Jirafe module and modify the domain being called from the tags (from data.jirafe.com to whatever your domain is) and put these tags into your pages manually.  Keeping tags current for ecommerce stores is hard – which is one of the reasons we created Jirafe.“

Mit anderen Worten ist diese Möglichkeit in der Jirafe Erweiterung nicht vorgesehen.

Piwik lässt sich einfach auf dem eigenen Server installieren. Doch ohne zusätzlichen Entwicklungsaufwand speichert er keine E-Commerce-Daten wie Warenkorbwert und der Wert abgebrochener Einkäufe (Warenkörbe, die nicht bestellt wurden).

Market Ready Germany macht den Shop fit …für Neuinstallation!

Verwendung von Market Ready Germany (MRG) ist nicht empfohlen, da die Erweiterung viele unnütze Module zwecks Werbung installiert, die im Nachhinein nicht entfernt werden können, da sie in der Konfiguration der Erweiterung als notwendige Module deklariert sind. Ferner lässt sich die Erweiterung nicht sauber entfernen, sondern hinterlässt weitreichende Änderungen am Shop-System.

MRG habe ich damals auf Magento 1.5.0 installiert. Offiziell war MRG zu diesem Zeitpunkt mit Magento 1.4 kompatibel, doch die Installation über den Downloader konnte fehlerfrei abgeschlossen werden. Später habe ich entdeckt, dass die Schaltfläche “In den Warenkorb” auf Detailseite aller Artikel blockiert ist! Im Nachhinein habe ich herausgefunden, dass dies von MRG verursacht wurde.

Erweiterungen, die Market Ready Germany installiert:

  • market_ready_germany
    • Steuerklassen für Deutschland – lassen sich manuell einrichten
    • Impressum-Modul – überflüssig, da ähnliche Funktionalität wie statische Blöcke
    • Statische Blöcke in Bestellbedingungen – einfache Code-Anpassung nötig
    • CMS-Seiten für Impressum, AGB, Wiederruf – auch manuell möglich
    • Email-Templates – basieren auf dem Impressum-Modul (und funktionieren nach der Deinstallation nicht vollständig) – lieber statische Blöcke verwenden!
  • Locale_Mage_community_de_DE
    • Deutscher Sprachpacket für Magento
  • BankPayment
    • Vorkasse
  • symmetrics_trustedrating
    • Trusted Shops Kundenbewertungen
    • Grauer Kasten mit Sternchen
    • Macht ohne Abonnement bei TrustedShops und Kundenbewertungen keinen Nutzen
  • symmetrics_cashticket
    • Bezahlung mit einem PIN-Code von CashTicket, dadurch mehr Privatsphäre, da keine Angabe von Kreditkarte nötig
  • Mage_Econda
    • Encoda Web Shop Controlling
    • Umfangreiche Analyse und Live-Ticker
    • Speichert Ihre Shop-Daten auf dem eigenen Server
  • Flagbit_Factfinder
    • Suchvorschläge während des Tippvorgangs im Suchfeld
Fazit: Nur 2 von 7 Erweiterungen bieten einen  Mehrwert für den Shop-Betreiber (die Vorkasse und der deutsche Sprachpaket), sind aber über Magento Connect auch unabhängig von MRG installierbar. Einstellungen, die MRG durchführt sind ebenfalls über die Magento-Administration machbar. Der Aufwand für manuelle Einstellungen steht allerdings in keinem Verhältnis zu der Abhängigkeit und Unflexibilität, die MRG mit sich bringt. Daher nur zu Lernzwecken auf einer Testinstallation zu gebrauchen, aber niemals in einer Produktivumgebung!

Eine gute Alternative zu German Market Ready, neben der manuellen Umsetzung der Anpassungen, stellt German Setup dar.

Einrichtung von PayPal in Magento 1.5.x und 1.6.x

 

Hier geht’s zum neuen Artikel: PayPal in Magento einrichten

 

Die Ingetration von PayPal Standard in Magento ist einfach: man muss lediglich die PayPal-Email-Adresse in dem Administrationsmenü eintragen. Alle anderen Einstellungen wie z.B. API-Schlüssel sind für PayPal Standard nicht relevant.

Bestellungen bezahlt mit PayPal für Kunden unsichtbar?

Die wichtigsten Einstellungen für PayPal Standard müssen im PayPal-Konto durchgeführt werden. Ohne dieser Einstellungen werden PayPal-Zahlungen zwar erfolgreich durchgeführt, aber Magento bekommt davon nichts mit. Als Konsequenz, erscheint eine Bestellung , die mit PayPal bezahlt wurde nicht im Kundenkonto. Im Administrationsmenü hat eine solche Bestellung den Status Pending Payment, der manuell nicht geändert werden kann (siehe auch: Bestellstatus in Magento verändern). Damit die Bestellung den Status Processing erhält und im Kundenbereich erscheint, muss Magento von PayPal eine Zahlungsbestätigung bekommen, auch IPN (= Instant Payment Notification) genannt.

Voraussetzungen für den Empfang von Instant Payment Notifications von PayPal

Damit Magento IPN-Nachrichten empfangen kann, muss die Shop-URL im PayPal-Konto eingetragen werden. Ferner muss der Magento-Shop (oder zumindest die PayPal-IPN-URL) im Web öffentlich erreichbar sein.

D.h. für eine lokale Testinstallation von Magento muss ein DynDNS-Service eingerichtet werden. Ferner darf der Magento-Ordner nicht mit einem .htaccess-Passwort (HTTP-Passwort) geschützt sein!

Diese Voraussetzungen gelten übrigens auch für den Empfang von Zahlungsbestätigungen von MoneyBookers und ähnlichen Zahlungsschnittstellen.

Konfiguration von PayPal für den Empfang von Instant Payment Notifications

  1. Reiter: Mein Konto > Mein Profil > Untermenü: mehr…
  2. Unten links ggf.: Klassisches Profil anzeigen
  3. Spalte: Verkäufereinstellungen > Einstellungen für sofortige Zahlungsbestätigung
  4. Schaltfläche: Einstellungen (vorher ggf. Schaltfläche: Sofortige Zahlungsbestätigungen aktivieren)
  5. Benachrichtigungs-URL: http://www.magento-trainer.de/magento/paypal/ipn/