I have worked in both flat file and staging table environments. I have also worked in Standardized table staging environments. that use xml, delimited, and almost EDI.
My experience in this area is for large data loads 185M ANSIX12 Invoice files(3000-20,000/day). Typically most companies will spend more on hardware for their database and main ERP/WMS than a translator. The value of the staging table is key, but the distinguishing value I have found, are all of the ancillary look up tables that can get built around it. This is what I call making the data loader "edi aware", which extends the EDI Knowledge of the application. What I mean by this is that a standard iteration of an N1 loop has say approximately 20 elements if you just count the N1, N2, N3, and N4 elements, when you can make these 20 elements = a table in an app and apply a lookup for values at data load or a decode, the inherent value of having one map can almost be achieved. Essentially removing some of the mapping from the mapper and putting it more in the line of the data loader. The data loader is naturally owned by the application which allows it to pull data when it is ready, rather than backing up you translator with ODBC sleep and reconnect calls which will back up translation.(atleast in the two cases I know of TLE and Gentran on NT) So when you extend the mapping to the data loader the oci/direct path is not getting clobbered by ODBC overheads. . . . Of course this is of no value if you are not translating large files or large counts of files or large counts of ST's. ________________________________ From: Ken Etter <[email protected]> To: Travis Truax <[email protected]>; [email protected] Sent: Thu, January 27, 2011 11:25:15 AM Subject: Re: [EDI-L] Flat File vs XML => What about Using your data base? I've read the past posts related to DB vs Flatfile and there are some valid points about using Flatfiles. If you have the expertise with DB staging tables or SQL in general, it sure makes it a lot easier and quicker to track down EDI content using a DB Staging table(s) than trying to filter through a flatfile archive directory where all EDI transactions are stored in individual files. Then if you still have a problem after reviewing the SQL staging data, you can backtrack to the original EDI. As to Ajay's earlier answer, yes if you empower the customer with database tracking there becomes an issue with ownership, but I think that is more from a eCommerce standpoint. You can implement DB staging tables for both your inbound and outbound EDI staging without the need to involve or impact customer data in other places... Ken [email protected] ________________________________ From: Travis Truax <[email protected]> To: [email protected] Sent: Thu, January 27, 2011 11:32:05 AM Subject: Re: [EDI-L] Flat File vs XML => What about Using your data base? We just went through the same thing when we moved to a different ERP a year ago. They had this flat-file import routine that they seemed so proud of, and it was going to require modification since it didn't include several critical bits of data we needed to import. It could handle ONE date on an 850 - the order date. I guess they had never worked with a customer who requested a shipping window or set a deadline for cancellation. The approach we took was to translate directly to a set of db tables (not the actual ERP tables - but more of a "queue"). Then a stored procedure processes the data from there and pushes it into the ERP. Sure, we still have to tweak the sp when a partner sends some new data it doesn't currently handle - but that's infinitely easier than modifying a proprietary import application. Cheaper too, since they would have been charging us to make the change.....every time it happened. They were borderline hostile to the notion of us circumventing their lame EDI functionality. Travis- ----- Original Message ----- From: "Chris Johnson" <[email protected]> To: [email protected] Sent: Thursday, January 27, 2011 9:56:38 AM Subject: Re: [EDI-L] Flat File vs XML => What about Using your data base? Quoted text is from <[email protected]>, by Skip <[email protected]> >Why or why do so many folks make more work. Any decent translator >marketed in the past 10 years will allow you to map directly into and >out from most commercial data bases in existence today. Use the tables >as they more closely mirror and structurally resemble EDI groupings. > A good question. Our software has the ability to map data to and from multiple key-linked delimited files. The only ERP which ever used this format was Baan, and over a decade ago they introduced the capability to import and export using a structured 'flat' file - an approach which was promptly adopted by everyone we dealt with. So the answer is that people do not like the multiple table approach. To the further question as to why this should be so I have no answer. Regards Chris -- Chris Johnson mobile:+44 (0)7785 302122 Fax: +44 (0)870 0519 818 EDI website http://www.edimatrix.co.uk EDIMatrix Ltd work: 0845 126 0680 or +44 20 8778 1402 Registered in UK no. 2777624 Reg.Office: 34 Sydenham Rd, London SE26 5QF ------------------------------------ ... Please use the following Message Identifiers as your subject prefix: <SALES>, <JOBS>, <LIST>, <TECH>, <MISC>, <EVENT>, <OFF-TOPIC> Job postings are welcome, but for job postings or requests for work: <JOBS> IS REQUIRED in the subject line as a prefix.Yahoo! Groups Links [Non-text portions of this message have been removed] [Non-text portions of this message have been removed] [Non-text portions of this message have been removed] ------------------------------------ ... Please use the following Message Identifiers as your subject prefix: <SALES>, <JOBS>, <LIST>, <TECH>, <MISC>, <EVENT>, <OFF-TOPIC> Job postings are welcome, but for job postings or requests for work: <JOBS> IS REQUIRED in the subject line as a prefix.Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/EDI-L/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/EDI-L/join (Yahoo! ID required) <*> To change settings via email: [email protected] [email protected] <*> To unsubscribe from this group, send an email to: [email protected] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
