home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / bit / listserv / edil / 321 next >
Encoding:
Text File  |  1992-12-24  |  3.3 KB  |  68 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!europa.asd.contel.com!gatech!usenet.ins.cwru.edu!news.ysu.edu!psuvm!auvm!BCSC02.BITNET!WLAIDLEY
  3. Message-ID: <EDI-L%92122409155953@UCCVMA.UCOP.EDU>
  4. Newsgroups: bit.listserv.edi-l
  5. Date:         Thu, 24 Dec 1992 09:15:59 -0700
  6. Sender:       Electronic Data Interchange Issues <EDI-L@UCCVMA.BITNET>
  7. From:         Bill Laidley <WLAIDLEY@BCSC02.BITNET>
  8. Subject:      Samuel Pepys & EDI transactions
  9. Lines: 57
  10.  
  11. It has been VERY quiet on this list, so I thought I'd make some noise (besides
  12. it's also quiet at work for the moment - so I have time...).
  13.  
  14. My topic of choice will be hierarchical EDI transactions (an explanation of
  15. the subject line - long ago Samuel Pepys re-designed the way the British Navy
  16. was organized by implementing the hierarchical, line of reporting structure
  17. which has become the model for armed forces world wide; eventually most
  18. organizations used it for lack of a better model...).
  19.  
  20. Some background...
  21.  
  22. We (the organization I work for) are in the process of starting an EDI pilot
  23. with our local telephone company. They will send us invoices for voice and
  24. data lines/services. The current practice is for the telco to send us the
  25. invoices on tape, in print image form (total size of the 2 files is over than
  26. 80,000,000 bytes...). Once we receive them they are processed by some custom
  27. programs which attempt to extract as much information as possible and then
  28. manually. The processing window is 4 working days before the invoice is passed
  29. to Accounting to pay. Looks like a good opportunity for EDI, as receiving the
  30. data in a more usable form would allow us to automate more of the processing,
  31. as well as make it possible to more thoroughly edit the data for accuracy
  32. (which I suspect is rather cursory today).
  33.  
  34. The difficulty...
  35.  
  36. There is a problem though - the 811 consolidated service invoice is SO big
  37. that it exceeds the capacity of the EDI translator that we have installed (and
  38. at least one other translator that I know of - both mainframe based). The
  39. problem is not the volume of data, instead the problem is in the design of the
  40. translators. Most EDI translators have the same basic design - they are table
  41. based. In our case the limitation is the size of the tables used to define the
  42. data segments and elements used in the transaction. (the limit on total
  43. segments is 100, the limit on combined segments and elements is 400). The
  44. transaction specification for the 811 that has been developed by Telecom
  45. Canada has over 500 segments and elements. Oops.
  46.  
  47. So what is the problem, after all we could split the transaction up and have
  48. it sent in two (or more) pieces. Well, the problem is in the nature of a
  49. hierarchical EDI transaction - to reach the lowest level of detail (which is
  50. what you need to validate your invoice) you must traverse the entire
  51. hierarchy. So there isn't an obvious way (to me anyway) to split up the
  52. transaction.
  53.  
  54. The request...
  55.  
  56. Is there anyone out there with some experience in dealing with hierarchical
  57. EDI transactions? Any suggestions (other than new software...)?
  58.  
  59. A footnote...
  60.  
  61. The other area that keeps me busy is working with my clients. We're working on
  62. the next transaction in the business flow, which will be the 857 shipment and
  63. billing notice. Guess what - it's hierarchical too.
  64.  
  65. Regards, Bill Laidley
  66. EDI Expert Team
  67. BC Systems Corp. Vancouver (604) 660-9705
  68.