Mungapen SAPLOG

A client of mine was performing data conversions using  LSMW to load open purchase orders from a legacy system.  a number of these failed to load for various different reasons. Fortunately they had used the idocs to load these legacy PO’s  and the BD87 display shows by error reason why the different idocs have failed. however this is not an excel friendly format to hand to the business and tell them to review the errors.   As these POs’ never hit SAP they didn’t have PO numbers but they did have their legacy PO numbers held in the requirement tracking number field.

I  immediately thought that we should be able to right a quick ABAP query to give them the necessary data to the business to correct the legacy data prior to reloading. This technique could be used to create an excel friendly list for any information in an idoc

Using the SQ02 transaction I created an info set based around table EDIDC which is the idoc control table.

This table holds the basic type, and the current status (which for all failures is 51). however it doesn’t hold the detailed failure messages that indicate why the IDOC failed to load.

These are held in EDIDS. Creating a join based on the idoc number and the status (51 from EDIDC

The join should look like this

This would be good enough to show you all the failed idocs and the reasons why, however the users need to link these records back to their legacy system PO’s. Hence we also needed to pull some information form the actual idoc segments. This would require linking to table EDI4. however this is a huge table and we only want to pull specific information from a specific IDOC  segment. Using transaction WE60 for IDOC  documentation I can find that for my basic type (PORDCR05) the segment where the requirement tracking number field is held is in  idoc segment E1BPEKKOA in a field called Sdata.

I could join EDId4 to my query, however this is a large table and I only ever want to pull out the segment E1BPEKKOA so it is better to add an additional field to the query. Further more the Sdata field is a long  fixed width data field holding many field values. Again checking We60 I can determine that the requirement tracking number field starts at the 90th character and continues for 12 characters.

Adding the following selection logic to this additional field which I called 

ZE1BPEKKOA will select the correct record from EDID4  then parse out the 12 characters starting at position 90.

 

clear ZE1BPEKKOA.
select sdata from edid4 into ZE1BPEKKOA
where DOCNUM = edidc-docnum
and SEGNAM =’E1BPEKKOA’.
endselect.
data l_str type char20.
l_str = ZE1BPEKKOA+90(12).
ZE1BPEKKOA = l_str.

This logic could  easily be edited to select info from different segments or different positions