pi_rules asks:
"I'm by no means an expert on EDI software (stuff used to communicate purchase orders, invoices, ship notices, etc., electronically) but from a programmer's point of view I'm dismayed at what the market for this stuff looks like right now. Looking at the specs to the documents it doesn't seem like an overly daunting task to implement a solution on a business-by-business basis; however the only commercial solutions out there are huge, expensive products. I'd like to know what other people who have worked with EDI software can tell me about what they need their software to do; and if they have a solution if they could give me a general over-view of how it even works. My intention here isn't to beat up on existing EDI solution providers really; it's just that I want to see a solution that's 'geek-friendly', and beneficial to businesses by setting up a system that will provide them software that not only functions, but does the job lickety split."
"After shelling out $10,000 for one of these products we found it to be: slow (incredibly slow), unintuitive, and it didn't even work! Of course, the company is clueless as to how to fix the problem. Granted we've only tried one vendor, but this was the one -recommended- to us by our customer. After asking around, it turns out that other businesses with similar needs had to hire in programmers to write their own custom solutions.
I'm entirely capable of writing the software to handle our situation here but I'd like to start a Free Software project out of whatever I make. The problem is that I know little about this massive standard and the Right Way to go about constructing software to do the task. The standard is absolutely HUGE, and can vary significantly from vendor to vendor I'm told."
I've worked with a bit of EDI myself - mainly the products from St. Paul Software - I don't know if these were the guys you worked with (it doesn't sound like them) or not (it wasn't the Gentran software from Sterling Commerce, was it? I've never used their products, so I can't comment on them).
/. - I would love to follow it's progress.
I've had good luck with SPS's solutions in regards to EDI (first with spEDI*tran on a sco box, then with Evision on NT) - they had excellent tech support, which is one thing that has stood out in my mind. However, their product isn't cheap.
To be honest, portions of the standards for EDI (which come from the UCC, a company we all love, right?) are convoluted, while most of the others are straight forward (most of the warehousing/inventory/order forms are easy - but the insurance related forms can give you nightmares).
Good luck in finding a free project, or starting your own - the "standards" tend to be the issue. It seems like every year they change significantly, to the point where it is hard to keep up with the standard. On top of that, the fees to buy a copy of the standards (in order to code a solution) can be pretty high. Plus, anybody working with the system would need a copy of those standards as well.
Most of the EDI solutions offered by companies (such as SPS's Evision product) are actually development environments, that allow you to create the templates to do the translation (basically, all EDI comes down to is data translation from one obscure format to another "standard" format to interchange data). The company may also offer services to create these templates as well, for a fee (many times it is cheaper to do this than doing the templates in house with the software).
I looked into the possibility of creating my own EDI software at one point - a template development/translation environment. I realized pretty soon that such a task would be near impossible by myself. I figured to even have a hope, I would have to have about 10 programmers working and designing for about a year before we would even get something (this was before I heard of free software, open source, and the GPL). Maybe today it would be possible to do what you want - but it would be akin to creating a programming language (in fact, SPS's software started exactly that way back in the early 80's - as a form of interpreted BASIC - you essentially wrote BASIC code to do the translation - the tools that came later GUI'ized the system, but still, under the hood of Evision, lies BASIC code and interpreter, chugging away). With the head start the other companies already have (10-20 years in some cases, like SPS), it might be possible, but it would be an uphill battle.
Still, if you have the need and development time, and you are well versed enough in EDI to consider it, I say go for it - create a simple system to handle creation of simple forms, or the portions of the forms thereof (so you can combine the pieces to form full forms), then go from there.
BTW - if you get something going, anounce it on
Reason is the Path to God - Anon