home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / bit / listserv / edil / 322 < prev    next >
Encoding:
Text File  |  1992-12-24  |  2.4 KB  |  53 lines
  1. Newsgroups: bit.listserv.edi-l
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!wupost!csus.edu!netcom.com!netcom!mdg
  3. From: mdg@netcom.Netcom.COM (Mark Grand)
  4. Subject: Re: Samuel Pepys & EDI transactions
  5. In-Reply-To: Bill Laidley's message of Thu, 24 Dec 1992 09:15:59 -0700
  6. Message-ID: <MDG.92Dec24121557@netcom.Netcom.COM>
  7. Sender: mdg@netcom.com (Mark Grand)
  8. Organization: Premenos
  9. References: <EDI-L%92122409155953@UCCVMA.UCOP.EDU>
  10. Date: Thu, 24 Dec 1992 20:15:57 GMT
  11. Lines: 40
  12.  
  13. >>>>> On Thu, 24 Dec 1992 09:15:59 -0700, Bill Laidley <WLAIDLEY@BCSC02.BITNET> said:
  14.  
  15. Bill> The difficulty...
  16.  
  17. Bill> There is a problem though - the 811 consolidated service invoice
  18. Bill> is SO big that it exceeds the capacity of the EDI translator
  19. Bill> that we have installed (and at least one other translator that I
  20. Bill> know of - both mainframe based). The problem is not the volume
  21. Bill> of data, instead the problem is in the design of the
  22. Bill> translators. Most EDI translators have the same basic design -
  23. Bill> they are table based. In our case the limitation is the size of
  24. Bill> the tables used to define the data segments and elements used in
  25. Bill> the transaction. (the limit on total segments is 100, the limit
  26. Bill> on combined segments and elements is 400). The transaction
  27. Bill> specification for the 811 that has been developed by Telecom
  28. Bill> Canada has over 500 segments and elements. Oops.
  29.  
  30. Bill> So what is the problem, after all we could split the transaction
  31. Bill> up and have it sent in two (or more) pieces. Well, the problem
  32. Bill> is in the nature of a hierarchical EDI transaction - to reach
  33. Bill> the lowest level of detail (which is what you need to validate
  34. Bill> your invoice) you must traverse the entire hierarchy. So there
  35. Bill> isn't an obvious way (to me anyway) to split up the transaction.
  36.  
  37. You asked for a solution to your problem other than new software.  I
  38. am not aware of any such solution.  My employer, Premenos, sells a
  39. product called EDI/e that is not table based and does not have any
  40. limitations on the number of segments or elements in a transaction.
  41. It is capable of front-ending for a mainframe, but does not run on
  42. mainframes.  It runs on UNIX boxes.
  43. --
  44. Mark Grand
  45. Premenos Corporation
  46. 1000 Burnett, Second Floor          mark@premenos.sf.ca.us
  47. Concord, CA   94520
  48. -- 
  49. Mark Grand
  50. Premenos Corporation
  51. 1000 Burnett, Second Floor          mark@premenos.sf.ca.us
  52. Concord, CA   94520
  53.