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."
it depends... (Score:1)
I think it's a neat idea. Go for it!
Why EDI? (Score:1)
I know EDI has been around a long time, but why EDI?
These days XML is as capable, or more capable than the EDI systems, and for that matter there are a lot of tools for doing XML based messaging.
I've been working for a year on a project (contract) writing client-side interfaces to CLEC OSS interfaces based in HTTP and XML. Development is fast (it's convincing my client to take the time to design the client side APIs and do the integration work correctly the first time - man they wanted quick one offs that don't scale).
Re:XML by itself can do nothing (Score:1)
XML Irrelevant -- Standards Cabals are the problem (Score:1)
Re:Good to see other interest... (Score:1)
Re:Go to it (Score:1)
Everyone wants to write an EDI Translator (Score:1)
XML by itself can do nothing (Score:2)
Good to see other interest... (Score:2)
I've submitted this very same question to Ask Slashdot once before. It's nice to see it actually surface and get a little attention, although I see not a lot of attention.
My first impression of EDI was why? But, as I read in to it a little more, I was increasingly impressed with the concepts, just discouraged by the implementation. EDI, for people who don't know, stands for Electronic Document Interchange. It has been around for quite a while and developed out of a military need for efficient, standardized documentation during WWII. No, it wasn't electronic then, but it didn't take long to adapt it.
If you've ever looked at a raw EDI document, you'll find that it is simply an ASCII flat file whose datafields are defined by a standard document template. It's amusing that they use the word "standard" to describe the template, because with each company you interface, you must have a copy of their "template" to tranlate the document with your EDI software. If you use the same software, GREAT! Just pass the template around. If not, you will normally have to hire an EDI consultant to create the template for you. The company we were going through would charge between $500 - 750 a pop (per business-to-business exchange) for 3 or four document templates (Purchase Orders, Order Acknowledgements, and Invoices are the basics).
The "markup" for the EDI document is supposed to be "universal", but my impression is that they've perhaps standardized on a few notations and styles. You could probably be able to pick out key fields in an EDI document by browsing the raw source file, but you would more than likely need to have your tranlsation specs sitting next to you to confirm.
Frankly, EDI is lightyears behind XML in readability/parseability but quite a bit ahead as an established business-to-business document exchange standard. Perhaps we'll see a migration of EDI to XML happen in the near future. It seems like the next logical step.
This leads in to my next comment, and a brainchild yet to be born. I would love to see an EDI to XML translation library pop up out of the Open Source community. (Which leads, of course, to the XML to DB import/export library...) Unfortunately, I'm quite busy and can't lend my hand in this venture, and as he previous post suggests, it's quite expensive to obtain copies of the "standards" documents.
I did have some links relating to EDI, but since I left my last job, I've had little need to follow up or maintain the list... IOW, I've misplaced it. Look into the XML&EDI scene on google, you should be able to find a few links.
Re:Why EDI? (Score:2)
Because a lot of companies, particularly very big companies, like Walmart, all the package carriers (UPS, FedEx, DHL...) and the Department of Defense use it heavily.
They aren't going to change overnight. If you want to do business with these guys you might be advised to get some X12 EDI capabilities.
-Jordan Henderson
Heh... (Score:3)
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 [uc-council.org], 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