ITKnowledge Exchange member "sillyITgirl" had a question about the difference between EDI files and flat files and fellow techies jumped in on the conversation and helped out. Here is a portion of the conversation. Read the rest of the thread.
Want to join in on a similar conversation? Register for ITKnowledge Exchange and fill out your profile so you can ask specific sets of people your IT questions and also help out your fellow geeks.
ITKnowledge Exchange member "sillyITgirl" asked:
I need to send purchase orders to vendors via EDI for R/3 v46B. Couldn't I just send a flat file (text file) containing the purchase orders to the vendors instead of using EDI? What is the difference between sending a flat file and EDI?
|
"KAJBRE" WRITES:
The normal reason for using EDI messages is that a receiver's system is able to process just a limited number of messages or file types. They want to receive files from their business partners according to a certain message standard and format. This is the whole idea of using EDI or other standardized message types.
If any file format would be accepted, the receiver should have a translation "engine" to handle every file type, which is obviously not very practical and gets expensive.
itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke
"SMILEY" WRITES:
The reason vendors insist on EDI is not only for security, but it also eliminates the need for re-entering the order in their system. EDI provides a set format that allows disparate systems to send and receive information without having to reenter it. All the fields in a purchase order, invoice, etc. are mapped and sent in a specific order so that the system receiving it knows what the information is and what to do with it. The way this mapping is laid out in the file makes it different than a flat file.
itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke
"STEVEL" WRITES:
EDI uses flat files. At your end it translates your PO into a specific standardized flat file format, handling things like packed data fields automatically. It then sends the flat file (either to an intermediary mailbox service like GE or directly to the supplier), and the supplier retranslates it into a file format their software can use.
By using EDI you are using agreed formats for flat files (for various different purposes), and they build their own translation between their EDI package and their software system if it doesn't come with one already; some big ERP packages provide translators for EDI formats. If you generate a custom non-standard-format flat file, the supplier will need to build a custom translation process, which they might want to charge you for building.
If you send a printed copy of the PO (a spool file), the supplier will have to manually import into a custom translation process (and again might want to charge for it) or manually key the PO into their order entry system (which might incur a handling charge).
If you are going to do this on a regular basis, you might find that some suppliers/customers will only handle orders via EDI. So decide how your business intends to deal with these suppliers/customers. It may be better to bite the bullet now and commit resources to getting up and running with EDI now, rather than later when your supplier/customer mix forces you to. Where is you business heading?
itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke*itke
"SOLUTIONS1" WRITES:
You have other options and considerations, which should be shaped by business improvement objectives. With respect to choices, besides EDI "classic" and "flat files" you also have a number of XML options (e.g., see Oasis-open.org and Universal Business Language [UBL]). You also should think of the overall "choreography." A purchase order typically follows a quote and precedes a shipping notice, receiving document and invoice, along with confirmations. If you send the order as a flat file of your own design, are you ready to accept a supplier's ship notice or invoice in a flat file of their own design? Ideally a "clean" order (decent format and reliable clean content) can set up a sequence of highly automated, productive transactions. There is no absolute "right" answer, but I suggest that you think seriously about working with your vendor to adopt a standards- and XML-based choreography.
