Hallo,

unsere B2B Kunden Fragen immer wieder nach einer EDI Anbindung. Wir nutzen unser eigenes Warenwirtschaftssystem und sind programmiertechnisch durch unsere eigenen Entwickler sehr flexibel. Ich möchte also gern eine EDI Anbindung programmieren lassen. Das Problem ist, dass unsere Programmierer keine Ahnung von EDI haben. Ich suche also einen Dienstleister der uns entsprechend beraten kann.

Könnt ihr hier jemanden empfehlen? Die meisten EDI Anbieter wollen deren Cloud Lösung verkaufen und verlangen dafür Einrichtungsgebühren von ca. 1000€ und monatlich kommen dann noch ca. 70€ PRO KUNDEN dazu das heißt wenn wir 10 Kunden anbinden sind wir bei monatlichen 700€ was ich Wahnsinn finde... da wir eh unseren eigenen root Server sowie System und Programmierer haben, möchte ich das gern selbst in die Hand nehmen was sicherlich auch kein Problem sein sollte, wenn wir die entsprechende Beratung erhalten, wofür ich auch gern bereit bin zu zahlen.

Ich hoffe ihr könnt mir etwas empfehlen?

Vielen Dank!

Wenn Ihr ja sowieso eigene Programmierer habt würde ich eher in die Richtung gehen, dass die das machen, eventuell schickt man die auf eine Fortbildung zum Thema API/Netzwerkentwicklung, bzw. ich bin der Meinung wer eine Warenwirtschaft programmieren kann, der kann sich sowas auch schnell selbst beibringen, ist ja nur eine Weiterentwicklung von dem was schon da ist (Datenbank,Verwaltungssytem,etc)

EDI ist total simpel. Am Ende ist es nicht anders als eine CSV Liste. Der einzige Unterschied ist, dass die Felder jeweils eine feste Zeichenanzahl haben.

Beispiel: (Auszug):

Ich denke mit

Programmierer keine Ahnung von EDI haben.

ist gemeint, dass die kein PHP/Linux Server managment/Firewalls/Security/etc. können. Der Beispielcode ist ja das was zum schluss oben drauf kommt, das kann jeder.

Baam hat geschrieben: ↑6. Okt 2022 12:41 EDI ist total simpel.

Kommt drauf an.
Electronic Data Interchange ist erstmal nur ein allgemeiner Oberbegriff. Austauschformate und Protokolle gibt es wie Sand am Meer.

https://de.wikipedia.org/wiki/Elektroni ... nstandards

Unsere Programmierer sind Profis in Sachen PHP, APIs Datenbanken usw. Aber die wissen nicht was EDI ist und wie die Daten benötigt werden bzw. Wie man mit unseren Kunden connected?

Ein Kunde hat uns zb. Folgendes geschrieben. Wir brauchen hier quasi einen genauen Leitfaden und am besten Beispiele wie die Daten auszusehen haben.

Nachstehend erhalten Sie unsere Informationen für die Anbindung:
- Warenwirtschaftssystem: HILTES 4000

- GLN:xxxxx

- Unsere E-Mail Adresse für EDI Daten: xxxxx

- Unser Verzeichnistyp: D96A

- Nachrichtenarten: PRICAT, DESADV, SLSRPT, ORDERS.



Wenn die Anbindung bereit ist, benötigen wir die folgenden Angaben von Ihnen:

- nutzen Sie Verzeichnistyp D.93A oder D.96A

- über welche E-Mail-Adresse können Sie EDI-Nachrichten von uns empfangen

- welchen Warengruppenschlüssel nutzen Sie

- Ihre GLN

Das gewünschte Datenformat sollte dann schon der Endkunde liefern und eine entsprechende Dokumentation, warum sollen eure Entwickler da 'raten' was das beste ist. Aber das sieht mir nach einem Spezialwunsch aus, vor allem EDI per E-Mail?? 90er Jahre? Für sowas stellt man eine richtige API hin, oder ein abgesichertes Webinterface mit Import/Export funktion.

Gibt viele bekannte Formate für solche Produktdatenanbindungen, einfach das populärste nehmen und eueren Kunden sagen, hier habt ihr, viel Spass. Wenn da jeder was anderes will, ist das unwirtschaftlich, bzw. kostet dann halt extra.

VIP-Kleider hat geschrieben: ↑6. Okt 2022 13:02
- Nachrichtenarten: PRICAT, DESADV, SLSRPT, ORDERS.

Sieht mir danach aus, gibt es entsprechend im Netz Dokumentation zu:
https://www.seeburger.com/info/what-is-edifact/

icstore hat geschrieben: ↑6. Okt 2022 13:06 Das gewünschte Datenformat sollte dann schon der Endkunde liefern und eine entsprechende Dokumentation, warum sollen eure Entwickler da 'raten' was das beste ist. Aber das sieht mir nach einem Spezialwunsch aus, vor allem EDI per E-Mail?? 90er Jahre? Für sowas stellt man eine richtige API hin, oder ein abgesichertes Webinterface mit Import/Export funktion.

Gibt viele bekannte Formate für solche Produktdatenanbindungen, einfach das populärste nehmen und eueren Kunden sagen, hier habt ihr, viel Spass. Wenn da jeder was anderes will, ist das unwirtschaftlich, bzw. kostet dann halt extra.

Genau das ist leider das Problem. Wir müssen uns jedoch nach unseren Kunden richten und das entsprechend bereitstellen was für unsere Programmierer auch kein Problem ist, sie benötigen nur genaue Infos, am besten Beispiele und eine Dokumentation. Wo können wir sowas erhalten?

Hier am Beispiel EDIFACT ist die offizielle Dokumentation kostenpflichtig (ISO Standard): https://www.iso.org/standard/82813.html

Sollte aber eigentlich wie gesagt, die Verantwortung des Endkundens sein, seine Wünsche bereitzustellen. Als Softwareentwickler würde ich einen derart unspezifischen Auftrag ablehnen, das gibt dann später nur Ärger wenn etwas nicht passt, weil es nicht konkret definiert wurde.

Danke. Es sieht wohl wirklich nach EDIFACT aus. Somit haben wir doch von dem Kunden alle Infos die wir brauchen oder? Wofür wird eigentlich die GLN benötigt und wie genau läuft die EDI Kommunikation per email ab? Gibt es dazu auch Dokumentationen? Senden wir denen die Daten einfach als Anhang oder im email Text?

MrChad hat was ganz Wichtiges erwähnt: EDI ist faktisch ja nichts anderes als der Überbegriff, dass Daten in irgendeiner Art und Weise elektronisch ausgetauscht werden.

Und das erklärt auch, warum es möglicherweise bei 10 Lieferanten dann auch verschiedene a) Datenformate und b) Übertragungsmethoden gibt, auch wenn es durchaus Standards gibt, wenn es z.B. um das Absetzen von Lieferantenbestellungen und die Rückmeldung der Verfügbarkeit bzw. der voraussichtlichen Liefertermine geht. Dem kann, muss aber nicht so sein, denn wir haben beispielsweise einen Kunden, da meint 'EDI' nichts anderes, als dass automatisch eine E-Mail mit einer CSV-Datei an den Lieferanten gesendet wird und dessen Warenwirtschaft liest sie ein - fertig.
Was Kosten bzw. Gebühren betrifft: Wir selbst (also Descartes, unser Mutterunternehmen) gehören tatsächlich zu den weltweit größten Anbietern von EDI-Dienstleistungen und eine unserer Aufgaben ist es, im sog. Clearing-Center Daten zu konvertieren und zu übertragen, damit eben nicht für jeden einzelnen Lieferanten ggf. individuelle Schnittstellen entwickelt werden müssen. Und das kann sich dann eben doch recht schnell rechnen, wenn der Lieferant bessere Konditionen anbietet oder/und nun die Verfügbarkeit automatisch an die WaWi zurückmeldet, um dann schneller die richtigen Entscheidungen zu treffen. Anders und etwas frech gesagt: Wenn für euch als Händler keinerlei - also wirklich absolut keine - Vorteile entstehen würden, wenn _ihr_ euch via EDI an die Lieferanten anbindet, dann könnte man auch weiterhin seine Bestellungen handschriftlich per Brieftaube an die Hersteller und Großhändler schicken.

Demnach muss es als in irgendeiner Art und Weise Vorteile geben, die entweder die Kosten von Anbietern rechtfertigen oder die Entwicklungsaufwände sowie ggf. die Wartung.

Was die Dokumentationen betrifft: Ab und zu bekommen auch wir bei pixi solche Anfragen und dann wird 'nicht selten ne aussagelose Liste der EDI-Messaging-Typen zugesendet, in der steht 'wir brauchen DESADV' und damit soll's dann gewesen sein. Ja, es gibt verschiedene Standards, wie eingangs erwähnt, die besagen, WAS in dem Datensatz steht (ist das z.B. 'ne Endkundenbestellung, ist das eine Lieferantenbestellung, ist das eine Auftragsbestätigung des Lieferanten etc.) und oftmals ist damit der sog. EDIFACT-Standard gemeint - aber eben nicht immer. Entsprechend empfehle ich: Lasst euch ganz konkrete Beispiel-Dateien schicken mit
a) Zweck der Datei
b) exakter Aufschlüsselung der einzelnen Datenfelder und
c) Markierung, welche der Felder und warum sie ggf. Pflicht sind.
Und dann klärt, _wie_ die Daten übermittelt werden sollen, ob z.B. tatsächlich einfach nur per E-Mail und ggf. in spezifischen Formaten in der E-Mail und/oder mit Dateianhang, ob per API oder klassisch via FTP.
Habt ihr alle Dokumente zusammen, sollte es dann auch ohne uns Profis wie Descartes recht problemlos möglich sein, die einzelnen Schnittstellen zu bauen.


Und lasst euch nicht mit 'wir brauchen ORDERS und liefern euch ORDRSP, PRICAT und INVOIC zurück" abspeisen, denn dann wisst ihr maximal, was für Daten in alle Richtungen geschickt werden, aber nicht, wie das Datenformat aussehen MUSS.

Ist also machbar.
Viel Erfolg euch!

Chris

VIP-Kleider hat geschrieben: ↑6. Okt 2022 13:40 Danke. Es sieht wohl wirklich nach EDIFACT aus. Somit haben wir doch von dem Kunden alle Infos die wir brauchen oder? Wofür wird eigentlich die GLN benötigt und wie genau läuft die EDI Kommunikation per email ab? Gibt es dazu auch Dokumentationen? Senden wir denen die Daten einfach als Anhang oder im email Text?

Am wichtigsten meiner Meinung nach Beispieldaten, damit die Entwickler wissen wie genau es aussehen soll. Der Standard beschreibt nur allgemein das Datenformat, in der Praxis gibt es oft abweichungen und irgendwelche Spezialfälle.

Wenn Ihr das per Mail senden wollt, würde ich das Intuitiv in den Email-Body packen, am anderen Ende sitzt dann ein Service dass die Inbox nach neuen Nachrichten scannt. Zum Versand habe ich das hier im Netz gefunden: https://www.example-code.com/csharp/smt ... iEmail.asp

EDIFACT ist ja nur ein Datenformat-Standard. Wie die Daten übertragen werden ist euch/dem User überlassen.

GLN ist vom GS1, eine Art Firmennummer: https://edicomgroup.com/learning-center/gs1/gln


Wenn jeder User ein anderes Format will, würde ich aber tatsächlich überlegen, ob so ein Cloud-Anbieter nicht sinvoller ist, die 70 EUR/Monat sollen dann die B2B Kunden zahlen für Ihre Extrawurst, ist doch jetzt kein Weltbrechender Betrag, ihr habt den Vorteil dass ihr nicht von null an 10 verschieden Formate programmieren und supporten müsst.