From: George Gallen > One thing I just don't understand..Why is it so > freakin expensive to transmit EDI transactions? in > today's age of the internet and transmission speeds.
I think the cost is a hold over from the old days when we required a Value-Add-Network to store and forward transactions, and to guarantee sequencing, delivery, etc. I was doing EDI (X12) in the early 90's and setup exchanges with large companies like Sears, Wards, JCPenny, and their trading partners. Free web services didn't exist and direct connections amongst companies were impractical (over phone lines). So going through a VAN was a requirement, and companies paid the price. Today, the cost is the same as it ever was, even though the "value-add" is arguable given how much we can do for ourselves. It's still expensive because people still pay the price - it's what the market bears. EDI software was and still is expensive. It validates data, offers to wrap your data to mapped document elements, wraps that payload in envelopes, handles transmission, and logs all events. There is certainly value here but I have always been agast at the cost of these utilities which often exeeds $30k. Unfortunately big companies easily pay this, because expensive software must be good, right? I've always tried to do as much as possible in BASIC to create a complete, envelope-wrapped payload which just needs to be transmitted, and I prefer to use BASIC to process inbound transactions as well. That said, every "standard" document that you process with every trading partner is going to be unique. EDI is more about human interaction and business decisions than it is a technical affair. So if you do this in BASIC, no matter how much you try to re-use your code, you're going to get a lot of custom code for every document for every partner ... your programs become a X-by-Y matrix of documents to partners, you'll rarely get one program for all partners for a given document. For that reason over the years I've found a lot of value in the commercial EDI document processing offerings (separate from VANs). We like to manipulate strings in BASIC but specialty software "may" do it more efficiently and with a lower TCO. But cost has nothing to do with quality. Unfortunately you need to evaluate every package for what it does and does not do. How extensible are they? Are they locked into a limited selection of VANs? Where are the data tables kept and can you load them with an interface to your MV system? There are all sorts of questions that need to be asked and you just need to shop around for a product that's affordable, well supported, and with all of the features that you require now and for your anticipated usage. Or as the saying goes: "You can get it Good, Fast, or Cheap. Pick two". HTH Tony Gravagno Nebula Research and Development TG@ remove.pleaseNebula-RnD.com Nebula R&D sells mv.NET and other Pick/MultiValue products worldwide, and provides related development services remove.pleaseNebula-RnD.com/blog Visit PickWiki.com! Contribute! _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
