Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Total EDI Newbie - I'm SURE I have a major misconception, help?

Status
Not open for further replies.

Zentide

MIS
Jan 7, 2005
2
US
Ok, I work at a small company who has recently been asked to implement EDI to receive and confirm orders for 1 customer for 2 documents.

Background:

We package and distribute salsa/sauces etc..
We have a basic homebrew WMS/ERP system and our customers send us a order in .csv file with formats we set up based on their needs. They e-mail us the orders, our system slurps them in from e-mail, processes them, and return mails a confirmation .csv from the info (ie 2 bottles shipped on X date via ups etc...)

Now as I understand it EDI is the exact same process, but with a different framework (ie Standards between businesses security, VANs etc..)


So lets say I get an edi document (we'll use 940's and 945's as examples. And I'm a moderately intelligent guy so I look at the map and think, (And here's where you can set me right)

I think ,..Heck. I can script the import of this file, pull the values from the fields, dump them into a .csv and have them dropped into my system like normal. (basically write some batches to pull and ignore varialbles from the EDI 940 document. Then do the exact opposite with my confirms.

What is the value,..underlying story etc.. of EDI that I'm not getting here? Why don't I just SCP files back and forth with all my buyers/sellers based on a published file format standard??

I mean if I was dealing with thousands of clients, I can see where the standards would come in handy (though from what I understand *everyone* uses completely different pieces of those standards) but all this mapping, and translating etc.. seems both painstaking, expensive, and redundant.

But again,..this is a whole new world to me so, clue me in ok?







 
Nevermind,..I just tried it out and it worked perfectly. I guess there is no magic behind the scenes. This really does appear to be a 100% overhead hallmark technology.
 
Not everyone has someone to write customer software, even if it is a batch file or shell script. There are lower cost options, such as Trading Partner PC etc. Biggest question to ask yourself: Will my homebrew work if my business doubles, triples. etc. What if you want to do business with Walmart?



BocaBurger
<===========================||////////////////|0
The pen is mightier than the sword, but the sword hurts more!
 
If you only have 1 program to write, you may be ok. If you have more than a few trading partners and each sends you a slightly different file, or version of X12/EDIFACT/EAN.UCC, you could be in real trouble. At a minimum, the cost of writing a custom program for each will soon exceed the one-time cost of a commercially available translator.
 
Remember too that you may have to send a 997 Functional ack back to your trading partner. Most translation software will handle this for you. Also, take into consideration that there are other validations and checks for required fields and values that most translation software will handle. If you write your own software then you may have to build these additional tables into it.

Lee
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top