A reverse of the usual, I'm sure Skip meant to share this with the group, so I am forwarding. Leah
----- Forwarded Message ----- From: Skip <[email protected]> To: Leah Halpin <[email protected]> Sent: Friday, May 27, 2011 11:34 PM Subject: Re: JD Edwards and EDI - Data Base v.s. 'Flat Files' Hmmm got some reaction and response. Mixed at best <smile>! First, this was specifically targeted to JD Edwards ERP systems and the implementation of EDI within that ERP system. Next, some of the issues raised are more related to the deficiencies in some translators. Ones such as Inovis/TLE has been used successfully with JDE systems for over 15 years. Other newer more data base centric like Liaison's Softshare provide all the DB functions as well as the EDI translation. The issue of tracking and visibility of inbound EDI data relates to audit/control as well as legal 'Trading Partner Agreements' that I did not discuss directly. Certainly a current DB provides for plenty of audit trails, reporting etc on the integrity of tables and data structures far beyond 'flat files'. Most decent translators provide administration, review and reporting (some better than others) that fully communicate to the user and EDI administrator what is and has been happening. There certainly should be NO modification to any inbound EDI data as it is tampering with legal electronic documents. The data once inserted into the DB tables (F47) is in control of audit trails, inspection and manipulation by the use in the JDE system. Other systems will vary... all depends on how well designed and functional they are. Again, not relevant to this discussion directly. Inserting the data directly into the controlled environment of the DB system from the pure raw EDI source via a translator makes a more secure audit trail and maintenance of data integrity. Messing around with flat files is just that; messing around and I really find it difficult to think of a cost effective case that a DB would not provide more functionality, visibility, integrity and audit-ability. I focus on cost effectiveness of the solution. In some cases where fixed or delimited data files are still in use, it may make sense. Certainly some older mainframe systems still employ these data models; heck I used to design, code, implement them many moons ago! For those of you who maintain and work with JD Edwards and have seen a mix of implementations, I'd love to see if you have any data on cost of ongoing maintenance of an implementation over time of a 'flat file' implementation v.s. a DB implementation. Would be interesting and again, comments are truly welcome. Cheers and thanks for your responses. Skip Stein Management Systems Consulting, Inc. The EDI Guy --- In [email protected], Leah Halpin <leahhalpin@...> wrote: > > How very Zen of you Michael. I couldn't agree more (at least I think so, > grasshopper). > Leah > > > > ________________________________ > From: Michael Mattias/LS <mcmlserve@...> > To: [email protected] > Sent: Friday, May 27, 2011 5:04 PM > Subject: Re: [EDI-L] JD Edwards and EDI - Data Base v.s. 'Flat Files' > > >  > >I have had recent interest in the subject of JD Edwards EDI and use of Flat > >Files v.s. Data Base Tables. To me it is idiotic to use Flat Files for > >much of anything any longer. But it is amazing how this primitive approach > >in today's Data Base Systems environment continues to be used; even > >promoted and presented in Webinar Presentations. Amazing isn't it. > > > > Anyway, I've put together a sort of white paper on the matter. Love to > > hear some comments from my 'peers' <smile>! > > > > http://www.ediguy.net/documents/jde_edi.html > > I can't tell if your indictment of "flat files" above is specific to the JDE > environment or not... but if it isn't and was meant in a broader sense, I > must disagree. > > To some system designers, only flat files make sense; to some only RDBMS > tables make sense; but to good designers, BOTH flat files and RDBMS tables > have their places. > > The medium is not the message; the 'how' is insignificant when compared to > the 'what;' the destination is more important than the route. > > Michael C. Mattias > Tal Systems Inc. > Racine WI > mmattias@... > > > > > [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/
