SAPTechno

Note 672577 - Initializing STPO-REKRI

Header
Version / Date 2 / 2003-10-30
Priority Recommendations/additional info
Category Workaround for missing functionality
Primary Component LO-MD-BOM Bills of Material
Secondary Components LO-EWB Engineering Workbench

Summary
Symptom

There are BOM (bill of material) items that have been recognized as being recursive during the BOM update and for which subsequently to the recognized recursiveness the system automatically sets indicator STPO-REKRI = 'X'.
You cannot initialize indicator STPO-REKRI subsequently via any maintenance transaction so that the recursiveness cannot be cancelled even if the reason for the recursiveness has already been eliminated.

Other terms

E29110, STPO-REKRI, STPO-REKRS, DISST, low-level code ; recursive

Reason and Prerequisites
  • In individual maintenance transactions CS01, CS02, CS05, CS62, ..., recursive items should be recognized in the dialog already so that the maintenance of recursive items will only be possible in the individual maintenance transactions if you set indicator 'recursiveness allowed (STPO-REKRS)'. BOM items with attributes STPO-REKRI = 'X' and STPO-REKRS = ' ' could be created via individual maintenance transactions only if the recursive BOM structure were not recognized in the maintenance dialog.
  • For the BOM maintenance with Engineering Workbench EWB (Transaction CEWB), BOMs are not checked for recursiveness in the dialog part of the transaction. The recursiveness check does not occur before you save the worklist. If the BOM becomes recursive due to the saving of the worklist, the system issues information 29 110 'BOM is recursive', however, the BOM changes are posted on the database. The system automatically sets indicator STPO-REKRI for the recursive items.
    In the dialog part of the EWB, no recursiveness check occurs since, for reasons of performance, the EWB has loaded only that BOM data program-internally which meets the selection criteria. For the individual maintenance transaction, the recursiveness check is already possible in the dialog part since the context is limited to one BOM.
  • For the creation of BOMs with function module BAPI_MATERIAL_BOM_GROUP_CREATE, the recursiveness check is not called before the COMMIT WORK so that the system issues information 29 110 'BOM is recursive' analogously to the program behavior in the EWB only after you have saved the passed BOM data. The system automatically sets indicator STPO-REKRI for the recursive items.
    Function module BAPI_MATERIAL_BOM_GROUP_CREATE behaves similarly to the EWB concerning the recursiveness check since the BOMs are saved via function modules of the EWB.
Solution
    1. Preparation
    Create report ZZ_REKRI_DATA (see the correction instructions) and execute the report. The report selects all items in material BOMs which were recognized as being recursive (STPO-REKRI = 'X') and/or for which recursiveness has been permitted (STPO-REKRS = 'X'). Internal numbers STLNR of the recursive material BOMs selected are written to file '\usr\bom_rec' on the application server. The recursive items selected are written to file '\usr\itm_rec' on the application server.
    2. Analysis of the status quo
    Create report ZZ_REKRI_ANALYSE (see the correction instructions) and execute the report. The report lists all items from file '\usr\itm_rec' with the following STPO attributes:
    STLTY STLNR STLKN STPOZ POSTP POSNR IDNRK REKRI REKRS
    Items which report ZZ_REKRI_DATA has written to file '\usr\itm_rec' are listed with prefix 'OLD:'.
    New recursive items which are not contained in file '\usr\itm_rec' are listed with prefix 'NEW:'.
    Attributes REKRI and REKRS are displayed with both statuses 'value old' -> 'value new' in each case. 'Value old' is that value which has been written to file '\usr\itm_rec', 'value new' is the current value from the database.
    If you call reports ZZ_REKRI_DATA and ZZ_REKRI_ANALYSE directly one after the other, then no items with prefix 'NEW:' should be listed. Attributes REKRI and REKRS of the listed recursive items with prefix 'OLD:' should only have old values ('X' -> ' ').
    3. Eliminating the cause for recursiveness
    Example:
    BOM A contains component B. With the EWB or the BAPI_MATERIAL_BOM_GROUP_CREATE, you create BOM B with component A. Since the recursiveness is recognized when you save, component A is marked with attribute STPO-REKRI = 'X'.
           A            B
           |      ->    |
          B            A      =>     STPO-REKRI = 'X'
    Now, BOM B with component A is supposed to keep existing and the recursiveness of component A is supposed to be cancelled. For this, you delete component B from BOM A without change number via the BOM maintenance (for BOMs with history requirement, refer to Note 35100). Now, BOM B is not recursive anymore. In the maintenance dialog, you cannot initialize indicator STPO-REKRI = 'X' of component A in BOM B. Effect: With the BOM explosion, component A will not be exploded further. The low-level code of A is not adjusted to the vertical integration of A in B.
    4. Initializing STPO-REKRI
    Create report ZZ_REKRI_RESET (see the correction instructions) and report ZZDIS501 (see Note 140573). If you execute report ZZ_REKRI_RESET, indicators REKRI and REKRS are hard-initialized via UPDATE command on the database in table STPO for all items that have been written via report ZZ_REKRI_DATA into file '\usr\itm_rec'. Afterwards, every manipulated BOM is checked for recursiveness. If a BOM is still recursive, indicator STPO-REKRI is set for the causing item. If the BOM is not recursive anymore, the low-level codes of the materials used are calculated again. For the low-level code calculation, if a previously not recognized recursiveness triggers the termination with message 'Maximum low-level code 999 is reached', report ZZ_REKRI_RESET terminates. You must manually start report ZZ_REKRI_RESET again afterwards. The report automatically restarts at the next (n+1) BOM since the checked BOMS are selected in file '\usr\bom_rec'. If report ZZ_REKRI_RESET terminates several times, you must start the report again until all BOMs of file '\usr\bom_rec' have been processed.
    5. Analysis after STPO-REKRI initialization
    Start report ZZ_REKRI_ANALYSE again. The report lists the following figures:

           BOMs Total:
Number of BOMs that are to be checked.

           BOMs checked and O.K.:
Number of BOMs checked which are correct.

           BOMs checked and not O.K.:
Number of BOMs checked which lead to the termination of report ZZ_REKRI_RESET. For these BOMs, the recursiveness must be searched manually and then eliminated. These BOMs are marked with status 'C' in file '\usr\bom_rec'. Afterwards, you must call report ZZDIS501 with the internal BOM number of the respective material BOM in order to calculate the low-level codes again.

           BOMs not check:
Number of the BOMs not checked up to now

    6. General information
    The reports described above have been derived from the reports from Note 140573:
    ZZDIS501 -> ZZDIS501
    ZZDIS502 -> ZZ_REKRI_DATA
    ZZDIS503 -> ZZ_REKRI_RESET
    ZZDIS504 -> ZZ_REKRI_ANALYSE
    While the procedure described in Note 140573 calculates the low-level codes of all material BOMs again with the aid of reports ZZDIS50*, reports ZZ_REKRI_* focus on the material BOMs which have recursive items. Yet, it is also valid for this procedure that the validity period and in particular the number of possible terminations is not predictable. If you want to undo the recursiveness of a few items, you should delete these items without change number via the BOM maintenance and then create these items again without change number.



Affected Releases
Software Component Release From Release To Release And subsequent
SAP_APPL46C46C46C
SAP_APPL470470470

Related Notes
140573Low-level code 999 for joint production
68792Collective note for low-level code / recursiveness