These tables are used in SAP to store IDocs:

• The table EDIDC – IDoc control record
• The table EDID4 – payload of the IDoc
• The table EDIDS – status records of the IDoc

Knowing these tables better will allow you to perform a number of useful evaluations directly from the database.

The table EDIDC – the IDoc control record

The table EDIDC contains the so-called control record. It contains basic administrative data for the IDoc. The most important fields are these:

• STATUS: the current status of the IDoc. This is also the last processing status from the list of status records (see below)
• DIRECT: the direction of the IDoc: 1 = output, 2 = input. This field of the control record enables filtering for incoming and outgoing IDocs
• the IDoc type. It is divided into two fields:
  • MESTYP: the message type and
  • IDOCTP: the basic type
• sender information: where did the IDoc come from?
  • SNDPOR: the sender port
  • SNDPRT: the partner type of the sender, e.g. LS=logical system
  • SNDPRN: the partner number of the sender
• receiver information: where is the IDoc going?
  • RCVPOR: the receiver port
  • RCVPRT: the partner type of the receiver
  • RCVPRN: the partner number of the receiver
• Timestamp of creation and processing
  • CREDAT: date of creation
  • CRETIM: time of creation
  • UPDDAT and UPDTIM: likewise for last update

This administrative data allows transactions such as BD87 (overview by status) or WE19 (search IDocs for business content) to search for IDocs of a certain type in a certain period of time.

Table EDID4 – the IDoc payload

The table EDID4 contains the IDoc payload. This payoad is divided into segments. Each line of the table contains one segment of the IDoc. The most important columns of the table are:

• DOCNUM: the number of the IDoc. This can also be found in the control record of the IDoc (table EDIDC).
• SEGNUM: the number of the segment within the IDoc
• SEGNAM: the name (i.e. type) of the IDoc segment. This is the name of one of the segments used in the IDoc definition (transactions WE30 und WE31)
• PSGNU: the number of the hierarchically higher-level IDoc segment (parent segement). This results in the nested hierarchy of an IDoc as shown e.g. in transactions BD87 (IDoc overview by status) or WE09 (IDoc search for content).
• HLEVEL: Hierarchy level: this is the amount of indentation in the hierarchical view of the IDoc in BD87 or WE09
• SDATA: the acutual application data (payload). This field is 1000 characters long. This character string cannot be used directly in an ABAP program. You must first assign this content directly to a variable of the correct segment type, this type is indicated in the SEGNAM column. You can then address the individual fields of this structure. This also means: if you want to write your own processing for a completely new IDoc type, then this assignment and processing takes a bit of ABAP code.
  

The following graphic compares the IDoc in the representation of BD87 on the left and the associated segment data taken directly from table EDID4 on the right. One data record is linked by an arrow as an example.

You can see in the IDoc that each segment has a name, the line type. These are defined in transaction WE30. Each line in EDID4 also knows its segment type. Segments 6 and 7 are subsegments of segment 5. On the left in the graphic you could click on node 5 to display these segments. Where sub-segments appear, the hierarchy level rises in EDID4.

The length of SDATA is central to the IDoc definition. This table definition limits the length of each segment to 1000 characters. This has an important consequence:

Suppose you expand an IDoc type over several years to hold more fields in order to meet new requirements, then the time may come when the segment can no longer be enlarged. In this case, you would then have to define another segment that accepts the new fields. This can then be time-consuming as you also might have to adapt the processing code to handle the new segments.

It is therefore worthwhile to be economical with segment expansions early. 4 fields with char255 already fill up the segment. Tidy up fields that you no longer need early.

Die Tabelle EDIDS – die Statussätze des IDocs

The table EDIDS contains the status records of the IDoc and thus the processing log. Each processing step of the IDoc generates one or even several lines.

The most important columns are:

• DOCNUM: the number of the IDoc. This is the same number as in the associated control record in table EDIDC.
• The timestamp of the log entry. It consists of LOGDAT , the date and LOGTIM the time.
• COUNTR: the sequential number of the log entry. This field also sorts the status lines by time.
• STATUS: the status value that was reached with this line. The status value of the last processing step can also be found in the control record.
• STATTTEXT: the message in full text. This is fed from the SAP message system:
• STAMID and STAMNO define which message template was used for STATTEXT. These are the message class and the message number from transaction SE91. Up to four parameters can be given here. These can then be found in the fields STAPA1 to STAPA4.

Here, too, a direct comparison helps to illustrate the relationship: Above is the IDoc as shown in BD87, below is the list of status records taken directly from the table EDIDS:

There is a separate line in table EDIDS for each status record from the IDoc display.

Direct queries on the IDoc database tables

As mentioned above, some evaluations of IDocs can also be made directly on the tables. Here are some examples:

You notice that an IDoc ran into a rare error and you wonder whether this error has occurred before, and if so, how often. The error was also logged in a status line in EDIDS. Get the message class and message number and check EDIDS for other occurences of these values.

Statistical evaluations are also possible. For example, a customer I work for, has built an import of orders from their webshop. The aim is to process these orders as automatically as possible. For a number of reasons, however, some IDocs are sent to manual processing. Maybe the postal address does not exist. Perhaps an article is not available, etc. Statistics are regularly calculated for the webshop import in order to achieve a consistently high level of automation. For this, EDIDS is evaluated directly.

Another interesting aspect is direct selection of IDocs based on IDoc payload (table EDID4). Transaction WE09 offers a lot of possibilities. But sometimes a direct selection on table EDID4 might also be an approach. There are some limitations, however:

Data table EDID4 is a so-called cluster table. This enables SAP to save this data in a space-saving manner. However, this also means that this column cannot be filtered for in the selection screen in SE16. So unfortunately, a *123456789* to search for this invoice number in the payload does not work.

However, you can select lines from EDID4 with SE16 (based on other criteria like message number, creation date etc.) and then filter the result in SE16 in the table display. Here the normal filter options from ALV grids are available. This works at least on that part of the SDATA column that can be seen in SE16. When the segments are too long, then the output rows will be clipped. But still SE16 on the IDoc payload may provide some insights.

When WE09 is not sufficient and the cluster limitations prevent your selection, then then you might try writing a specialized report for filtering. The table EDID4 states the segment type of the payload. You can use that to access the payload by correct type and filter for those fields that you are interested in.

One example might be: you have the suspicion that some records are missing in processing. You can then extract a list of processed orders direcly from the IDocs. This might help you to prove that these IDocs are already missing in the sending webshop.

You can find more articles about SAP here.