EDIFACT translator

[webcat]

Hi,

Has anyone ever come accross EDIFACT? It is a UN standard for sending and receiving data electronically.

I need to have an EDIFACT translator in my DB, and I haven't found any Mac software that does this.

The EU publish a book on the regulations, but before I resort to writing something of that scale in FM, I was wondering if anyone else had done it already, or even if anyone had a vague idea of what it is. I had never heard of it until a couple of days ago, and I have found some helpful web sites on defining exactly what the EDIFACT thing is and what it means to me, but not the actual specs or a way of translating EDIFACT to work with my DB.

Any info would be gratefully received.

Thanks

[webcat]

I guess no one has ever heard of this then!

well, I'll let you know if I come up with anything. This could be an important thing if you are dealing with other companies from your DB

[mon]

I am searching for such a thing, too. There must be a solution using FMP XML capabilities. Maybe it is a matter of creating a set of proper fields and then format in flat file format.

[jcavard]

this post is almost 3 years old haha

[mon]

My! That is so constructive!

[jcavard]

Well, thank you.

[Lee Smith]

[color:blue] Hello mon, and welcome to the Forum

Please update your profile to reflect your OS, Version of FileMaker, and platform you are using. This can be helpful to us when we are trying to provide solutions.

Next, [color:blue] jcavard has a point. A tread this old without an update by the poster, or a response by the members, usually means that the question was poorly worded, or there wasn't enough information given, or there wasn't a solution to the question, and in this case, this might be true.

It is best to assume that we don't know anything about what you are trying to do, so you need to give as much details as possible, in a concise and logical manner. You should include a site if you think it helpful, any format that you are getting the data in, such as a screen capture, saving in a file format, downloading a file and the formats avaiable, etc. The neat thing about this forum, is you cam Attach copies of any files involved (FileMaker, Text, etc.), post a URL if you feel it would be helpful,

HTH

Lee

[mon]

Thanks, Lee.

Since I am new to XML and to working with EDI and EDIFACT any information would be helpful. EDI stands for Electronic Data Interchange and uses .sef file format to transmit data in a machine readable format. I hoped I could find information to lead me to find a way to move filemaker data to at least the format required for EDI. Some other info here: http://www.disa.org/

Best Regards,

mon

[Lee Smith]

Hi mon,

I just did a search of the forum for Electronic Data Interchange encased with quotes [color:blue]"Electronic Data Interchange" and it returned a few hits. There isn't much there, but take a look anyway, and see if there is anything there that can help. One suggestion was a google search.

HTH

Lee

[mon]

Hi Lee, thanks for the tip - I will check into this now. I was unable to to search EDI (too short a phrase) in the forums so I used EDIFACT. I didn't think to use the non-acronym, duh! By the way the Google search is what brought me to this (old) thread in the first place so maybe this part of my loop is over!

Regards,

mon

[Lee Smith]

If you are able to nail down an answer to this, I would appreciate it if you post back so that we can provide this to others in the future.

TIA

Lee

[mon]

Hello Lee,

The precise implementation of the EDI seems to be left up to the companies that use it. Typically they will supply a template in .rtf format. In FM Forums own discussions I found these threads that may help in figuring this out:

http://fmforums.com/forum/showtopic.php?tid/170131/

I then found

http://fmforums.com/forum/showtopic.php?tid/158542

Thanks to Bob Weaver for this good stuff!

Regards,

mon

[Joost Miltenburg]

The post was quite old indeed.

However, I am currently building a xslt to produce a edifact message for a client of mine.

I am currently pondering what is the best way to implement the message part.

All FTX ( free text) field can be up to 70 characters long as far as I can tell. So I am considering doing a message lines kind of setup, so I can easily check the length of the line. However, from a UI standpoint this is sub optimal...

Any thougths ?

[Babelabout]

Hello Everyone ;-)

Sorry to enter this FM Forums without ever used FM But, it looks like this thread need an EDIFACT specialist :

If (1) you want to generate EDIFACT instances and (2) you can "easily" generate XML instances from FM, I would suggest that:

(1) You generate your EDIFACT message with the XML/EDIFACT grammar, see http://en.wikipedia.org/wiki/XML/EDIFACT

(2) Then, you can use my XSLT script to "serialize" it into EDIFACT, see http://parse-edifact.googlecode.com/svn-history/r26/trunk/Serialiser/SerialiseEDIFACT.xsl, it's open-source

Of course, you would need a XSLT processor, but you have plenty of them depending of your platform... I guess that FM comes with some kind of scripting language that should be able to call such a XSLT processor. Correct?

I have attached a test set that would "just" require an XSLT processor:

- ORDERS.D.97A.instance.Seagate.txt.parsed.xml, the EDIFACT in XML/EDIFACT, the stuff you have to produce out of your DB

ORDERS.D.97A.instance.Seagate.txt.parsed.xml

- SerialiseEDIFACT.xsl.txt, my open-source XSLT script, the .txt should be removed, I have added it in order to upload the file to this forum ;-)

SerialiseEDIFACT.xsl.txt

- ORDERS.D.97A.instance.Seagate.txt.parsed.xml.serialised.txt, the ouput of the XSLT, which is your EDIFACT instance

ORDERS.D.97A.instance.Seagate.txt.parsed.xml.serialised.txt

In addition to that, I would say that EDIFACT instance are usually send over the EDIINT AS2 transport protocol, for which I also have an open-source solution, see http://code.google.com/p/babelas2/

/Patrice - http://babelabout.blogspot.com/

[comment]

I have been following this (and other EDI-related threads) loosely. The main problem, AFAICT, is that the people who know EDI don't know Filemaker and vice versa. I, for example, could never understand how and why CustomerName "Candy Inc" should become:

<C_C080><D_3036>Candy Inc</D_3036></C_C080>

Anyway, Filemaker has a built-in XSLT processor (XALAN-C) that you can employ while importing or exporting.

[Babelabout]

I can confirm that as an EDI specialist I know nothing about FM

Regarding your question about the "meaning" of NAD/C080/3036, I am afraid I do agree with you - despite the fact that EVERYTHING is publicly documented by the United Nations ;-) see http://www.unece.org/trade/untdid/d10a/trsd/trsdnad.htm for instance.

This is why, when working with EDI, you usually work with 2 steps! The application owner/developer creates his OWN interface with the technology/format he likes the most. For instance, you produce your own XML grammar with

It's the same with the EDI "standard" Now, by this decoupling, you actually reuse - e.g. do not touch - the application (e.g. FM) interface when you connect with a new trading partner, you "just" need to create a new mapping/translation. To finish, this post, I would say that EDI as the reputation to be expensive, it is just one of this "lie". The best quote I have found so far on this subject is

<CustomerName>Candy Inc</CustomerName>

And then, a guy, like me, writes a mapping/translation - preferable using XSLT, but a lot of "EDI software" have their own proprietary mapping technology that I would STRONGLY recommend to avoid! - that transforms it into

<S_NAD>

  <C_C080>

    <D_3036>Candy Inc</D_3036>

  </C_C080>

</S_NAD>

The final step being the serialization to the actual EDIFACT instance as explained in my previous post.



This approach decouples the application (e.g. FM) interface with the trading partner interface. This is great, because usually you use the same application interface with multiple trading partners who have different EDI formats. Do not think that EDIFACT (or any other "EDI standard") are standard in the sense that you can reuse it. Think about your personal relationships with different administrations, it's standard that they ask you to fill (paper) forms, in which you usually give the same kind of information (e.g. name, date of birth, sex, etc.) BUT, all the forms are "slightly" different 

We can all be honest: it is a cryptic language that has fed many children of the people who have mastered that language.

Source: http://www.energyservicesgroup.net/markets/unpealing-the-edi-onion-part-1/

Anyway, I am here to prove that EDI is (at least technically) not expensive, visit http://www.babelabout.com/about.html :

[comment]

I am not sure I see the benefits of multiple transformations here. Filemaker already has its own XML grammar, and the choice of the stylesheet can be scripted - so you could just click an "Export EDI" button and end up with the final document, with no need for third-paty software.

Adding a new recipient would be only a matter of adding a stylesheet and associating it with the customer. That's nothing new or specific to EDI - you often need to produce customized reports per recipient.

The "missing link" here is the mapping of Filemaker fields to the EDI "cryptic language".

To finish, this post, I would say that EDI as the reputation to be expensive, it is just one of this "lie". The best quote I have found so far on this subject is

We can all be honest: it is a cryptic language that has fed many children of the people who have mastered that language.

Isn't that a contradiction? :