One of the requirements for integration with a 3rd party system on my latest project was to cut some standard segments from idoc. Why? Basically it was due to the nature of the 3rd party system, they never read those segments and having them generated errors in their processing. Of course we can do it in non standard way through enhancements or during the conversion in the PO/SIS middleware, but is there actually a standard configuration that achieves it?
Since SAP created this technology, for sure there is a standardized approach to such a basic task, and it is well defined right? .... Right?!
Since we were working with deliveries at that time, my first look was at the IDOCTYPE_READ FM, with the DELVRY07 idoc as the test subject. This one is responsible for “Basistyp lesen” which as you can guess is responsible for reading the basic type of idoc. In particular what kind of basic type we are going to use and all of the segments and extensions for it, taking the information from the tables IDOCSYN and CIMSYN.
There are some more tables checked in this FM, however they are there only to help to link all of the data from the configuration of WE20 till the last segment/extension. Unfortunately in the ideal place, which was there “MERGE_IDOC_WITH_EXTENSION”, there is no standard configuration or user exit that can be used to achieve what we wanted. Next possibility comes in PERFORM SEGMENTS_TO_READ_SET and this one had a badi spot
A bit better, but still no ideal. Especially since it was limited by case switch to few segments. Afterwards in the code, there were more designed extension points, however they were after the data has been already drawn and the segments were created based on it. This was a no go, since we already wasted precious resources to build the segments, so removing them at that moment was stupid. You would thought that it would be the same for all of the idocs, especially since it is a SAP creation… Maybe it’s just not here, but there has to be some kind of standard approach for it in others, right? There are 129 FM for idoc outputing from the group IDOC_OUTPUT, and much more in the MASTERIDOC group and some of them are following a configuration table TBD24 and FM IDOC_REDUCTION_FIELD_REDUCE. This approach, If you want to know how to use it, its written in the sap documentation, but basically it follows BD53 tcode [1], where for the types defined in the documentation (and only those so forget about Z types), you can select which fields and segments to reduce, assigning them to a new message type.
Unfortunately this basically is all that SAP propose. In the end in my scenario we did it on the SIS, since with object mapping its easy, you can simply not connect few segments or fields you don’t want to and be done with it
However this approach generate some useless data and burdens with it the bandwidth of both SAP and SIS. Nevertheless it’s the quickest and most reliable of them all.
Conclusion
Even though IDOCs are a SAP technology, because some of them remember the times I wasn’t even here, the approach to their generation is nothing closed to being standardized. By the different structure of FMs for the idoc generation you can see that, when new functionality were being introduce, depending on the current version of the SAP at that time, a new approaches were also designed. However looks like they didn’t take into consideration the idoc reduction topic till much later and the approach of TBD*. In the end if you have SIS/PO or any other middleware its most likely the best way to do the idoc reduction, otherwise you are for some tricky enhancements in the abap which I wouldn’t recommend.
