Purpose
This page is created to help understanding the application logic behind functionality Splitting.
Overview
This debugging guide can help understanding how the Splitting functionality works and what is the logic behind it. This page can be useful for identifying the root cause of an undesirable behavior of system. For a detailed description of this functionality and for possible solutions of common issues please refer to the following Wiki page: Splitting
Debugging Guide - Classic scenario
The debugging can be started in method SPLIT_BACKEND_OBJECTS of class CL_BBP_SC_TRANSFER. System will check the document type whether it is backend Purchase Order, Requisitions or Reservation.
The logic behind the splitting process is similar and it will be demonstrated considering document type Purchase Order.
In case of a backend PO method SPLIT_BACKEND_PO will be called and the data of the items will be exported in is_objtype_pack. At the beginning of the method the system maps the splitting criteria using method SPLIT_PO_BE_MAP_CRITERIA.
Here system checks if the items have any vendors and sets the country of the plant. If there was no error during this process the items will be appended to et_object_split. After this step lt_object_split will be sorted by the relevant attributes. Then it loops through the items and checks if they are catalog items and if they have a contract assigned to them. If yes the data of this contract will be read.
Afterwards the very first item will be appended without checking the criteria.
In the next iterations of the LOOP, the splitting criteria will be checked. Here you can see all of the relevant splitting criteria.
In this part there are two scenarios:
- If the new item is different considering any of the splitting criteria, then a new document should be created, so lv_refnumber will be increased by 1 and this number will be assigned to the actual item.
- On the other hand if the new item has the same parameters, then there is no need to create another document, so the lv_number won’t be increased. This indicates that the new item will be grouped to the same document like the previous item.
Afterwards the standard behavior can be modified using BADI BBP_BS_GROUP_BE.
In case of a Contract creation the logic is the same, but the splitting will occur in another method (BE_CONTRACTS_SPLIT in FM BBP_PD_SC_TRANS_MULTI_BE_CTR) and with less splitting criteria:
Debugging Guide - Local scenario
The debugging can be started in method SPLIT_LOCAL_OBJECTS of class CL_BBP_SC_TRANSFER. Just like in the backend scenario the system checks the follow-on document type whether it is Purchase Order or Bidding document. The logic behind the splitting process is similar and it will be demonstrated considering document type Purchase Order.
In case of a PO method SPLIT_LOCAL_PO will be called and the data of the items will be exported in is_objtype_pack. At the beginning of the method the system maps the splitting criteria using method SPLIT_PO_LOC_MAP_CRITERIA.
In this method system loops through all local items and checks if the item is external requirement, determines the process types according the subtype and reads the Organization and Partner data. Then the items will be appended to et_object_split and it will be also sorted using the relevant attributes.
Afterwards method SPLIT_LOCAL_PO_DO will be called.
In SPLIT_LOCAL_PO_DO method SPLIT_PO_LOC_CMP_CRITERIA will be called for every item, where the same criteria comparison will happen like in the backend scenario.
This method import variable lv_split which decides if the actual item should be created in another document. If yes the lv_doc_number will be increased by 1. If no the item gets the same lv_doc_number as the previous item.
Afterwards we are again in method SPLIT_LOCAL_PO. Here you can change the standard splitting behavior using BADI BBP_GROUP_LOC_PO.
Then the system loops through the items, saves the ref_number as object_id and appends the items to the lt_items table. When the system reaches the end of a ref_number (so there are no more items that have the same ref_number) the already gathered items will be appended to et_object_pack.
In case of a Contract creation the logic is the same, but the splitting will occur in another method (SPLIT_LOCAL_SC_ITEMS_FOR_CTR in FM BBP_PD_SC_TRANS_MULTI_LOC_CTR) and with less splitting criteria:
In case of an Rfx and Live Auction there aren't any splitting criteria that will be checked. However the splitting behavior can be changed in BADI BBP_TRANSFER_GROUP.