Die Windeit-Software GmbH wird in der nächsten Zeit eine neue Version des Automatic XML-Export Shopware-Plugins veröffentlichen. Es hat nun die Version 2.0.0 erreicht und kann jetzt selbstständig per SCP XML-Dateien auf einen anderen Server laden.
Dafür muss die php-ssh2 Extension installiert sein, was unter Ubuntu sehr einfach geht:
sudo apt-get install php7.2-ssh2
Auf dem Ziel Server muss der Openssh-Server installiert sein.
Danach müssen nur noch die Verbindungsdaten eingegeben werden und der SCP-Upload aktiviert werden.
Dropshipping mit Shopware ist ja nicht immer ganz einfach, wenn man nicht direkt alle Produkte von einem Vendor bezieht. Wenn man nur einen für alles hat ist alles ganz einfach weil man direkt, die gesamte Bestellung an diesen senden kann. Hat man nur einen, aber der auch nur bestimmte Produkte liefert geht es jetzt auch bzw. der erste Testdurchlauf für diesen Use-Case lief sauber durch.
Für Multi-Vendor Orders muss man eine Bestellung in mehrere kleine pro Distributor/Vendor/Lieferant aufteilen. Wenn man nur einmal alle 2h oder so die Bestellungen übermittelt und die Waren an sich selbst liefern lassen möchte, kann man diese sogar noch mal vorher wieder mergen, weil dann Lieferant und Empfänger bei allen Bestellungen immer gleich sind. Aber das ist schon ein Ausnahmefall.
Natürlich kann jeder Vendor einen eigenen Endpoint für die Bestellungen bereitstellen. Entweder per Email, Datei-Upload oder REST-API können die Daten in immer unterschiedlichen XML-Formaten übertragen werden. Das macht dann mehr Probleme.
Mein Shopware-Plugin kann nun aber immerhin verschiedene Vendor/Hersteller bei diesem Splitting ignorieren. Damit ist es nun möglich, wenn man nur einen Vendor für bestimmte Produkte hat, diesen auch mit dem Plugin die Bestellungen automatisch zu zustellen. Bei mehr als einem muss mein Plugin noch leider passen.
Das Plugin kann also momentan folgende Fälle komplett abdecken:
- Übertragung von allen Bestellungen in ein ERP-System oder ähnliches
- Übertragung von allen Bestellungen an einen Vendor (mit oder ohne Dropshipping)
- Übertragung von bestimmten Bestellungen oder auch nur Teil-Bestellungen an einen Vendor (mit oder ohne Dropshipping)
ob es sich um eine einfache Order bei dem Vendor handelt oder um Dropshipping, muss man sich teilweise im XSLT für das Order-XML selbst zusammen bauen (oder mich damit beauftragen). Für die openTRANS-Formate versuche ich momentan eine Lösung zu entwickeln, die dann z.B. die Lieferadresse automatisch nach Konfiguration mit den eigenen Adress- oder den Kunden-Adressdaten befüllt.
Für den Export zulassen
An einer vollständigen Lösung, um beliebig viele Vendor mit jeweils eigenen Übertragungsarten und XML-Formaten anzubinden, arbeite ich auch nebenbei. Gerne würde ich eine Shop-System unabhängige Lösung bauen.. leider fehlt dafür aber Zeit und Geld... bzw. hauptsächlich Geld.. weil wenn man das Geld hat, hat man auch die Zeit.
Bis jetzt konnte das Plugin neben dem Shopware-Model als XML auch openTRANS 1.0 und 2.1 exportieren. Das war aber rein in PHP implementiert. Zusätzlich konnte man eigene XML-Formate über XSLT ausgeben.
Nun werde ich nach und nach den PHP Anteil reduzieren und auch openTRANS in XSLT implementieren. Erste Schritte sind getan.
Ich rechne damit dass ich so in 2 Wochen, dann alles so weit auf XSLT migriert haben werde.
Nächstes Jahr werde ich wirklich mal das Adventskalender-Projekt nach vorne bringen. Mit Shopware Emotion-Element und so. Erstmal stehen jetzt für Ende diesen und Anfang nächsten Jahres folgende Dinge auf meiner Todo-Liste:
- Shopware-Plugin: Warnung bei unnatürlichen Preisänderungen
- Shopware-Plugin: Globale Smarty-Variablen für Kundendaten
- Shopware-Plugin: XML-Order Export für ERP-Integration
Dann kommt noch die Planung/Konzeptionierung für ein Projekt mit RFID Technik in Kombination mit vielleicht Shopware.
Und auch SMS2X soll noch mal verbessert werden, so dass es vielleicht mal zum Einsatz kommen kann.
Auch Zeitmessung ab von RFID wird mich wohl noch mal beschäftigen.
Mein 2. Shopware Plugin (also.. das 2. das in den Community-Store soll..) ist jetzt so gut wie fertig. Es fehlen nur noch ein paar Test und Dokumentation.
Das Plugin stellt einen Export der Orders bereit. Im Gegensatz zu den eingebauten Export hat man hier ein paar mehr Möglichkeiten das Aufgabeformat (so lange es XML ist) anzupassen und alles zu automatisieren.
Features:
- XML Formate: nativ, openTRANS 1.0 (eher experimentell), openTRANS 2.1
- automatischer Export direkt nach der Bestellung als Datei in ein lokales Verzeichnis
- automatischer Export als XML in einem JSON Container per Push (getestet mit einem Wildfly 11 und einem RestEasy Endpoint)
- Export bestimmter Orders in ein Verzeichnis per CLI
- Abfrage über die REST-API
- REST-API: Als XML in einem JSON-Container (Liste und einzelnd)
- REST-API: Als XML (einzelnd)
- XSLT-TRansformation, damit ist man im Ausgabeformat nicht eingeschränkt (egal ob mit Automatisch, CLI oder REST-API)
- Für die openTRANS-Formate gibt es verschiedene Einstellung für Buyer-Definition und die Party-Ids
Es ist also ein Plugin was rein auf die Integration von Shopware in vorhandene Bestell-Prozesse mit ERP-Systemen wie SAP ausgelegt ist. Arbeit wirklich gut mit Java Application Servern wie Wirldfly zusammen und auch zum Debuggen ist es sehr praktisch die Bestellungen als XML zu dumpen.
Ein relativ alter Fork des Plugin wird bei https://www.notebookswieneu.de genutzt, um die Bestellungen als openTRANS 1.0 an das SAP-System
zu übermitteln.
Diese Woche werden die letzten Dinge erledigt und dann wird es hoffentlich Anfang nächster Woche für den Store eingereicht.
Oft hat man das Problem, dass man verschiedene Einheiten verarbeiten muss und nicht alle sich an Standardeinheiten (SI) halten. Mag es daran liegen, dass die Person historisch gewachsene Einheiten wie Liter oder Pfund verwendet oder auch einfach daran, dass diese Person Amerikaner ist. Natürlich gibt es genug Frameworks, die einen helfen mit allen möglichen Einheiten klar zu kommen, aber es ist an sich gar nicht schwer sich so etwas selber zu schreiben.
Man muss nur die Basis-Einheit (SI) bestimmen und alle anderen Einheiten sich darauf beziehen lassen. Ein gutes Beispiel ist hier Inch/Zoll um das ganze zu demonstrieren.
Wir befinden uns in der Gruppe der Einheiten zur Bestimmung von Längen. Die Basiseinheit ist laut SI der Meter. Wir bauen uns jetzt 3 Einheiten Entitäten (die man am Besten in einer Datenbank anlegen sollte).
Wie kommen wir jetzt ganz einfach von Inch auf Zentimeter? Wir nehmen den Inch-Wert und multiplizieren ihn mit dem Conversionfactor. Dann haben wir bei 1 Inch einen Wert von 0,0254 Meter. Nun nehmen wir uns unseren Zentimeter und teilen den Meter-Wert durch den Conversionfactor des Zentimeter. 0,0254 / 0.01 = 2.54 damit haben wir Inch in Centimeter umgerechnet. Einfacher Dreisatz. Wenn wir nun Einheitenwerte zu irgendwas speichern wollen, ist es eine gute Idee, diese vor dem Speichern immer auf die Basis-Einheit umzurechnen.
Das vereinfacht die Ausgabe, weil eine Methode sich so direkt die Einheit bilden kann, die sie gerne hätte.
In dem Zusammenhang ist auch eine Methode gut, die eine ideale Maßeinheit für einen Wert bestimmt. Wenn wir nun 0,001cm haben sollte diese Methode uns sagen können, dass die Repräsentation 1m für den Benutzer sehr viel einfacher zu lesen ist und uns den Wert und die Einheit liefern können.
Auch praktisch ist, dass man so dem Benutzer es überlassen kann in welcher Einheit er Ausgaben gerne sehen würde. Würden wir uns im Bereich der Flächeneinheiten befinden und die Fernsehsendung Galileo über die Größe der Flächen von bestimmten Dingen berichten wollen, können wir für sie direkt die Einheit "Fußballfeld" definieren und sie ihnen als Ausgabemöglichkeit anbieten.
Weitere Gedanken zu Einheiten/Units
Bei Bestellsystemen bereitet oft die Pseudo-Einheit "Stück" Probleme. Aber hier muss man sich einfach von der Vorstellung von Stück als eigene Einheit trennen. Maßeinheiten werden gemessen.. Stück werden einfach gezählt. Am Ende wird alles auf eine Verpackungseinheit herunter gebrochen und diese ist alleinstehend "1 Stück". Wenn ich 5L Wasser bestellen möchte ist es weiterhin sehr wichtig wie dieses Verpackt ist. 5x 1L oder 10x 0,5L. Verpackungseinheiten können auch rein virtuell sein. 100L = 100x 1L wobei nicht gesagt ist, dass dieses "verpackt" sein muss und nicht einfach direkt von einem Tank in einen anderen umgefüllt werden kann. Also.. Stück ist keine Maßeinheit sondern existiert parallel dazu um beschreibt nur eine Portionierung der in der Maßeinheit gemessenen Sache, die so geliefert werden kann.
Wo ist der Unterschied zwischen einer 1L Flasche Wasser und einem Stuhl? Beides ist "1 Stück" wobei man bei der Flasche den Inhalt in eine Maßeinheit fassen kann und bei einem Stuhl nicht. Ok.. man könnte.. es ergibt aber einfach keinen Sinn sich 25kg Stuhl zu bestellen.
Für Produktionssysteme ist der obige Ansatz sogar ohne solche Überlegungen einfach direkt umsetzbar und funktioniert sehr gut.
Blog-entries by search-pattern/Tags:
Möchtest Du AdSense-Werbung erlauben und mir damit helfen die laufenden Kosten des Blogs tragen zu können?
bezahlt von 
Blog: Blog-entries by search-pattern/Tags:
