You find certain condition type couldn’t get determined as you’ve expected in item pricing condition tab. Pricing analysis shows:
108 Condition record exists, but has not been set
008 Condition record exists (removed manually)
for the determination of this condition type.
Pricing analysis (condition determination analysis) takes the current state of customizing and condition master data into account. Therefore it is not relay an analysis of what happened at the time of the original pricing run.
Message VE 108 (alternatively message VE 008) in pricing analysis indicates that while executing the pricing analysis a condition record has been found for a specific access but no corresponding line exists in table XKOMV of that item.
Message 108 could be an indicator that no condition record existed for this condition at the time of the original pricing and a record has been created meanwhile. This also applies to changed condition records with regarding to their validity periods.
A condition record was found during original pricing but no line in table XKOMV was created due to detected inconsistency (e.g. calculation type is D Gross weight, but no weight unit of measure available in KOMP).
Basically you cannot really debug since the analysis runs correctly. You’ll have to guess about why did the message appear and try to prove the speculation. Here are some steps which you could take a reference:
- Check if the condition has not been manually deleted in the document. Also have a check with the end user.
- Check if the condition is a data determination condition with condition class ‘H’.
- Check if the condition has been assigned with formula in which it sets KINAK to ‘Z’.
- Check validity periods of the condition record, compare Date on Which Record Was Created (KONH-ERDAT) with pricing date.
- Check if a requirement is set to the condition in the pricing procedure or to the accesses in the access sequence. Are there statements using KOMP in the pre-step part of the requirement (routine KOBEV_xxx)? You may refer to SAP Note 130416 and 156230 for more details. Please also refer to IV. Procedure during the analysis of requirements of SAP Note 859876.
- Check which fields are used in the relevant condition access. Is there any suspicious code in USEREXIT_PRICING_PREPARE_TKOMK or USEREXIT_PRICING_PREPARE_TKOMP (MV45AFZZ in sales order processing, RV60AFZZ in billing processing) related to those fields? Could it be possible that one or more of those fields were initial during original pricing?
For the detailed analysis steps, please also refer to III. Procedure during the analysis of the access of SAP Note 859876.
- Check if there's customer logic inside USEREXIT_XKOMV_FUELLEN(RV61AFZB) which modifies SY-SUBRC to 4.
- Could something be wrong with the pricing date due to customer modification (KOMK-PRSDT in a requirement or any other userexit)?
If the error is reproducible,
1.Check if the access could be fulfilled in the pricing pre-step.
Set a breakpoint in routine LV61AA30 at:
call function 'SD_COND_ACCESS'
2. Check if the access cannot find the condition record in real condition access.
Set a breakpoint in routine LV61AA29 at:
call function 'SD_COND_ACCESS'
Run the transaction until KOMT1-RKSCHL gets the desired condition type.
Execute the function module and check SY-SUBRC.
If SY-SUBRC is not 0, no condition record could be found. Check the fields in KOMK and KOMP which are relevant for the condition access. Also make a check with the pricing date field KOMK-PRSDT.
If SY-SUBRC = 0 after executing function module SD_COND_ACCESS, it means a condition record has been found. Then you’ll need to go ahead and debug to check why no entry gets inserted into XKOMV afterwards, especially you may have some further check in FORM XKOMV_FUELLEN (LV61AA52).