Import von Logistikdaten in Magento nach VDA 4921
Magento bietet die Möglichkeit, dass man bei einer Bestellung die Sendungen hinterlegt. Dies können auch Mehrere sein und man kann genau angeben, welche Artikel im Paket vorhanden sein sollen. Es lassen sich auch Tracking-Daten hinterlegen, z.B. die Sendungsverfolgungsnummer von DHL. Das ermöglicht Kunden den Versand ihres Pakets zu verfolgen. Meistens werden diese Nummern per E-Mail an den Kunden verschickt. Ein besserer Service ist es natürlich, wenn die Daten schon bei der Bestellung im Shop hinterlegt werden.
Ein zusätzlicher Vorteil ist, dass für die Service-Mitarbeiter des Shop-Betreibers bei Rückfragen des Kunden über Telefon oder E-Mail einfach über das Magento Admin Interface alle relevanten Daten vorhanden sind und sie so schneller und einfacher die Fragen des Kunden bearbeiten können.
Um diese Tracking-Daten in Magento zu importieren gibt es verschiedene Wege, z.B. über die Schnittstelle vom Versanddienstleister direkt aus dem ERP-System, der über den Connector den Shop befüllt, wenn dort die Daten vorhanden sind.
In manchen Fällen wird aber der Versand von einem externen Partner übernommen, so dass man keinen Zugriff auf die Daten hat. In einem Fall bei einem Kunden konnte aber der Dienstleister die entsprechenden Daten als Datei zur Verfügung stellen. Diese Datei entspricht dem Standard nach VDA 4921. Dies ist ein Standard der vom Verband der Automobilindustrie festgeschrieben wurde. In der Datei ist die Lieferscheinnummer und die Sendungverfolgungsnummer enthalten. InitOS hat ein Modul entwickelt, um diese Daten in Magento zu importieren.
Technisch funktioniert das so: Die Dateien werden per FTP abgeholt, dann liest ein von uns entwickelter Parser die Daten aus den Dateien aus, das ERP-System wird angefragt um der Lieferscheinnummer eine Bestellung zuzuordnen und darauf hin wird die Informationen in Magento hinterlegt.
Haben sie ein ähnliches Problem? Brauchen Sie Hilfe mit der Integration ihrer Prozesse in ihrem Shop oder haben sie Intresse an einer PHP Lib mit der sie VDA 4921 Daten verarbeiten können? Dann treten Sie einfach mit uns in Kontakt.
Über Markus Schneider
Markus Schneider ist Experte für Shop- und ERP-Systeme. Er betreut mehrere eCommerce Kunden welche Magento oder Oxid eSales einsetzten. Dabei integriert er nicht nur CMS Systeme wie Joomla, TYPO3 oder WordPress in ihren Shop, sondern beschäftigt sich auch mit dem Einsatz von Warenwirtschaft und deren Prozesse, dabei greift er auf gesammelte Erfahrung von unterschiedlichen System von OpenERP, über Sage bis hin zu SAP zurück.
Magento – doppelte Bestellung vermeiden
Bei Magento gibt es eine Unschönheit beim Checkout. Diese kann zu doppelten Bestellungen führen.
Wenn ein Kunde beim Durchlaufen des Checkouts im letzten Schritt angekommen ist, wird beim Drücken, des Buttons “Bestellung abschicken”, der Request per Ajax absetzt und der Button deaktiviert. Dies ist erst mal genau so wie es sein soll.
Sobald aber dieser Request an den Browser mit der Bitte, den Kunden weiter auf die Seite des externen Zahlungsanbieters zu leiten zurückgeleitet wird, wird der Button wieder aktiviert. Wenn der Kunde jetzt nochmals klickt, dann wird der Kaufprozess noch mal angestossen und in Magento zwei Bestellungen erzeugt. Dies sollte aber vermieden werden, weil der Kunde mit hoher Wahrscheinlichkeit nur eine Bestellung tatsächlich absetzen wollte. Die Überraschung und vermutlich auch das Ärgernis beim Kunden ist im Ergebnis groß, falls diese doppelt verschickt und entsprechend auch abgerechnet werden sollte. Außerdem steigt der Verwaltungsaufwand auf Seite des Anbieters natürlich völlig unnötig.
Dieses Problem in Magento lässt sich nur beheben, wenn man sein Template anpasst. Nachfolgend hierzu eine kurze Anleitung (im Falle von Magento 1.7).
Hierfür muss man das eigene Template im Checkout anpassen, dafür kopiert man die Dateien:
- app/design/frontend/base/default/template/checkout/onepage/review.phtml
- app/design/frontend/base/default/template/checkout/onepage/review/button.phtml
an die selbe Stelle des eigenen Templates, falls diese noch nicht vorhanden ist.
In der review.phtml ändert man:
<script type="text/javascript">// <![CDATA[
review = new Review('<?php echo $this->getUrl('checkout/onepage/saveOrder') ?>', '<?php echo $this->getUrl('checkout/onepage/success') ?>', $('checkout-agreements'));
// ]]></script> |
zu:
<script type="text/javascript">// <![CDATA[
var btnActive=true;
review = new Review('<?php echo $this->getUrl('checkout/onepage/saveOrder') ?>', '<?php echo $this->getUrl('checkout/onepage/success') ?>', $('checkout-agreements'));
function activateButton() {
btnActive = true;
$("submitBtn").update("<?php echo $this->__('Place Order') ?>");
}
// ]]></script> |
in der button.phtml ändert man von:
<button type="submit" title="<?php echo $this->__('Place Order') ?>" class="button btn-checkout" onclick="review.save();"><span><span><?php echo $this->__('Place Order') ?></span></span></button> |
nach:
<button type="submit" title="<?php echo $this->__('Place Order') ?>" id="submitBtn" class="button btn-checkout" onclick="if(btnActive) {btnActive=false; review.save();}"><span><span><?php echo $this->__('Place Order') ?></span></span></button> |
Abschließend muss man noch eine Änderung im JS machen, damit der Button im Fall eines Fehlers wieder aktiviert wird. Hierfür in der Datei:
/skin/frontend/base/default/js/opcheckout.js (bzw. angepasste Version im Template) in der Zeile 887 nach:
if (msg) { alert(msg); } |
folgendes einfügen ( Review.nextStep() ):
if(typeof(activateButton) == typeof(Function)){ activateButton(); } |
Achtung: Man sollte hier wissen was man tut, da bei Fehlern in der Umsetzung der ganze Kaufprozess nicht funktioniert, das heißt man muss gründlich testen. Wir übernehmen daher natürlich keine Verantwortung für die vorgestellte Lösung ‘-).

This work is licensed under a Creative Commons Attribution 3.0 Unported License.
Über Markus Schneider
Markus Schneider ist Experte für Shop- und ERP-Systeme. Er betreut mehrere eCommerce Kunden welche Magento oder Oxid eSales einsetzten. Dabei integriert er nicht nur CMS Systeme wie Joomla, TYPO3 oder WordPress in ihren Shop, sondern beschäftigt sich auch mit dem Einsatz von Warenwirtschaft und deren Prozesse, dabei greift er auf gesammelte Erfahrung von unterschiedlichen System von OpenERP, über Sage bis hin zu SAP zurück.
TYPO3 eigene Extbase Erweiterung beschleunigen
In diesem Blogbeitrag sind wir ja auf die allgemeine Performanceoptimierung von TYPO3 schon eingegangen. Jetzt will ich mal noch ein paar Tipps geben, wie eine selbst entwickelte Extension beschleunigt werden kann, die auf Extbase aufbaut.
Als Vorwort sollte noch angemerkt werden, dass der normale TYPO3-Cache ausreicht, wenn man nur Content hat, der für alle Besucher gleich ist, also keine Daten an der Session oder an Rechten von FeUser hängen. Aber für aufwändigere Extensions muss man Action im Plug-In als ‘non-cacheable’ eintragen, was dafür sorgt, dass diese Seiten wieder sehr langsam sind.
Falls noch nicht geschehen, kann man den Extbase Cache ab TYPO3 4.6 noch in den Memcache verlegen, dies tut man indem:
$TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['extbase_reflection'] = array( 'backend' =>; 't3lib_cache_backend_MemcachedBackend', 'options' =>; array( 'servers' =>; array('localhost:11211'), ) ); $TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['extbase_object'] = array( 'backend' =>; 't3lib_cache_backend_MemcachedBackend', 'options' =>; array( 'servers' =>; array('localhost:11211'), ) ); |
in die localconf.php eingefügt wird.
Des Weiteren sollte man in seinen Models genau darauf achten, dass überall Lazy-Loading für die Relation aktiviert ist. Dies wird durch die Annotationen mit “@lazy” ergänzt. Dies sieht dann so aus:
/** * Contact Informations * @lazy * @var Tx_Initos_Domain_Model_Contact */ protected $contact; |
Eine weitere Analyse der PHP Ausführung zeigt, dass die Anteile vom Code in der Regel so aufgeteilt sind:
- 40% Extbase Framework
- 20% eigene Extension
- 40% Fluid Template
Dies zeigt, dass die falsche Verwendung von Extbase oder Fluid schnell auf die Performance durchschlagen. Da hilft es nur, geschickt Funktionalität im Controller abzufangen bzw. sich eigene ViewHelper zu definieren um komplexe Schachtelungen von mit und zu unterbinden. Hier kommt man nicht um eine Code-Analyse herum.
Ein weiterer wichtiger Baustein ist, die eigene Extension um einen eigenen Cache zu erweitern. Hierfür gibt es schon eine Anleitung im TYPO3 Wiki.
Wenn Sie mit der Performance von TYPO3 nicht zufrieden sind, analysieren wir für Sie gerne das Problem und beheben es. Nehmen Sie einfach mit uns Kontakt auf.
Anmerkung:
Bei der Performance-Analyse zeigt sich, dass vor allem der Persistence Layer von Extbase sehr langsam ist. Aber wie wir schon erfahren haben, soll in der nächsten Version von Extbase noch mehr Performance rausgeholt werden.
Über Markus Schneider
Markus Schneider ist Experte für Shop- und ERP-Systeme. Er betreut mehrere eCommerce Kunden welche Magento oder Oxid eSales einsetzten. Dabei integriert er nicht nur CMS Systeme wie Joomla, TYPO3 oder WordPress in ihren Shop, sondern beschäftigt sich auch mit dem Einsatz von Warenwirtschaft und deren Prozesse, dabei greift er auf gesammelte Erfahrung von unterschiedlichen System von OpenERP, über Sage bis hin zu SAP zurück.




