In retrospect, aligning the available interfaces with business processes from the outset was a smart move on the part of SAP. Today, for example, there are a number of available IDoc interfaces for each SAP release, which are defined on the basis of ISO 9735. This ISO standard not only regulates the naming of the individual business processes (ORDERS, DELFOR, DESADV, INVOIC, etc.) but also adopts framework parameters such as maximum field lengths etc., which today are also used internationally in identical form in global standards such as UN/EDIFACT. Each IDoc interface exists in different versions, with the highest version number corresponding to the maximum amount of data available. When implementing new EDI partners, SAP users are therefore always well advised to use the highest IDoc version number currently available for EDI data exchange. This ensures that the EDI data pool created via IDoc contains the most content possible, and the likelihood of still having to supplement the data pool with Z-IDoc records is minimized. EDI integration of incoming processes such as ORDERS usually involves populating all mandatory fields defined as MUST with the contents of the corresponding EDI documents in order to ensure further processing of the process in SAP ERP. Partner-specific information that is provided in the EDI message but is not part of the process-related core information and is irrelevant for processing the process in SAP can be ignored throughout and does not have to be used to populate the incoming SAP IDoc. For outbound processes, DESADV and INVOIC, a large amount of EDI data elements is usually needed to meet the semantic requirements of the EDI data recipient. Here, the use of a high IDoc version number ensures that the available amount of information is sufficient for generating the outgoing messages.

In addition to the need to supply the various common EDI formats and processes via SAP IDoc interface, today we also sometimes come across the requirement to connect EDI exchange partners directly via XML IDoc files as part of an EDI communication. This necessity results primarily from the use of SAP modules such as SNC (Supplier Network Collaboration), whose interfaces require direct input from XML IDocs. Many large market participants from, e.g., the pharmaceutical sector, refrain from equipping these XML IDoc interfaces with an upstream EDI system. Instead, suppliers are required to deliver the desired XML IDoc files to the SNC module or to process their output. The increasing spread of e-procurement systems and e-procurement and e-invoicing service providers also supports this trend, as they either originate from the SAP world—such as Ariba—or operate close to SAP.

Given this fact, it is easy for SAP users to come to the conclusion that only corresponding XML IDocs need to be generated or processed in order to connect EDI partners, who in turn also participate in the EDI data exchange using SAP XML IDocs. In this scenario, only EDI routing without conversion would then be required to connect the relevant partner or the desired platform. In practice, however, this approach is often doomed to fail, since the required XML IDoc structures usually have application-specific properties that cannot be mapped by standard IDocs but only through difficult internal IDoc parameterizations. SAP users, therefore, usually have to use an EDI subsystem to generate an XML IDoc message that meets the requirements of the EDI data recipient from the independently generated XML IDoc.

The IDoc message type SYSTAT is especially important. The Softzoll EDI solutions can optionally generate a corresponding SYSTAT for each XML IDoc generated from SAP and report it back to the SAP system. The SAP user is then shown a traffic light mode display in the ALE monitor, indicating the current processing status of their XML IDoc. This allows SAP users to check the processing status in the EDI subsystem without having to leave their familiar SAP environment and needing to use monitoring third-party systems.