SAP IDoc—the standard EDI structure in the SAP universe
The standard SAP data structure known as IDoc or Intermediate Document is a manufacturer-specific interface that is used in almost all known SAP versions. The structured interface is intended for data import and export and occupies a special position not only within the SAP world, but also for the higher-level EDI data exchange. The IDoc interface also plays an exceptionally prominent role with respect to use in the context of electronic EDI data communication from SAP-to-SAP and SAP-to-non SAP-ERP or EDI subsystems.
The basis of the entire data exchange procedure is SAP’s own ALE (Application Link Enabling) functionality, which was originally designed for exchanging IDoc files between different SAP systems. The first SAP IDoc interfaces were designed as flat files, a technology that was quite state-of-the-art at the time. Today, however, the IDoc files can be defined as XML IDocs with a few mouse clicks within the SAP partner profiles; an approach that brings numerous advantages for EDI implementations.
Softzoll supports all interfaces and EDI functionalities provided by SAP
Current EDI projects in the SAP environment therefore mostly use XML IDocs, as associated XML schemas are available for each business process in the form of *.xsd files. The XML schemas represent a kind of blueprint of the EDI business process-based SAP interfaces. This procedure enables the upstream pre-SAP EDI subsystem to take into account the maximum specification of the respective business processes, including the structural design of the IDoc document in the form of segments etc., right from the start.Even for individually parameterized Z-IDocs, there is a command within the SAP system with which the standard IDoc extended by Z-segments can be output as an *.xsd file (Transaction WE60 -> Menu Documentation -> XML Schema or DTD). All Softzoll EDI solutions have a functionality to import SAP native XML schemas directly into any EDI workflow and make them usable for the integration of SAP ERP systems via SAP IDoc interfaces.
The SAP XML IDoc interface at a glance
Click on the screenshot to enlarge
SAP users should always use a current IDoc version number
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.
This post is also available in DE.