EDI System Design Part I - Message Control

Assuming you have an ERP system that processes sales orders, invoices, remittances, stock balances etc. how do add EDI (Electronic Data Interchange) capabilities? The first thing we need is to decide what is going to whom, in what format, by what means.

Let us suppose we want to start sending Sales Invoices to a key customer. The routine that will create the EDI invoice could be called from the ERP routine that does the invoicing, or it could be called from a periodic routine run sometime after. We will need a EDI Sales Invoice Control screen.
Customer:
Message Format:
Protocol:

Suppose we want to start sending Order Acknowledgements. We would have to create a similar screen. To avoid this, we add a Document field. Suppose the standards body releases a latest version of the message format. Some of our partners start to use it. Some stick with the old version. We could add a Format Version field or incorporate the version in the format.
Document:
Customer:
Message Format:
Message Format Version:
Protocol:

Some customers will have multiple branches or delivery points. I warn you from experience, there is a high probability that customer A only has half their branches EDI enabled, while customer B will have all branches enabled. So customer can't be the group account and must be the branch account.

Now a key supplier want us to send our purchase orders, so we add a Supplier field. One of, Customer or Supplier, must be entered. Next the taxman wants our sales tax information. Is he a customer or a supplier? Neither really. With luck you will have a Contacts file that incorporates all these entities and you can use that identity. Otherwise we need a Contact Type field (answer customer/supplier/third party) and Contact ID.
Document:
Contact Type:
Contact ID:
Message Format:
Message Format Version:
Protocol:

Some Document, Format and Protocol combinations will be compatible with immediate delivery e.g. sending purchase orders by email PDF attachment. However some formats are designed for batching up several messages into one. Also a partner might want a steady trickle of messages through the day and prefer one combined message say, once a day or once a week. If you are communicating by Dial-up (facsimile or point-to-point) there will be savings if messages can be combined. To achieve this we need to add a Batched Y/N option. If 'Yes' then the document ID is placed in a pending file to be translated and communicated at a later time.

At last we come to Protocol. We can't just store FTP, HTTP, SMTP, P2P etc. in each case we require more information e.g. URL, user name, password, phone number, alternative phone number. When you have a partner with lots of branches but central communication, this would mean a lot of repeated set up. It would also make batching very difficult because we would have to check every field.

The solution is another level of abstraction. We create a concept of Communication Type and this points to another screen where the additional fields are stored. Then, when Acme Widgets have all their stores documents going through one VAN mailbox, we only have to store the Communication Type identity.

So finally we have...
Document:
Contact Type:
Contact ID:
Message Format:
Message Format Version:
Batched? Y/N:
Communication Type:

Update - I was trying to keep this post as short as possible, but it just keeps on growing. I realised I missed another field. There some other pieces of information that you might need. Examples are where a customer wants EDI invoices but only for orders raised by EDI. Or the customer prohibits amendments to EDI sourced orders. Or the Trading Partner requests special formatting of a reference used in the message. There could be a need for several flags for minor functionality. Rather than clutter this screen with more fields, I tend to add a generic "Options" list on a sub screen.

Part II