I am on a project to add EDI to our billing system. This will allow us to bill and receive payments from our largest trading partners. However, our client would like to open this option to all our trading partners, if possible. How can I justify using XML when our company already uses EDI in other departments?
Originally posted by Tim Podolske: I am on a project to add EDI to our billing system. This will allow us to bill and receive payments from our largest trading partners. However, our client would like to open this option to all our trading partners, if possible. How can I justify using XML when our company already uses EDI in other departments?
Explain that XML is the "next generation" of EDI. You can read/write it in near-english with much easier-to-read syntax and easier-to-understand grammar. The fact that the metadata describing the data is included in the XML is a big factor in building/parsing/debugging. Also, think about this: You can build your XML to include critical pieces of information about the transmission. For example, the simplest thing to do is whatever process sends the information can insert a 'trasmittedAt' date/time tage into the XML just before sending, and the receiver can do the same for 'receivedAt'. Then, if the XML file date changes for some reason, you still have the transmission information. You can also capture other characteristics, such as what machines were involved in the sending/receiving. If you have middleware that does processing, you can record what/when/who did it, and the results can be appended or inserted into the XML file before reaching it's final destination. This brings up the point that a single XML file can be routed through different apps to add different information, and when reaching it's destination after transmission, it's easy for multiple apps to process it and skim the information they need from it. One such process might be an enterprise information system and workflow. A received XML could be parsed once by the EIS to retrieve just the product counts and sales amounts for the execs, then a workflow process could parse it looking for who/where to route the file to, then when it arrives at it's final destination the user's app can read it and perform the appropriate processing and request the appropriate input. You can't do that with a record-layout based file that only contains data, or at least not easily. XML is much more flexible. Hope this helps!
CJP (Certifiable Java Programmer), AMSE (Anti-Microsoft Software Engineer)
Author of Posts in the Saloon
hey tim, is it EDI in text format, ? if it is so it's easy to convince them,, let me know
posted 17 years ago
Thanks for all the information, Gerry. I really appreciate your time. As to Ravi's question, this is all I know about the files: we will use the ASC X12N 811 for the transmittal file, and the ASC X12N 820 for the payment file. In fact, the EDI specialists within our organization haven't even shown us the file structure. They are waiting for us to formally declare that we will use EDI. Then, they will order the manuals and send us a spreadsheet interpretation of the two files. Tim