EDI System Design Part II - Export Mapping

I'm not going to go into the details of creating the text of EDI (Electronic Data Interchange) messages in certain formats. Well not in this post anyway. It is a big subject and the last post was long enough. What I am trying to do is lay out the System Design and APIs.


So you have a routine in your ERP system that created a document or a transaction e.g. a Sales Invoice. The options you have are,

1. Edit the routine to - Check EDI control. Pass the document to a export mapping routine. Store the returned EDI message in a folder for later batched communication.


2. Edit the routine to - Check EDI control. Store the document reference in a folder for later batched export mapping and communication.


3. Create an external routine to - Periodically select all unchecked documents. Check EDI control. Pass the document to a export mapping routine and communicate.

If you don't have access to your existing source code then your only option is 3. If you do have access to the source code you may still want to do option 3. There is less chance of introducing error and, in these days of Sarbanes-Oxley, the administrative work in getting changes approved, in something like an invoicing routine, must be considered. It doesn't mean you can't move to option 1 or 2 at a later date.


For traditional EDI formats (e.g. EDIFACT, TRADACOM etc.) there will be sections of messages that are common to several documents. Consider the senders address. For each document, this will probably be read in from the same place. The format may say addresses must be presented in a certain way. The first line of the address may be limited to a fixed number of characters but our system allows longer lines. We can't chop off the end of lines, so we will have to move the excess to the second line. This isn't that difficult a task but we don't really want to have to type out this code several times, testing and debugging each one. And if a format version change means a code change is required, then a small task will have just turned into a code hunt.

For all these reasons we want a single export mapping routine per format. Things like, senders address, can then be a single local function or subroutine. One of the calling parameters is document type. The next calling parameter will be a list of documents objects, or pointers to documents - probably the key fields in our SQL table. The returning parameter will be a list of formatted EDI documents. The calling program can then take care of writing to the pending folder or passing them to the communication routine.

There is one other less obvious parameter needed by the export mapping routine and that is the Communication Type data. Even though we have designed a system to separate mapping form communication, this flag is still needed. The reason is envelopes and addressing. Especially in traditional EDI formats, the message document is not complete without an envelope wrapper and we will need the communication type.


Part I