Guide to Troubleshooting IDocs: SAP Functional Consultant

There are some days that require a speedy resolution for something you don’t know. That something could be IDocs. I have been in that situation.

Back then, I have come across multiple jargons such as ALE, BAPI, and EDI. I will eventually make a blog post of these concepts (in relation to IDocs) but for now you can find some guides on how to troubleshoot IDocs below. Note that this is my personal guide so you can play around with the information and maybe create your own approach.

IDocs involve interfacing between one system to another and it is best to understand the scenario you are facing:

• SAP to SAP
• Third Party System to SAP
• SAP to Third Party System

The main purpose of an IDoc is to send out information or data. Thus, the concept of interfacing. Once you have narrowed down the scenario you are encountering, you can somehow find or piece together some information as seen in the “questionnaire” below.

1. Origin of the IDoc
2. (Supposed) Final destination of the IDoc
3. Purpose of the IDoc
4. Additional Details
   • When was the IDoc sent (date and possible time)
   • Actual data contained in the IDoc

Let us consider a scenario where a third party “employee expense system” sends out information to SAP to create a financial posting. We can then fill out our entries in the “questionnaire”:

1. Origin of the IDoc – Employee Expense System
2. (Supposed) Final destination of the IDoc – SAP (Production Environment)
3. Purpose of the IDoc – Sends out employee expense data to SAP to create a financial posting

Now assuming that this issue was reported an hour ago and the user explains that the financial posting is missing in SAP, you can get some more details by asking when the data was marked as confirmed (for example).

4. Additional Details

• When was the IDoc sent (date and possible time) – November 29, 2019
  • Actual data contained in the IDoc (some)
    • Amount
    • Vendor Number
    • Text Description of the item
    • GL Account
    • Reference Text

Having all these details, you can follow the analysis procedures below.

1. In SAP Production (final destination), go to TCode WE09 to search for the IDoc in concern

This is the most common case and it is usually done when you do not know the IDoc number in production. You can start by narrowing down the search criteria to the dates concerned.

If the results aren’t too heavy, you can add +- 1 day so you have more info and comparison.

Once you have located the IDoc, there will be an error status / message there to explain why it did not post. There are many scenarios for this so analyze the error message according to the business/company knowledge.

If it involves let’s say a blocked vendor number, then you can clarify with the business on this blocking. However, if it involves a “nonexistent” vendor number, you may want to check on the IDoc segments to see what data it tagged as a vendor number. I have experienced cases wherein the wrong information was sent (i.e. GL Account as Vendor Number).

By seeing the error message, you should by now know what you need to do to fix the issue but if it is still unclear, there are other details as you read further.

You can take note of the IDoc number and search accordingly in Tables EDIDC, EDID4, EDIDS. Here you can get a summary of the structure and IDoc details.

2. Find a successful IDoc posting (with similar structure) with WE09 and do comparison with the erroneous one.

You can still use WE09 for this. From the example above, you should have an idea of the expected IDoc structure. Let’s say if you are expecting an accounting document posting, you can search basic type as “ACC_DOCUMENT01” and search for a recently posted successful IDoc with status 53. Another basic type example is “INVOIC01” if you are expecting an invoice posting.

Notice also how I narrowed down the results to indicate Direction “2” as inbound.

If you happen to know the segments of the IDoc, you can use that to narrow down the search even more by filling up the fields below (WE09)

3. Replicate the issue in a test environment through WE19 and do some testing (if needed)

In the test environment, you can find an existing successful IDoc with similar structure (basic type) through WE09, copy that IDoc number, and use it for TCode WE19. This is the IDoc Test Tool. You can copy from a reference IDoc or Basic Type.

Once you click on execute, you can double click on an entry to update the details and pattern it after your reference IDoc.

When all details have been entered and you are ready to create your test IDoc, recall if the scenario is an outbound or inbound scenario. Since our example involves data coming from a third party system to SAP, it is an INBOUND to SAP scenario.

Since the inbound scenario is confirmed, click on test inbound function module.

Here you need a function module to simulate / process the IDoc you are creating.

If you do not know the function module concerned, you can cross reference Tables EDIFCT and EDCIM. There will be a field there that shows what function module is used for the IDoc processing.

4. If there is a need to reprocess the IDoc, you can do so through TCode BD87

Take EXTRA CAUTION in doing this step and know the company or IT processes for this. You can reprocess the IDoc foreground or background but remember to select the “restrict and process” option.

Other Considerations

Retention Period

There are concerns wherein an IDoc has a “retention” period of n days/months/etc. depending on the setup agreed with the business so it is possible that you may not locate the IDoc. Thus, ruling out your quickest chance at finding a concrete basis. Your best bet now is to try and replicate the scenario in QAS or maybe try on using WE10 (click on Data Source…) to see if the IDoc can be found in the Archive.

Basic Data Flow

The basic flow of an IDoc involves an (1) Origin System, (2) PI/XI, and (3) Destination System as seen in the diagram below. The origin system sends out the data and it gets received by PI/XI (Process Integration or Exchange Infrastructure). Think of PI/XI as a middle man that gets the data and determines what it should do with the data. If all is okay, PI/XI will send the data to the Destination System where it can be found as an IDoc. Note that PI/XI usually deals with IDoc-XML file types so you can expect the origin system to send an .xml file. When it reaches the destination system, it will be shown in IDoc format.

Expected IDoc is Missing

If it so happens that you cannot find the IDoc in the destination system and you are able to provide proof that the origin system sent the data, it is possible that the error can be on the PI/XI level. I have encountered cases where connectivity was down so there was a delay on the processing and sending to data to SAP. There have been cases as well wherein the origin system was not sending data in the proper “format”. Thus, encountering ‘rejects’ from PI/XI. There are more cases but these are the usual issues I have encountered that involve “missing” expected IDocs in the destination system.

System Behavior to Wait on SAP’s confirmation

Some system architectures / behavior involves the third party system waiting for a ‘confirmation’ communication from SAP to determine if the IDoc has successfully posted or encountered an issue. If that is the case, then it is possible that it stores the IDoc details in a database or report. If you have access to those, you can try to check on them.

• If SAP returns a status of 53, it means that the IDoc has successfully posted and it is possible that SAP will send the corresponding generated accounting document and IDoc number.
• If SAP returns some other IDoc status and IDoc number, you can go ahead and quickly check on it through TCode WE10 or WE09. This is of course a quicker approach since you know the IDoc number in concern. At this point there is no need to try and find the IDoc through ‘context clues’.

I have the Accounting Document Number but I want to find the IDoc

This entirely depends on the system interfacing design and architecture. Here are some possibilities below:

1. IDoc number will be found in the “relationship browser” of an accounting document
   • You can view the posted document via FB03 and click on Environment > Document Environment > Relationship Browser
2. IDoc number will be found in Table EDIDS Technical Field STAPA2 by searching on the accounting document number. Remember to use wildcard for this to make sure it pulls the search.
   • Use wildcard symbol (*). Example: “*123456*” since it is possible that the accounting document is stored as “00123456COCD2019” where COCD is the Company Code and 2019 is the Fiscal Year.

Summary of Tables and TCodes used

Table / TCode	Description
WE09	Search for IDoc Content
WE10	Search for IDoc including Archives
WE19	Test Tool for IDoc
BD87	Reprocess IDoc
EDIDS	Status Record (IDoc) – You can search for Tech.Field STAPA1 here
EDIFCT	IDoc: Assignment of FM to log. message and IDoc type
EDCIM	Extensions – Extension, Linked With, and Description fields may be helpful
EDIDC	Control record (IDoc) – Summary of control records with Message Type and Receiver/Sender Ports
EDID4	IDoc Data Records from 4.0 onwards – You can view IDoc segments here if needed

Inbound IDoc Status Summary (Detailed list can be found here as well: Link )

• 51 inbound IDoc data contains errors
• 53 inbound IDoc posted

Summary of Steps and Considerations

1. In SAP Production (final destination), go to TCode WE09 to search for the IDoc in concern
2. Find a successful IDoc posting (with similar structure) with WE09 and do comparison with the erroneous one.
3. Replicate the issue in a test environment through WE19 and do some testing (if needed)
4. If there is a need to reprocess the IDoc, you can do so through TCode BD87
5. Other Considerations
   • Retention Period
   • Basic Data Flow
   • Expected IDoc is Missing
   • System behavior to wait on SAP’s confirmation
   • I have the accounting document number but I want to find the IDoc