Hallo ich schaue mir nach über 1,5 Jahren ERPNext wieder an.
Gibt es jemanden der schonmal probiert hat Shopware 6 an ERPNext anzubinden über die beiden API’s?
Kennt jemand ein Projekt das das schon vorhat?
2 Likes
Hallo, mich würde das auch interessieren, falls es noch jemanden in der Community gibt, der hierauf antworten könnte 
Auch bei uns aktuell ein Thema.
Das wäre auch für uns hochinteressant!
Hier auch Interesse!
Ein erster Ansatz wäre ja das man die “Bestellungen” importieren könnte.
Ich bin kein Entwickler und schon gar nicht Python aber ich werde mal schauen was man hinbekommt. Ich will schon lange mich mit Python beschäftigen und vielleicht ist das ein passender Ansatz es zu machen.
Für uns wäre eine Integration zwischen Shopware 6 und ERPNext zukünftig auch interessant.
Wir können gerne an der Entwicklung mitarbeiten.
Mit Shopware 6 kennen wir uns sehr gut aus, sowohl bei den Schnittstellen (Admin API, Storefront API) als auch bei der Entwicklung von Plugins / Apps.
In ERPNext haben wir uns bisher nur an kleineren PoCs probiert, allerdings entwickeln wir all unsere Microservices in Python (Flask) daher sollte ERPNext auch machbar sein.
Vielleicht würde ein einfaches Shopware-Plugin schon reichen, welches einen Webhook von ERPNext aufruft und die Daten (Kunde, Bestellung, Artikel…) weitergibt, sobald die Entität angelegt wurde oder einen bestimmten Status erreicht hat.
Mit den Flows und der Shopware Enterprise Edition quasi schon möglich.
Oder übersehe ich da etwas?
Gibt es reusable Code für solcherlei Connector?
Inkl. für Shopware 5, das ja bald endgültig EOL ist? => Opportunities?
Bei einer Datenbank mit 364 Tabellen (reales Shopware Beispiel) mit je X Feldern, oder alternativ die APIs mit ihren leicht abweichend zusammengestellten DB-Strukturen (inkl. Sub-Abfragen wie Detaillisten usw.), da wären schon Beschreibungen der Tabellen, Felder, Datenstrukturen/Entitäten und Abhängigkeiten hilfreich, oder sogar bloße Mapping-Beispiele.
Z.B. enthält ein Export einer Bestellung komplette Artikelbeschreibungen, Kunden- und Lieferantendaten, vmtl. weil es als Dokumentation der Willenserklärung des bestellenden Kunden eine Bedeutung hat.
Ein Datenwust, der sich gewaschen hat. Aus den Bestelldaten könnten man womöglich sogar die Geschichte von Änderungen der Artikelbeschreibungen rekonstruieren.
Tabellen ganz ohne Inhalte. Oder komplett nie genutzte Felder. => Was muss überhaupt übernommen werden?
Viel Arbeit, Erfahrung hilft, Einarbeitung braucht Zeit, alles irgendwie mühselig.
Kennt jemand Tools, die solche Arbeit unterstützen?
Z.B. Tools zur Datenbankexploration, also was man real in Tabellen und Feldern findet, aber übersichtlich und zeitschonend – nicht bloß sowas wie DBxyzAdmin?
Die Export Funktionalität könnte da schon manch eine Frage beantworten: Shopware 6 - Einstellungen - Import/Export
Und die API Reference für Orders: Detailed information about a Order resource. | Admin API
In Shopware 6 könnte man mit dem Flowbuilder im Paid-Plan auch Webhooks callen.
Über die API könnte man sicher auch den Order-Status mit ERPNext in Shopware updaten: Partially update information about a Order resource. | Admin API
1 Like
Danke für die Infos!
Die dev-Doku für Shopware 5 und 6 nutze ich schon.
Die Webhooks kannte ich noch nicht. Was machen die, wenn das Zielsystem mal nicht erreichbar ist: Retry / Abort / Fehlermeldung – geht die Bestellung dann erstmal unter, bis man im SW-Backend checkt?
Ich bin ein Freund der APIs. Erster Zugriff (Auth) und genaues Protokoll (Entity-Namen, Filter, Order, …) sind manchmal etwas fummelig, aber ich komme schon an alles ran, was ich will.
Mein momentanes Projekt ist, eingehende (über SW5) Bestellungen mit einem eigenen Tool auszulesen (cron oder/und auf Anfrage), zu speichern und bei ERPnext als eingehenden Auftrag einzuspielen.
Damit kann dann das ERP-System mit realen und aktuellen Daten (parallel zum aktuellen System) von den Mitarbeitern getestet (und konfiguriert) werden.
Da eine abgerufene Bestellung über die SW5-API ziemlich geschwätzig daherkommt, könnte man gleichzeitig nach und nach die Lagerdaten (Warehouses, Bins, Artikel, Preise, Kundenkategorie, Bestand, Lieferant) sammeln. Ggf. sogar verschiedene Analysen fahren.
Als Start so eines Vorgehens müssten an sich also erstmal nur ein API-Passwort und die IPs konfiguriert werden. – Wenn so ein Tool intelligent mit den Daten umgeht, könnte das vielleicht viele Leute interessieren und die Hürde für eine ERPnext-Installation senken.
Wenn das funktioniert, dann wäre praktisch fast eine komplette Auftragsverarbeitung und sozusagen eine Art sanfte Übernahme ganzer Systemteile möglich. (Man könnte sie sogar parallel laufen lassen und die Ergebnisse automatisch vergleichen, zur Bestätigung der Richtigkeit der Verfahren.)
Dann fehlen aber noch die Einbindungen der Auslieferungsdienste (DHL / Spedition), und die Anbindung von Buchhaltung, idealerweise auch Bank, wg. Vorkassen und SEPA-Lastschriften.
Was mir bei ERPnext schnell aufgefallen ist, sind die teilweise schlechten Übersetzungen. Der aktuelle Stand der Methodik würde mich mal interessieren. Forum-Posts dazu habe ich schon gesehen, aber keine wirklich aktuellen.
Übersetzung ohne Kontextberücksichtigung kann nicht gut funktionieren, und das sieht man sofort (vielleicht ist das derzeit sogar ein oder gar der Show-Stopper für viele Interessenten). Übersetzen ist immer direkt damit verbunden, Mehrdeutigkeiten aufzulösen (disambiguation), was maschinell oft misslingt.
Ich vermute, dass jetzt vor der Konferenz in Mumbai (bzw. der offiziellen Freigabe von Version 15) noch eifrig einiges poliert wird und danach vielleicht der aktuelle Stand sichtbar(er) wird?
Ansonsten würde mich interessieren, ob unsere vorhandenen Picker (d.h. kleine Geräte am Unterarm mit den abzuarbeitenden Picklisten, die im Lager verwendet werden zum Packen der Sendungen, läuft über WLAN) weiterverwendet werden können, die laufen derzeit über ein SW-Plugin (“Pickware ERP”).
Gibt es dazu Erfahrungen?
Alternativen?
Oder müsste man sich selbst eine kleine Web-App machen, die die Picker ersetzen können? Oder einen eigenen Connector zur direkten Weiternutzung der Geräte mit ERPnext?
Barcode scannen können die auch, wird in der Praxis aber nicht genutzt, außer für Umlageraufträge.
Als Picker würde ein einfaches Smartphone im Prinzip schon reichen, und eine Barcode-API gibt es bei denen ja auch längst. Rugged => Baustellen-Smartphone.
Hi Peer,
ist da mit ERPNext und Shopware 6 schon was weitergegangen?
Wer hat da schon Erfahrungen gesammelt?
Viele Grüße
Udo
Es geht voran, aber so eine ERP-Einführung usw. ist nicht ganz ohne.
Es gibt viele unterschiedliche Möglichkeiten je nach Setup der jeweiligen IT und der gewünschten Datenströme.
Um es mal auf die Anbindung runterzubrechen:
- Eine Anbindung über die Shopware-API ist relativ leicht herzustellen: API-Key für einen geeigneten Benutzer in Shopware einrichten und dann von ERPNext über ein Skript (kann ein Server-Script sein) darauf zugreifen.
- Hiermit kann man dann eingehende Bestellungen abrufen, Artikel u.a. hochladen und somit den Shop als Anhängsel/Außenstelle vom ERPNext System betreiben. Die SW6 API ist gut dokumentiert auf Seiten von Shopware. Mit der ERPNext API kann man kreative Dinge machen, die für einen Entwickler cool sind. Mit bench kommt man auf einer Dev-Instanz sehr leicht an die Datenbank ran und kann alles bequem sozusagen von innen erkunden, und wenn man sich auch auf ERPNext einen API-Zugang einrichtet, hat man eine zweite bequeme Möglichkeit, mit den ERPNext Daten erkundend (z.B. durch den Browser oder auch eigene Skripte oder eine Flask-Instanz als Bedienoberfläche/C&C-Instanz) umzugehen. Man kann so z.B. auch (mit einem kurzen Server-Script) die ERPNext API ansprechen und von SW6 abgerufene Daten einfach durchreichen, so kann man bequem entwickeln und schnell sehen, wie alles zusammenpasst.
Damit kommt man schon weit genug, dass man Erfolge sieht und es Spaß macht, damit zu entwickeln. - Das Mapping der Felder ist etwas fummelig, weil man die Datenstrukturen in SW6 und ERPNext gut genug verstehen muss, damit dann alles genau passt und wie gewünscht läuft. An sich alles nichts Besonderes, aber eine Menge Holz, da muss man nun mal durch. Was man mappen will bzw. muss hängt natürlich von der gewünschten Nutzung des Shop sowie des ERPNext-Systems ab (d.h. genutzte Funktionalitäten, erforderliche Datenfelder, Pflichtinformationen in dieser immer mehr Pflichtdigitalisierten Welt).
- Eine Dosis Robustheit, Fehler abfangen, Retries usw. gehört natürlich auch dazu, wie bei jedem solchen Projekt. Dazu muss man sich halt in ERPNext einarbeiten, was je nach Vorkenntnissen und erforderlicher Entwicklungstiefe unterschiedlich schnell gehen kann.
- Aus den PoCs dann eine eigene App (im Sinne von Frappeframework-App) zur bequemen Integration auch über Updates hinweg machen, wäre je nach Setup wohl der nächste sinnvolle Schritt, ggf. aber unnötig, wenn man die gewünschten Funktionalitäten schon mit Server-Scripten erzielen kann, was von den gewünschten Prozessen und Funktionalitätsumfang abhängt.
Es scheint schon Leute zu geben, die Lösungen haben, aber es sieht so aus, als hielten sich alle sehr bedeckt, was sowas angeht, insbesondere in der deutsch(sprachig)en (also DACH-) Community. Ich habe mich schon manches Mal gewundert und verstehe die Situation nicht wirklich, kann mir aber auch viele legitime und/oder nachvollziehbare Gründe dafür vorstellen, je nach Situation der jeweiligen Protagonisten.
Die Lernkurve für ERPNext ist nicht ganz ohne, also braucht es eine gewisse persönliche Investition (d.h. Lernen, aber es gibt auch einiges an Material: die Dokumentation, den Sourcecode, die Videos von frappeschool und BuildWithHussain).
Allerdings hat das System auch echt was, mir ist damit noch nicht langweilig geworden, und je mehr man entdeckt, desto mehr staunt und schätzt man es.
Das Frappe-Team selbst beeindruckt durch vielerlei menschliche Qualitäten und seine gelebten Werte (s. Frappe Blog, Frappeverse Konferenz, insbesondere vor Ort).
2 Likes