PlumberSurplus.com Ecommerce and Entrepreneurship Blog | About | Contact | PlumberSurplus.com Store

Electronic Data Interchange (EDI) Solutions that will Save Your Company Dollars before You Pick a Provider

Posted on January 22, 2010 by josh

Whether you're a business that buys or sells, you've probably heard of EDI. For those of you that haven't, EDI is an acronym that stands for Electronic Data Interchange. EDI is used when two entities want to share a standardized form of data. For example, a buyer sends a seller a Purchase Order EDI file. The seller then sends an acknowledgement EDI file. Then the seller might send a shipment notification EDI file, followed by an invoice EDI file. Makes sense, right? Seems easy…

We've built our own flavors of data interchanges before. However, we had not used the ANSI X.12 industry standardized EDI. We leveraged everything from simple flat files over automated email or ftp to xml via web service, each with agreed upon formats between us and suppliers or vendors. It's easy to do. You say, "Here are the fields and format we're going to send." They say, "Great! Here are the fields and format we're going to send." You both work to parse the data appropriately and agree on a delivery methodology and transaction schedule. So, why use the ANSI X.12 industry standardized EDI? Great question. I'm still trying to figure it out.

We were sort of forced to build it. By "sort of", I mean we were completely forced to build it. As in, one or more strategic partners says, "Oh, if you want to do business (/continue to do business) with us, you'll use this form of EDI." OK. No problem. How hard could it be? One would think that it wouldn't be that hard, as EDI has been around since the 1980's. This was back when data networks and a high level of computer competency was not a mainstream requirement of modern business, especially small businesses. Even the modern version of the standard still looks like it was built in the 80's. It also looks like it was built by a group of guys that desperately wanted job security. Yes, the files are in a standardized format. However, each file includes a copious number of optional elements, and a field representing one piece of data in one file type. For instance a Purchase Order file is formatted completely differently for the same piece of data in the next file type, like shipment. As I was working on the EDI project for our company, it occurred to me that this must have been the inspiration for XML. Someone was staring at this, saying to themselves, "No! Don't make me redefine the field for each stinking file type!" Also, the file has a flat file format, but it's delimited in the weirdest way. You have to build your parser to count out segments and account for optional fields. At least all of our partners utilize each of the standardized documents the same way, right? Nope. Each one takes their interpretation of the standard and we end up having to apply parsing logic by file type and by sender. Doh!

Pay Per Kilocharacter?

But, dealing with the building and parsing of files isn't the really irritating part; and truthfully, we're going to have to do something special for each of our business partners whether we use standard EDI or homebrew XML solution or something else. The REALLY irritating part is the delivery medium that you may be forced to use to communicate with EDI partners. As I understand it (and I could be wrong), back in the day, a very few telecommunications companies controlled data networks. These companies were regulated by government, and in order to charge for specialized services, like assisting in the transfer of critical business EDI files between two business entities, without regulation, they needed to create a new kind of service. So, Value Added Networks (VANs) were born. VANs serve as a go between, like a post office, offering various file transfer mediums, levels of security, tiered and specialized reporting, storage services, et al. You send a file up to your VAN, who holds a mailbox for you, and your VAN checks your file to ensure that it includes the right headers for the appropriate file type, stores your file and alerts your trading partner of a new file ready for exchange. That's it. That's what a VAN does, nothing that you couldn't do yourself. It's not like I can't store the files myself. Storage is cheap. It's not like I can't find a file transfer medium that works securely (simple things like FTPS or SFTP should not be tough for any IT guy to set up really cheaply). The best argument I've heard in favor of using a VAN, so far, is that it eliminates the need to let others have some access to your network. This came from one of our partners. To this I say, "Fine. We won't connect to your network. You can push and pull files on our network." Again, setting up the file transfers is not that hard and also doesn't expose your network to uncommon risk. It's dumb to pay the VAN for services that you can build yourself for very little money and effort. Plus, the VAN charges you by something called the kilocharacter. This is how you know it's from the 80's. A kilocharacter is represented by 1000 characters in your EDI file. Seriously, I feel so ripped off. Twenty years ago, you would have had to have a direct data link with the VAN. I would have really felt ripped off if that was the case today.

Paying Sticker Price

If you do have to do EDI through this type of channel chances are you'll be put in the position of explaining to your boss why your company has to spend money to send an order. It will end up being only pennies, maybe nickels depending on your volume, per order, but you won't feel any better about it. My advice if you're stuck in this position is this: Negotiate, Negotiate, Negotiate. When I started looking around for the right VAN solution, I was surprised at the breadth of offers. After getting quotes I went back to the same places and pitted them against one another. Not a single vendor stuck to their original quote. Everybody folded in one way or another. I finally found the two that would meet my needs that would give me a good price and I focused in on them. Just when I thought I had done a great job of negotiating and had gotten the best price I possibly could have, I went to my boss with my final contract terms for VAN services. He balked. "Why do we have to spend this much, again?" I explained it to him. He told me to go back and get better terms and better pricing. Feeling like I had done the best I could, I told him I would see what I could do. Surprisingly, when I went back and told the two vendors that I was going to have to decline because the price was too high and the terms weren't as good as we wanted, I was able to negotiate even better pricing and even better terms from both vendors.

Key Takeaways

The point here is this, if you can avoid having to use the antiquated and expensive ANSI X.12 industry standardized EDI, avoid it. If you can't (and chances are if you work with any large companies from traditional verticals, you can't), do this: Ask your partner to skip the VAN and exchange files directly with you. If they won't, get your customer or supplier to pay for it. If they won't, negotiate the heck out of the VAN services, then go back and negotiate again; you can get much better than published pricing on VAN services. Finally, if you're transacting via EDI with more than one customer or supplier, don't count on the files being used consistently across all of them. Portions of the standard are open to interpretation.

 

blog comments powered by Disqus