Recursion and Low Level Recursion Control in Web services

As it is known, Recursion is a feature in the BOM to prevent the endless loop that can result from the vertex material reaching the top material again when the BOM is exploded at all levels. This feature both prevents the material from entering into an endless cycle by creating secondary needs over and over in material requirement planning, and also prevents it from entering an endless loop in standard price calculations in cost accounting.

In this article, we will first examine the recursion control of SAP and then discuss what kind of problem we can encounter when the integration is made using a web service and its solution. We will also include reviews about how SAP performs recursion control on its standard screens.

There are 2 fields in BOM for recursion in SAP. Recursion is tracked by these fields, whose technical names are REKRS (Recursion Enabled) and REKRI (Recursive), respectively. In addition, the DISST (MIP level) field in the MARA table is one of the fields used in recursion control. In fact, this field, which determines the order in which the MRP should work on the basis of material, is controlled whether the material added to the BOM is likely to be recursive or not. For example, if a material with MRP level 002 is added to a material with MRP level 003, there will be no possibility of recursion anyway. This is the first feature the system checks. Then, while checking the bill of materials, recursion checks are performed regardless of date, place of production and usage. (SAP note 42891)

When the save button is pressed on screens such as CS01, CS02, after checking the recursion, if there is recursion, an error message is given and the "Recursion Possible" sign is requested to be discarded. According to the need, the trace feature can be turned on and the recursion loop can be viewed.

In order to open this control, after adding your user from OS29, the trace feature should be activated from the CSRC_TRACE transaction code.

When the tracking feature is turned on, the system will create a table as follows after the error message.

The recursion in standard screens takes place before the top-up save feature. However, this is not the case with a BAPI used in a Web service. Since the control takes place after the commit in the transactions made with BAPI, the data should be checked before sending it to BAPI. Otherwise, the product tree is automatically deleted from the system after Commit runs. In our example, this deletion Since the process can be delayed up to 3 minutes, it disrupts the synchronization between the two integrated programs.

The problem is solved by writing a function that checks for recursion before sending the incoming data to BAPI and will send the "recursion possible" field checked if there is recursion. This function first performs a recursion check on the first level BOM, then explodes all BOMs of all levels with a self-invoking performance and then detonates all BOMs of their components. While performing this check, preventing the same components in the bill of materials from being checked over and over again prevented performance problems. In addition, a logging feature similar to the control on the standard screen has been added to the function.