Tips and Tricks - How to debug
When is low-level configuration executed and when high-level?
High level configuration is an interactive configuration. It is used for example in CU50 and in sales orders. During the configuration, the user assigns values to characteristics. Dependencies between configurable materials in the configuration structure can be mapped using constraints.
Low-level configuration is used in none-interactive configuration. Low-Level configuration refers to background explosions of bills of material (BOM), routings, maintenance orders, model service specifications, and standard networks, in material requirments planning (MRP), or when creating production orders or networks.
If you are not sure, you can check it by setting a break point in function module CULL_CONFIGURE_ITEM. When the program stops there, the low-level configuration is used. Low-level configuration can be simulated in transaction CU50 by pressing the button ‘planned order’ or ‘costing’. Routing explosion is always done in low-level configuration. You can also simulate this in CU50. Low-level BOM explosion can be simulated in transactions CSK1 and CSK2.
Characteristic values from the sales order, for object $ROOT or $PARENT, are automatically used to determine the BOM components and operations or activities. The $SELF instance is always unknown. Therefore an object dependency cannot set values, where $SELF is used. In the low-level configuration you can only access values from $PARENT and $ROOT.
Restrictions in low-level configuration
Dependencies for characteristics, characteristic values and configuration profiles are ignored.
Constraints are not processed
Following expressions will be ignored: $set_pricing_factor, $del_default, $sum_parts, $count_parts and type_of
Debug:
In most of the cases, there is a selection condition in BOM or routing, which is executed in high-level configuration and the you are wondering, why the component is missing when you do low-level configuration (for example, executing costing in sales order). First, find the selection condition in BOM or routing and find the internal number of the object dependency (CUKB-KNNUM). If you have the problem with a BOM, first set a breakpoint at this function module: CUBX_CONFIGURE_STPOB – set it at this call:
There you can see, which component (material) is currently processed in c_stpob-idnrk or which is the current position in c_stpob-posnr. In lt_selconds, you can see, if the selection condition, you are looking for, is the current one. If you are on the right position or material or selection condition, then enter the function module CULL_CONFIGURE_ITEM.
If you are using class nodes, a breakpoint here could also be helpful:
Here you can see, which component was found in class node (c_stpob-idnrk).
If you have a problem with a routing, the first point for debugging would be in function module CUBX_CONFIGURE_OBJECT.
In function module CULL_CONFIGURE_ITEM, first you can check, which component is $root and $parent and $self. Enter following variables: CULLD_INSTS (there you can see which material number is on which level and which characteristic values are in access ). In the line ‘properties’ you can find the characteristic values, which are loaded for this level. CULLD_SELF (mostly level ‘1’), CULLD_PARENT and CULLD_ROOT. The number shows the level of the material in CULLD_INSTS. With this information, you can check, if the selection condition is fulfilled or not. You will see, that the $self instance is always unknown. So an object dependency cannot set values, where $self is used. In the low-level configuration you can only access values from $parent and $root.