2012-07-02 6 views
6

Wir sind ein modernes Unternehmen mit moderner Technologie wie XML-Schnittstellen, aber viele unserer Kunden wollen zum Beispiel elektronische Rechnungen von uns in einem EDIFACT-Format wie D96A.Gibt es eine wirklich einfache Möglichkeit, EDIFACT zum Beispiel D96A zu verarbeiten?

Nein, wir können bereits vorhandene Bibliotheken nicht verwenden, da sie nicht in der C/AL-Programmiersprache geschrieben sind, die unsere Navision-Software verwendet.

Also, um es in C/AL zu analysieren, muss ich seine Spezifikation verstehen. Aber es sieht extrem schwierig und kompliziert aus.

So kann mir jemand einen Überblick geben, wie man D96A interpretiert und wie man es analysiert?

Antwort

0

Ich weiß, dass diese Frage älter ist, aber ich musste für ein Kundenprojekt ein wenig recherchieren. Es gibt einige gute Add-ons für Dynamics NAV. Schauen Sie sich zum Beispiel Anveo EDI Connect an und implementieren Sie den Import und Export von EDIFACT (und vielen weiteren Formaten) direkt im NAV. Andere Lösungen sind von BMI, Yaveon, Lanham und einigen anderen Unternehmen erhältlich. Es gibt auch mehrere Dienstanbieter, die die Daten verarbeiten und Sie stimmen ihnen in einer einfachen XML- oder dateibasierten Struktur zu.

2

Ich schlage vor, durch GitHub oder SourceForge Repos suchen und durchlesen. Eine schnelle Suche mit Stichwörtern: + EDIFACT + D96A zur Verfügung gestellt mehrere Bibliotheken zur Auswahl. In der Tat ist dies für Ihren Fall vielversprechend aussieht:

  • Bots Open-Source-edi Übersetzer, http://sourceforge.net/projects/bots/. Die Beschreibung des Projekts sagt, es ist ein vollständiger Übersetzer für EDI (Electronic Data Interchange).

Sie können immer bewerten und überprüfen Oracle B2B 11g, die einen Teil der Oracle SOA Suite 11gR1 ist: - http://www.oracle.com/technetwork/middleware/soasuite/downloads/downloads-085394.html#11g. Es hat UN/EDIFACT OTD-Bibliothek, die Sie zumindest für die Analyse verwenden könnten.

Im Allgemeinen ist es das Beste, die vorhandene Bibliothek zu übernehmen und entweder in NAV zu portieren oder über die externe Schnittstelle zu verwenden, über die Daten in Ihre NAV-Datenbank fließen. Wenn Sie in der Lage sind, .NET-Code aufzurufen, sollte eine Vielzahl vorhandener Bibliotheken vorhanden sein, und Sie können einfach durch den Verweis auf die Assembly dorthin gelangen. Da ich mit der NAV-Entwicklung nicht vertraut bin, aber irgendeine Art von REST/JSON verwenden sollte, was auch immer Ihr Mechanismus zum Aufruf von Datentransferobjekten sein sollte - wo Ihre Komponente B die schwere Arbeit macht und Ihre NAV-Komponente geparste UN/EDIFACT-Nachrichten durch Ihre XML-Schnittstelle.

Es gab eine andere ähnliche Frage und paar Antworten, die auch Ihnen passen könnten: Is there any good open source EDIFACT parser in Java?.

Prost!

9

Parsing EDIFACT ist eigentlich nicht so kompliziert. Split an den Sytax-Zeichen: zuerst bei ', um die Segmente zu erhalten, als bei +, um Datenelemente dieser Segmente zu erhalten und bei :, um die einzelnen Komponenten zu erhalten. Sie müssen natürlich auf entkommene Trennzeichen achten. Die hier verwendeten Zeichen sind nur die Voreinstellung, sie können am Anfang der Nachricht durch das optionale UNA-Segment geändert werden. Tatsächlich gibt die wikipedia article auf EDIFACT eine ziemlich gute (aber kurze) Einführung dazu. Und das Format ist mit Details auf der UN's UNECE site dokumentiert (ja, das ist viel und schwer zu lesen).

Der knifflige Teil ist, die Informationen aus diesem und in Ihre Anwendung zu bekommen (und zu überprüfen, dass es gültig ist, lassen Sie in Ruhe gute Fehlermeldungen erstellen). Wenn du wirklich vorhast, einen kompletten Parser aus allem für jede Sprache zu schreiben, dann: Nein, es gibt keinen einfachen Weg, dies zu tun. Es gibt auch keine andere flexible Datenrepräsentation. Das ist eine schwierige Aufgabe und wird immer sein.

Aber hier ist eine Idee: Wenn Sie in XML so viel (oder jede andere "moderne Technologie" wie Sie es nennen möchten ...). Es wäre eine relativ einfache Aufgabe, ein Programm zu schreiben, das EDIFACT-Nachrichten in ein einheitliches XML-EDIFACT-Format konvertiert (was ziemlich schrecklich ist und mich höchstwahrscheinlich ausflippen würde). Sie können jedes EDIFACT-Segment in ein XML-Tag, vielleicht wie folgt konvertieren:

ERC+A7V:1:AMD' 
IFT+3+NO MORE FLIGHTS' 

In XML:

<segment qualifier="ERC"> 
    <element> 
     <component>A7V</component> 
     <component>1</component> 
     <component>AMD<component> 
    </element> 
</segment> 
<segment qualifier="IFT"> 
    <element> 
     <component>3</component> 
    </element> 
    <element> 
     <component>NO MORE FLIGHTS</component> 
    </element> 
</segment> 

Dann können Sie die Kraft Ihrer XML-Tools und Bibliotheken auf sie entfesseln zu validieren/auswerten es.

Sie könnten auch tun es spezifischere, wie folgt aus:

<segment_ERC> 
    <element> 
     <component>A7V</component> 
     <component>1</component> 
     <component>AMD<component> 
    </element> 
</segment_ERC> 
<segment_IFT> 
    <element> 
     <component>3</component> 
    </element> 
    <element> 
     <component>NO MORE FLIGHTS</component> 
    </element> 
</segment_IFT> 

Dies könnte einfacher Validierung über XSD. Natürlich können Sie mit dieser Konversation so genau gehen, wie Sie wollen, aber Sie würden früher oder später zu einem Punkt kommen, an dem Sie Informationen über die Struktur Ihrer gerade geparsten Nachricht in den Converter schreiben müssten (da es nicht trivial ist) weiß, welche Segmente in andere Segmente geschachtelt sind, die sie gruppieren.Es gibt nicht nur UNG, und so, sondern auch einige Segmentgruppen, die Sie nicht direkt sehen.

Trotzdem müssen Sie nach den EDIFACT-Handbüchern, die Sie als Dokumentation bekommen sollten, spezielle Auswertungsprogramme/Schemata/whatevers für die Nachrichten erstellen, die Sie erhalten.

Verwandte Themen