Troubleshooting Guide for Message 108 in Pricing Analysis
Skip to end of metadata
Created by Alex Zheng, last modified on May 19, 2020
Go to start of metadata
Symptom
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
or
008 Condition record exists (removed manually)
for the determination of this condition type.
General introduction about this message
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.
Possible scenarios which might lead to this error
Condition line has been deleted manually
The customer deleted the line in XKOMV manually. This case represents the original intention of the message.
New condition record created/record changed
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.
Requirement was not fulfilled
A requirement set for this condition in pricing procedure or in access sequence was not fulfilled during initial pricing and now it’s fulfilled.
Pricing determination key fields with initial value
A field used in one of the accesses was initial during original pricing or had a different value. It might in most cases be a userexit problem.
Pricing date issue
The pricing date was not correct during original pricing determination (maybe due to customer modification).
Inconsistency detected during pricing determination
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).
Include LV61AA52
FORM XKOMV_FUELLEN...
if xkomv-krech ca weight and komp-gewei = space.
sy-subrc = 4.
exit.
endif.
if xkomv-krech = 'F' and komp-voleh = space.
sy-subrc = 4.
exit.
endif.
if xkomv-krech = 'L' and komp-punei = space.
sy-subrc = 4.
exit.
endif.
if xkomv-krech = 'R' and komp-medst = space.
sy-subrc = 4.
exit.
endif.
if xkomv-krech = 'S' and komp-anzvse = space.
sy-subrc = 4.
exit.
endif.
...
Condition inactive indicator (KINAK) was set to 'Z' during pricing run
This flag could be set in condition value formulas or condition base formulas like 28 and 29.
It will lead to the result that the line in XKOMV got deleted after calculation -> message 108.
Include LV61AA55
FORM XKOMV_BEWERTEN• Update XKOMV
IF xkomv-kinak NE 'Z'.MODIFY xkomv.ELSE.
DELETE xkomv.
CONTINUE.
ENDIF.Data Determination Conditions
Condition types with condition class ‘H’ are used to determine sales deal/price book (in standard condition type PBU for example), but they do not appear in XKOMV due to the special logic in
Include LV61AA52
FORM XKOMV_FUELLENif xkomv-koaid = 'H' and sy-subrc = 0.
How to analyze?
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.
call function 'SD_COND_ACCESS'
2. Check if the access cannot find the condition record in real condition access.
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).
Related Content
Related SAP Notes/KBAs
SAP Note 859876 - Condition is missing: Message VE 108 or VE 008
SAP Note 130416 - Requirements in the condition preliminary step
SAP Note 156230 - Requirements: What is permitted, what is not?