Generating EDI from a non-SAP, non-EDI-savvy database to go INTO a SAP sys?

[Former Member]

I am a FileMaker geek.

I have been asked about developing EDI transaction modalities from within a FileMaker Pro database for facilitating data exchange between the FileMaker db and a SAP environment owned & maintained by the same company.

It seems like an odd request (these days, most exchange to/from FileMaker and other in-house systems is done "live", writing directly to the rows & columns of the various non-FileMaker tables using standard ODBC drivers;... but ignoring that, I've looked at what EDI is, and does, and I gather that the following are true?:

u2022 System A's data structure is "flattened" down and then that data is arrayed as a "document" such as an invoice or a purchase order, etc etc....

u2022 EDI is a venerable and well-established system allowing that resulting "document" to be conveyed, usually to a different company such as a trade partner, (in this case NOT, it will all be internal), which can then, in some fashion, import the data from the "document" into its own very different table structure in what we'll call System B.

u2022 EDI in some fashion creates a standard, and that standard replaces the need for the folks using System A and the folks using System B to do a lot of cumbersome comparison of "what table and what column in your system represents the unique identifier for invoice and which column is invoice number" etc etc, -- by having both folks "speak EDI" the need to map out those matchups is eliminated.

Please correct me if I'm on the wrong track up until that point, thanks. Now, assuming I am NOT wrong, my main questions:

u2022 File format! Is the EDI "document" a plain text file that can be assembled and exported from a system that is itself oblivious to EDI, by a developer who is given the schema of how that text document has to "look" to System B? Or is it binary and/or of sufficient complexity that no one DOES that, that instead some sort of driver or program is generally acquired or purchased that encodes data (say for example tab-delimited ASCII text) into EDI format?

u2022 Schema? I know how to flatten relevant information and export it out of FileMaker, but for most such requests I would be given a sample document, e.g., "data that goes into QuickBooks has to be in XML format with the relevant XML headers & data in the following order..." or "data that goes into our MAS 90 should be in tab delimited text with the following column order and without column name as top row..." or "data that is to go into our SAS system should be a plain text file with each column a precise char length padded with the standard space char as need be, in the following order..." etc etc. Would I be given a similar schema and then just export out of FileMaker and assume that they will convert it (if need be) to EDI format from that, or is the art of spitting out data as an EDI "document" a very different sort of task?

u2022 Is there a good reason that my initial gut reaction is necessarily WRONG, i.e., that since Company X owns both System A (FileMaker) and System B (their SAP system) and presumably have the hi-level passwords for full access to both, it would make more sense to write directly to the appropriate corresponding tables rows & columns instead of using EDI? If so can you give me a sense of why they would want to use EDI for this?

with sincere gratitude, thanks in advance.

Edited by: Allan Hunter on Feb 3, 2009 2:25 PM elaborated on thread title

[Former Member]

Thank you, <b>Amit Kulkani</b>, for your replies. I'm afraid neither answer is really an answer to my questions. May I elaborate?

a) In the first reply post, you write: " if we did not use EDI there might be many mannual error take place in operation. So In short only the security point of view EDI works better."

Assuming your target (SAP) tables have rules per each column and per each row, a direct SQL statement should not allow inappropriate information to be entered. I can accept that perhaps SAP was written without such safeguards, if that is what you are telling me, but in that case any direct data entry process is going to be vulnerable to data entry error. Or do you mean that no data entry <i>whatsoever</i>, at any point, at any time, occurs other than via EDI?

b) In the second reply post, you cite these advantages. Advantages over hand-writing the data on the back of a paper napkin and mailing it in a manila envelope for someone to retype into the system, yes, but how are any of these improved by using EDI instead of a direct connection from FileMaker?:

u2022 Reduced postage costs <i>Huh?</i>

u2022 Reduced expenses <i>what expenses?</i>

u2022 Speed <i>I would think directly writing to the data would be considerably FASTER than exporting to EDI and then importing from EDI into SAP</i>

u2022 Elimination of paper documents <i>Who said anything about paper documents?</i>

u2022 Elimination of labor intensive tasks, such as data entry <i>Yes, what I propose would eliminate that also</i>

u2022 Greater accuracy of information <i>See above</i>

Can you re-read my original post and give the same thoughtful consideration, but this time comparing EDI to what I am proposing (direct connection to the SAP tables), <i>not</i> comparing it to sending the data in on a piece of paper to be retyped manually when it arrives?

Thanks in advance, and thanks again for your answers so far.

[Former Member]

Hello,

Below are the benefits of EDI -

Reduced postage costs

Reduced expenses

Speed. Because information is moved faster and with greater accuracy, time spent communicating with suppliers is decreased.

Elimination of paper documents.

Elimination of labor intensive tasks, such as data entry.

Greater accuracy of information.

Best regards,

Amit C Kulkarni.

[Former Member]

Hello.

In short EDI is elctronics data interchange , if we didnot use EDI there might be many mannual error take place in operation.

So In short only the security point of view EDI works better..

Regards,

Amit C kulkarni.