>We need to build EDI files from our VFP accounting system. While I know how to build a flat file, I wondered if anyone new of a good tool for building EDI files.
>
>I have the specs of the file on paper (several pages long). But I was looking for something I could use to double check the output or even a tool I could call to build the file.
>
>Thanks
>
>Alan Wyne
>IS Manager
>Rollpak Corp

Alan,

Though I should assume that you know what you are talking about, let me give you the below for info anyway.

As you say that you know how to build a flat file, you know how to create EDI files. It's just ascii.
If you -then- ask for some tool to create EDI files, you are, in fact, asking for a program to create the ascii file with the protocol (hence record layouts) you have on the paper in front of you.

Now something starts to go wrong ...

What you ask for, is if I have a program that sorts out the data from your database to any EDI format. Think of it ...

Only the last urges for additional explanation.
The only one (european) back-bone standard is EDIFACT (in the US it is another I think). It's 2 meters of paper. But, it can be done (we have it). However, nobody actually uses it, except for the EDI providers. They send the EDI-"file" by means of physically transporting the EDIFACT layout.
Note that an EDI provider is the instance to send an "in house" EDI file to, and he converts it, sends it to the addressee (EDI provider), and there it is converted again to the "in-house" format as liked overthere (your customer etc.).

The in-house files, are the phenomenon where everyone can put in what he likes, and your EDI provider is there to convert whatever it is to EDIFACT or from EDIFACT. This tells that you can do what you want, as long as you pay the EDI provider for his (conversion) work.

But it is slightly more complex ...
Within business lines, standards exist for the in-house files. Think of standards for food, metal, etc. Both are very different from eachother, and both use very different subsets of the EDIFACT standard. And, EDIFACT supports just all.
Now an additional problem arises : when you'd be really using the part of EDIFACT that supports "metal" stuff, the receiver most likely doesn't have an app that can deal with the dynamics concerned. So what you send is useless. And it is exactly here where the standards come in at the in-house level. "Send data that all participants can deal with".

Now, it is STILL so that you can send what you want, as long as the EDI provider let it complay to the standard implied; he shouldn't trow away parts of your data, and he shouldn't need to add for sure.

This is your answer.

I can ad to it, that you want to EDI a accounting data. Well, I even wonder whether it exists. So, it might be your customer (or account desk) just dropping you some record layouts, and you'd just have to give 'm that. Well, do it. You are the only one who can.

Last thing : Overhere the phenomenon "EDI provider" is dying out for the sake of formally transporting the data. All tends to go over the Internet, and app-suppliers (like me) are allowed now to play their own "provider".
From this you might learn that EDI becomes not much more than sending some electronic data via email, if you trust that.
This even more tells "do what you want", and hence, forget about any existing program for you. It just can't exist, unless someone in the area of the accounting system has done it before you.

BTW, if you need to go from XML to EDI, I'd start asking why "they" can't receive XML. It's made for it you know. In fact, EDI based communication is dying, and XML based systems come instead (for a long time now).

HTH,
Peter