There is often confusion and misunderstanding around who is responsible for the various parts of an EDI enabled process.
There is a common misperception that EDI is "technical" and that functional folks or the business are not involved. Nothing could be further from the truth...
We will use a customer and supplier enable EDI process to describe who should do what... First up, a customer facing process.
An outbound EDI message to a Customer (E.g. Customer Invoice - 810 message)
(1) The EDI technical team is responsible for the following:
Developing the mapping template.
Mapping of the IDoc (e.g. INVOIC) to the corresponding X12 (e.g. 810) or EDIFACT message.
Transmitting the EDI message to the partner via a VAN, AS2, sFTP, ...)
Receiving the EDI acknowledgement (997) back from the customer and processing it back to SAP (via STATUS IDoc)
Process any technical issues while trying to communicate the message to the partner. E.g. syntax errors, communication error
(2) The responsible business team (e.g. Accounts receivable for the Invoice) is responsible for the following:
Understand the needs of the customer in terms of EDI - Note: A customer typically dictates the format and content needed in the EDI process. They communicate their needs to us by means of a published EDI implementation guide.
Process any functional errors that are received (typically via workflow) for the outbound message (IDoc in status 51). These are functional issues and relate to the requirements set out by the customer in their EDI specs (Log in to our Documents section to see example templates and guides)
An inbound EDI message from a Customer (E.g. Customer PO - 850 message)
(1) The EDI technical team is responsible for the following:
Developing the mapping template.
Mapping of the IDoc (e.g. ORDERS) from the corresponding X12 (e.g. 850) or EDIFACT message.
Receiving the EDI message from the partner via a VAN, AS2, sFTP, ...)
Sending the EDI acknowledgement (997) to the customer
Process any technical issues while trying to post the message to SAP. E.g. syntax errors, bad partner profile.
(2) The responsible business team (e.g. Sales rep for the Sales Order) is responsible for the following:
Understand the needs of the customer in terms of EDI
Process any functional errors (E.g. missing PO number) that are encountered (typically via workflow) for the inbound message (IDoc in status 51). These are functional issues and relate to the requirements set out by the customer in their EDI specs.
And for a supplier process it is somewhat similar...
An outbound EDI message to a Supplier (E.g. Purchase Order - 850 message)
(1) The EDI technical team is responsible for the following:
Develop the implementation guide together with the business to encapsulate all the requirements for a smooth EDI process. Note: A good EDI process is only as good as the manual execution of the process in the system. i.e. If you have a poor business process then EDI won't fix it! In fact it may make it worse because it will highlight the issues more frequently. (Log in to our Documents section to see example templates and guides)
Developing the mapping template.
Mapping of the IDoc (e.g. ORDERS) to the corresponding X12 (e.g. 850) or EDIFACT message.
Transmitting the EDI message to the partner via a VAN, AS2, sFTP, ...)
Receiving the EDI acknowledgement (997) back from the customer and processing it back to SAP (via STATUS IDoc)
Process any technical issues while trying to communicate the message to the partner. E.g. syntax errors, communication error
(2) The responsible business team (e.g. Procurement for the PO) is responsible for the following:
Understand the EDI process and what was asked for in the EDI implementation guide - Note: We typically dictate the format and content needed in the EDI process to a supplier.
Process any functional errors that are received (typically via workflow) for the outbound message (IDoc in status 51). These are functional issues and relate to the requirements set out in our EDI specs. E.g. missing terms or carrier
An inbound EDI message from a Supplier (E.g. Supplier ASN - 856 message)
(1) The EDI technical team is responsible for the following:
Develop the implementation guide together with the business to encapsulate all the requirements for a smooth EDI process.
Developing the mapping template.
Mapping of the IDoc (e.g. DESADV) from the corresponding X12 (e.g. 856) or EDIFACT message.
Receiving the EDI message from the partner via a VAN, AS2, sFTP, ...)
Sending the EDI acknowledgement (997) to the customer
Process any technical issues while trying to post the message to SAP. E.g. syntax errors, bad partner profile.
(2) The responsible business team (e.g. WH rep for the Inbound Delivery) is responsible for the following:
Understand the EDI process and what was asked for in the EDI implementation guide
Process any functional errors (E.g. missing tracking number or SCAC code) that are encountered (typically via workflow) for the inbound message (IDoc in status 51). These are functional issues .
That was easy :)
Note that the business folks are the most qualified to address functional issues found in the EDI process. The EDI team should not be responsible for correcting functional errors as they relate to business transactions. If the business is truly engaged and take ownership of the EDI process then there should be no problems addressing any issues.
With that being said you may begin to get a sense that EDI is far less technical than you would expect. I would suggest that 80% of the EDI process is business related. Business owns the partner relationship, executes the contracts, has the power to enforce compliance, decides on what functionality to provide to partners, verifies the validity of transactions, and finally.... they are the ones who hurt more if the EDI process does not work! Business should own the EDI process and the EDI team is an enabler for the process.