IDOC Management and Error Handling in SAP S/4 HANA
“For every process, an IDOC”. That’s the sales pitch from SAP, and there is no doubt that IDOCs offer a useful way of linking two different systems and passing data between them. This is useful in Electronic Data Interchange functions (EDI).
Processes within the same system can also be managed via automated IDOCs too.
So what is an IDOC? The acronym stands for “Intermediate Document” and is simply a container which houses data and is passed to another function either within the same system or to another system. Both inbound and outbound IDOCs are supported in SAP.
The IDOC itself is made up of three tiers:
Tier 1 – The Control Record
The control record shows you the direction, basic type and message type of the IDOC. It also shows you the sender and recipient partners.
Tier 2 – The Data Records
The data records houses all the segments of the IDOC. Each segment contains data which is used in the recipient system to fulfil the process in question.
Tier 3 – The Status Records
Shows all the status records which the IDOC has gone through in its lifetime, in reverse chronological order.
So where can you see IDOCs in the system? There are numerous places in S/4 where you can see IDOCs. A traditional ECC6.0 approach uses area menu WEDI, which is also available in Fiori.
From WEDI, a functional consultant can define all EDI processes through IDOC management. There is plenty of documentation out there as to how the EDI process can be configured; this blog post does not cover that area.
Traditional approaches to error handling in IDOC management will use transactions such as WE02, WE05, WE09, WE19 and BD87. This can be frustrating navigating between the various transactions for a Help Desk analyst who is trying to identify errors.
However, SAP S/4 HANA has addressed this and offers an improved version of all these with transaction WLF_IDOC (Fiori app “IDOC processing”):
This app acts as a cockpit for all the former ECC6.0 transactions mentioned above. All varieties of selections are available here on the various tabs on the selection screen. The “Criteria for data record” can be used to search within segments for specific data (as is possible in the traditional WE09 approach).
From this cockpit, you can navigate directly to the IDOCs and execute all the functions you require.
Functions of the new app:Details icon: Details icon:
1. Display IDOC
This icon shows you a summary dialog box with the details from the Control record:
2. Display IDOC:
This opens up the IDOC in a new style view from the traditional views in WE02, WE05 or BD87. The control data record is not shown as this can be seen from the Details icon (see above). Instead the IDOC segments are shown on the left and details are displayed in the bottom right section of the window. The Status Record of the IDOC is shown in the top left and can be hidden.
3. Edit IDOC:
This is the same as the display function but the segments are available for editing.
This allows you to process the IDOC in the event of the IDOC being as yet unprocessed, or in error state. The options displayed when hitting the “process” button are Online (process the IDOC in the foreground), dialog BD87 (process the IDOC using the traditional BD87 route) or background (process the IDOC in the background).
5. Change View:
This option controls the layout of the view of the IDOCs. The options are:
Selecting “by Status” will group the entries by status as below. In this example, we have one IDOC in error status (status 51) and three with status 12, dispatch OK. These are grouped on the right-hand side by message type.
Selecting “by Type” instead of “by Status” will group the IDOCs the other way around.
6. Send IDOC via RFC
This option allows the IDOC to be sent out to a specific RFC destination. Spot the standard SAP spelling error!
7. Compare IDOC
This is a really useful tool to compare two IDOCs (such as the two above) which look the same but one has failed. In the event that the status message you receive from SAP against the failed IDOC is not necessarily enough to identify the error, you can list out the differences between a successful IDOC and the unsuccessful one and go through each segment to see where you have an issue.
8. Change Control Record:
Does exactly what it says on the tin – you can use this function to change the control record of the IDOC.
9. Copy IDOC and Delete Segment
Here you can create your own copy of an existing IDOC with a specific segment deleted. SAP will ask you for the segment name when you hit this option. There is a similar option in the “More” functions to run the traditional WE19 option to create a copy version of the IDOC:
10. Change the status of an IDOC
Fairly often, if an error in an IDOC is manually corrected in the document, the IDOC status should be changed to reflect that. In the past, this had to be done by running programs such as RC1_IDOC_SET_STATUS. However, by selecting this option, SAP allows you to amend the status in the IDOC (normally to status 68 – “Error – no further processing”):
So who should run the IDOC error handling functions within your business? This is really a question only you can answer. Accepted wisdom suggests that if your use of ALE and EDI technology is relatively light, then the monitoring process can be handled by your SAP help desk. However, normally if companies use IDOCs, then they are too numerous to handle within the IT arena. My advice would be as follows:
- Set up or allocate an existing team with the authorisation to display, edit, change the status and reprocess IDOCs. This team should be a centralised function and be comprised of “super users” within your organisation.
- Set up a custom Fiori tile with a function module in the background which runs a variant of WLF_IDOC to show all IDOCs in “error” status. The function module should show the number of errors on the front. This will enable the centralised team to see immediately how many IDOCs need addressing without having to run reports. It also means that you do not need to go to the effort of setting up workflow processes in SAP to email users in the event of failed IDOCs. The dynamic Fiori tile should look something like the following:
- Any error messages which cannot be resolved (and you will inevitably get these) should be passed by the centralised team to the IT team to handle.
- The aim should be to keep the number of error IDOCs at zero. Any which cannot be resolved should be manually addressed in the documents and then the IDOC status amended to 68.
- Once ALE/EDI processes are in train, the monitoring of the errors must begin immediately.
If handled correctly, IDOC management can revolutionise your business, streamline your process flows and allow a greater degree of automation of key functions.