SAPFree generatorPDF, Excel, Word exportSAP ECC / S/4HANA

SAP ABAP IDoc Status Query Generator

Support teams often need a quick list of IDocs stuck in one status, with the reason. This generator writes the ABAP to select them from EDIDC and pull the matching status record from EDIDS.

Fill in

Generated code
Download:

IDoc status report

REPORT ZR_IDOC_ERROR_LIST.

TYPES: BEGIN OF ty_idoc,
         docnum TYPE edidc-docnum,
         status TYPE edidc-status,
         mestyp TYPE edidc-mestyp,
         idoctp TYPE edidc-idoctp,
         sndprn TYPE edidc-sndprn,
         rcvprn TYPE edidc-rcvprn,
         credat TYPE edidc-credat,
         cretim TYPE edidc-cretim,
       END OF ty_idoc.

DATA: lt_idoc   TYPE STANDARD TABLE OF ty_idoc,
      ls_idoc   TYPE ty_idoc,
      lt_status TYPE STANDARD TABLE OF edids,
      ls_status TYPE edids,
      lv_from   TYPE d.

lv_from = sy-datum - 7.

SELECT docnum status mestyp idoctp sndprn rcvprn credat cretim
  FROM edidc
  INTO TABLE lt_idoc
  WHERE mestyp = 'ORDERS'
    AND status = '51'
    AND direct = '2'
    AND credat >= lv_from.

IF lt_idoc IS NOT INITIAL.
  SELECT * FROM edids
    INTO TABLE lt_status
    FOR ALL ENTRIES IN lt_idoc
    WHERE docnum = lt_idoc-docnum
      AND status = lt_idoc-status.
  SORT lt_status BY docnum ASCENDING countr DESCENDING.
ENDIF.

LOOP AT lt_idoc INTO ls_idoc.
  READ TABLE lt_status INTO ls_status WITH KEY docnum = ls_idoc-docnum.
  WRITE: / ls_idoc-docnum, ls_idoc-credat, ls_idoc-cretim, ls_idoc-sndprn, ls_status-statxt.
ENDLOOP.

Quick status guide

02: error passing data to port. 29: error in ALE service. 30: IDoc ready for dispatch. 51: application document not posted (inbound error). 56: IDoc with errors added (identification of partner failed). 64: IDoc ready to be passed to application. 69: IDoc was edited. Current direction filter: 2 for message type ORDERS.

For very large systems add an index-friendly condition such as CREDAT and a narrow MESTYP, and avoid SELECT * on EDIDS in production. The status text in EDIDS can contain placeholders filled from STAPA1 to STAPA4, so use message class and number with FORMAT_MESSAGE when you need the full text. Check field names in SE11.

Want IDoc failures summarised for you?

Optional: discuss a read-only assistant that explains IDoc errors in plain language for your support team.

Optional. The tool and every export work without this. No spam.

How to use the generator

Pick the message type, status and direction, set how many days back to search and copy the code into a report. The result lists number, partners, creation time and the status text. Extend it with ALV output or a mail step if the team wants a daily error digest.

How the tables relate

EDIDC has one row per IDoc with its current status. EDIDS has one row per status change, numbered by COUNTR, so the newest entry for a status has the highest counter. The report reads the current status from EDIDC, then looks up the matching rows in EDIDS and sorts by counter descending to get the latest message. Segment data is in EDID4 and can be joined by DOCNUM when you need to filter on content.

Common statuses to monitor

Most teams watch a short list: 51 for inbound application errors, 56 for unknown partner or profile problems, 02 and 12 for transfer errors, 30 for stuck outbound and 64 for inbound waiting for a job. A dashboard that counts these by message type and age shows backlogs before users call.

Common mistakes

Selecting without a date filter on a table with millions of rows is the classic performance problem. Another is reading EDIDS without the counter and picking the oldest status text instead of the newest one.

Frequently Asked Questions

Which table holds the error message of a failed IDoc?

Table EDIDS holds the status records, including message class, message number, text and up to four parameters. The latest row for the IDoc number, highest COUNTR, usually contains the current error. WE02 shows the same information on screen.

Why use FOR ALL ENTRIES and check for an empty table?

If the driver table is empty, FOR ALL ENTRIES in ABAP selects every row of the target table, which could be millions of status records. Always guard the second SELECT with a check that the first result is not initial.

How can I reprocess the IDocs I found?

For inbound errors, call program RBDAPP01 or RBDMANI2 for the selected numbers, or use BD87 for a manual run. For outbound ones use RSEOUT00. Always fix the cause first, otherwise they fail again with the same status.

Is it safe to run this in production?

It is read-only, so it changes no data, but a poorly restricted SELECT on EDIDC can still load the database. Always keep the date and message type filters, and run large analyses outside peak hours or in a reporting copy.

Netray can build a private assistant that answers questions like which IDocs failed yesterday and why, straight from your SAP tables. Ask for a review if that would help your support team.