Summary
This consulting note describes the various options provided by R/3 pricing Customizing to exclude conditions from the pricing result.
This note also describes scenarios in which the system uses a hard-coded logic to exclude conditions (for example, using the 'last price' logic
Content Overview:
This note deals with the following topics in detail:
1. Attributes of the inactivity indicator (KINAK field).
2. Use of the KZNEP exclusion indicator to exclude conditions.
3. Condition exclusion based on the properties of the
condition type.
4. Use of exclusion group Customizing to exclude conditions.
5. Use of KINAK 'Y' ('last price' logic) to exclude conditions.
6. Summary/program steps for condition exclusion.
7. No exclusion on header level
-
1. Attributes of the inactivity indicator (KINAK field):
You will see that a condition has been excluded if
- the condition does not exist at all (condition exclusion with the KZNEP exclusion indicator) or
- the inactivity indicator (KINAK field) is filled with a corresponding value. This value is then displayed on the condition detail screen.
The inactivity indicator can assume the following attributes:
-
a) 'X' - "Inactive via formulas or incorrect":
Conditions are deactivated with 'X' in the following cases:
- Failed quantity conversion: If quantity conversions fail, the XKOMV-FXMSG and KOMP-FXMSG fields are also filled with message number '804'.
- Failed currency conversion: If currency conversions fail, the XKOMV-FXMSG and KOMP-FXMSG fields are also filled with message number '803'.
- Field overflow for condition basis (KAWRT) or condition value (KWERT) or failed execution of a condition basis formula or condition value formula: In these cases, the XKOMV-FXMSG and KOMP-FXMSG fields are also filled with message number '802'.
- Both the condition rate and condition value are zero for a pricing condition (KOAID = 'B') that is not a group condition. This avoids the situation where a 'zero price' remains as the last active non-statistical price (for information on the 'last price' logic, see section 5).
In scenarios where message number '802', '803' or '804' is set, the pricing result is marked as containing errors (KOMP-PROSK = ' ').
-
b) 'W' - "The document item is statistical":
Conditions on statistical items (KOMP-KOWRR field is not SPACE) are deactivated with 'W'. This scenario occurs, for example, if an appropriate reason for rejection is set for an item.
-
c) 'A' - "Condition exclusion item":
See section 4.
-
d) 'K' - "Inactive due to calculation basis/shipping material type":
This inactivity indicator is used in freight cost determination. Refer also to Notes 318775 and 773034.
-
e) 'L' - "Condition exclusion header or inactive at header level":
This is used in the area of freight cost determination. For 'Normal' pricing, there is no exclusion at header level. Compare section 7 as well as Note 217009, point 1 in the section 'Reason and Prerequisites'.
-
f) 'M' - "Inactive due to manual entry"
See section 3.
-
g) 'T' - "Inactive at header level":
Only in freight cost determination. See also the explanations for the 'K' and 'L' inactivity indicators.
-
h) 'Y' - "Inactive because of subsequent price":
See section 5.
-
i) 'Z' - This inactivity indicator is used internally, for example, when processing interval scales and therefore it must not be used in a user-defined logic and in user-defined enhancements.
-
2. Use of the KZNEP exclusion indicator to exclude conditions:
Conditions are excluded during automatic condition determination (condition access, FORM XKOMV_AUFBAUEN_AUS_KOMT1, Include LV61AA67 and FORM KONDITIONEN_LESEN, Include LV61AA29). You can only use this exclusion variant to control whether or not a condition causes follow-up conditions to be excluded from the pricing procedure. Use of the KZNEP exclusion indicator to exclude conditions: Furthermore, the condition value of the conditions involved is completely irrelevant because this is not yet determined at the time of condition determination.
The procedure is as follows:
In Customizing of a condition type or in the condition master data of a condition record, you can define an exclusion indicator (field KZNEP). For example, exclusion indicator 'K' is defined for the condition record of a condition ZKO1.
As part of automatic condition determination, all of the conditions of the pricing procedure are now processed from top to bottom. First, the condition requirement is checked (if it exists). This check must be successful before the system checks whether valid condition records exist in the condition master data and then transfers these if they exist. For example, the condition record for ZKO1 is determined with the 'K' exclusion indicator. The system then copies the value for the exclusion indicator from the master data (KONP-KZNEP) to the communication structure for the document item (KOMP-KZNEP).
If no excludion indicator is defined in the determined condition record, but one is defined in Customizing of the condition type (T685A-KZNEP or KOMT1-KZNEP), this is copied to the communication structure for the document item (KOMP-KZNEP). If no condition record is found for the condition type or no exclusion indicator is defined in Customizing of the condition type, KOMP-KZNEP stays initial.
In requirements, the system may query the contents of the KOMP-KZNEP field. If a requirement is assigned to condition ZKO2, which is a follow-up condition to ZKO1, and if this requirement is only fulfilled when KOMP-KZNEP is not 'K', automatic condition determination no longer takes place for ZKO2. Therefore, if a condition record exists for ZKO2, it is not set in the pricing result.
The contents of KOMP-KZNEP remain the same until
- for example, another condition record with the KONP-KZNEP condition exclusion indicator is found and KOMP-KZENP is overwritten with this new value or
- for example, another condition type with condition exclusion indicator T685A-KZNEP is found and KOMP-KZENP is overwritten by this new value or
- KOMP-KZNEP is changed in a requirement or in other user exits (for example, FORM USEREXIT_XKOMV_FUELLEN, Include RV61AFZB) (this is undesirable, but possible) or
- KOMP-KZNEP is initialized at the beginning of another pricing program run.
In the R/3 standard system, the following exclusion indicators are delivered:
A List of invoices U Metal price X Net price
O Event V VKP Calculation Surcharge
You can use the following IMG path (Transaction SPRO) to maintain other exclusion indicators:
Sales and Distribution > Basic Functions > Pricing > Condition Exclusion > Condition Exclusion for Condition Types and Records
Note:
-
a) Due to the design, you cannot exclude a condition with your own exclusion indicator. This is because the requirement is already checked before the condition is accessed. However, you can only set the exclusion indicator after the condition record is accessed.
-
b) The KOMP-KZNEP field must be queried in the 'KOBED' part of a requirement. It cannot be queried in the 'KOBEV' part since only KOMK fields are available in the 'precondition'. For more information on the requirements logic, see Note 156230.
-
c) A condition exclusion with an exclusion indicator is not possible in combination with certain Customizing settings (with interval scales, for example):
A ZK01 condition sets the exclusion indicator to 'X'. For a follow-up condition ZK02, which is maintained as an interval scale (STFKZ = 'D'), the exclusion indicator is checked in a requirement (002, for example).
If pricing is now triggered with pricing type 'A' (for example, if this runs for a quantity change, only the condition records for interval scales are redetermined), condition ZK01 is not redetermined since ZK01 does not have the interval scale attribute. Therefore, the KOMP-KZNEP exclusion indicator is not set. Consequently, the requirement 002 runs successfully for condition ZK02 and the ZK02 interval scale is now determined.
Example:
Requirement 777 is not fulfilled for KOMP-KZNEP = 'K'.
Requirement 888 is not fulfilled for KOMP-KZNEP = 'L'.
Requirement 999 initializes KOMP-KZNEP.
Pricing procedure:
Condition Requirement Condition record exists
with the following KONP-
KZNEP
ZKO1 - SPACE
ZKO2 777 SPACE
ZKO3 - K
ZKO4 777 SPACE
ZKO5 - L
ZKO6 777 SPACE
ZKO7 999 SPACE
ZKO8 888 SPACE
This results in the following situation:
- Condition ZKO2 is set since KOMP-KZNEP is not set to 'K' at this time.
- Due to requirement 777, condition ZKO4 is not set in the pricing result since KOMP-KZNEP was set to 'K' as a result of setting the condition record for ZK03.
- Despite requirement 777, condition ZKO6 is set in the pricing result since, in the meantime, KOMP-KZNEP was set to 'L' as a result of setting the condition record for ZK05.
- Despite requirement 888, condition ZKO8 is set in the pricing result since KOMP-KZNEP was initialized by requirement 999 of condition ZKO7.
-
3. Use of the condition type attributes to exclude conditions:
In Customizing of a condition type (Transaction V/06), you can make the following settings for the 'Manual entries' field (KMANU) in the 'Change options' section:
' ' No limitations
'A' Free
'B' Automatic entry has priority
'C' Manual entry has priority
'D' Not possible to process manually
With regard to the condition exclusion, only the 'C' setting is relevant in this case (Manual entry has priority). The effect of this setting is self-explanatory (see also the example). Note: The setting is valid only within the affected condition type, that is, it is not valid across all condition types.
If you choose the 'B' or 'D' setting, manual entries are not permitted. Even though both the ' ' and 'A' settings permit manual entry of the condition type, they do not have any immediate influence on the condition exclusion since this logic is not programmed in the system.
Within pricing, the condition exclusion based on the KMANU field takes place
- after the 'first' (preliminary) valuation (FORM XKOMV_BEWERTEN, Include LV61AA55) of the pricing result in the FORM XKOMV_AUSSCHLUSS (Include LV61AA56), but
- before the exclusion according to exclusion group Customizing (see section 4), which is also performed in the FORM XKOMV_AUSSCHLUSS.
If conditions are excluded from FORM XKOMV_AUSSCHLUSS, a 'second' (final) valuation of the pricing result is carried out once again (FORM XKOMV_BEWERTEN) to update the pricing result based on the exclusions that were made.
Example:
The 'C' setting was selected for a price ZPR1. A condition record is automatically found for an order item. Another row is manually entered for this price. Afterwards, the row with the automatically found condition record is deactivated with the 'M' indicator (Inactive due to manual entry). If you manually enter another row, the automatically determined row remains inactive with 'M' and the first row that was entered manually becomes inactive with 'Y' (see section 5 and note that ZPR1 is a price condition).
-
4. Use of exclusion group Customizing to exclude conditions:
Exclusion group Customizing is in the following IMG path (transaction SPRO):
Sales and Distribution > Basic Functions > Pricing > Condition Exclusion > Condition Exclusion for Groups of Conditions
Carry out the following steps:
-
a) Define condition exclusion groups:
First create one or more exclusion groups, for example:
G001 Discount group 1
G002 Discount group 2
This data is stored in the T684 database table.
-
b) Assign condition types to the exclusion groups:
Then the required condition types are assigned to the exclusion groups, for example:
G001 Discount Group 1 ZD01 Discount 1
G001 Discount Group 1 ZD02 Discount 2
G002 Discount Group 2 ZD03 Discount 3
G002 Discount Group 2 ZD04 Discount 4
This data is stored in the T684G database table.
-
c) Maintain condition exclusion for pricing procedures:
Finally, define the required exclusion rules for each pricing procedure. In this case, you can create exclusions in accordance with the following predefined rules (KAUVF field):
- 'A' - Selection of the most favorable condition type within a condition exclusion group
- 'B' - Selection of the most favorable condition record of a condition type if several condition records exist (for example, selection under various condition records of the condition type PR00)
- 'C' - Selection of the most favorable of the two condition exclusion groups (in this case, all of the condition types of the two groups are cumulated and the totals are compared with each other).
- 'D' - "Exclusive" procedure: If any of the condition types of the first group exists on the item, all of the condition types of the second exclusion group are excluded.
- 'E' - Similar to 'B', but with the most unfavorable condition record.
- 'F' - Similar to 'C', but with the more unfavorable condition exclusion group.
The actual exclusion rules for a pricing procedure are maintained with a sequence number and completed by specifying the exclusion rule and the affected exclusion group(s):
10 D Exclusive G002 Discount Group 2 G001 Discount Group 1
20 A More favorable ... G002 Discount Group 2
This data is stored in the T684S database table.
All exclusion rules except for rule 'D' are based on the knowledge of the condition values of the condition types involved. In accordance with exclusion group Customizing, the condition exclusion is therefore also created in pricing in the FORM XKOMV_AUSSCHLUSS (include LV61AA56)
- after an 'initial' (preliminary) valuation (FORM XKOMV_BEWERTEN, Include LV61AA55) of the pricing result
- and after the condition exclusion based on the KMANU field (FORM XKOMV_AUSSCHLUSS, Include LV61AA56)
The exclusion is created with inactivity indicator 'A'.
The information in section 3 also applies here: If conditions were excluded from FORM XKOMV_AUSSCHLUSS, a 'second' (final) valuation of the pricing result takes place once again (FORM XKOMV_BEWERTEN), in order to update the pricing result based on the exclusions made. In this case, conditions with inactivity indicator 'A' are no longer valuated.
Note:
-
a) Since the exclusion of a condition may influence the condition basis and therefore also the condition value of follow-up conditions, a condition or exclusion group that was more favorable (more unfavorable) than another condition or exclusion group after the preliminary valuation may have been more unfavorable (more favorable) after the final valuation. See also the following example.
In such a case, another exclusion or valuation based on the last valuation is NOT triggered. This procedure could result in a continuous loop (the "flip flop effect"). For more information, see Note 217009.
-
b) In the R/3 standard system, conditions with a zero condition value do not participate in exclusions according to exclusion groups. However, you can change the system response in such a way that conditions with a zero condition value also participate in exclusions.
To do this, add the value formula 038 (Include FV64A038), or a corresponding user-defined value formula that contains the source code from value formula 038, to the pricing procedure used for a condition that will definitely be part of the pricing result.
-
c) Conditions that the condition exclusion indicator (see section 2) already fully excluded from the pricing result of an item no longer participate in exclusions according to exclusion groups. As a result, you can no longer use rule 'D' to exclude the conditions of another group.
-
d) Exclusion group Customizing should not be maintained randomly, but rather with care. If exclusion group Customizing is so extensive that you can no longer comprehend the formation of the 'final result', it is time to reconsider the relevant business process.
Example:
The aforementioned exclusion group Customizing is valid.
Before an exclusion is created, a document item contains the following preliminary pricing result, which of course is not displayed in this form. In this case, the percentage discount ZD02 refers to the price ZPR0 and the percentage discount ZD04 refers to subtotal 1.
Condtns Amt Condtns Val Inactive
ZPR0 Price EUR 100.00 1 PC EUR 100.00
ZD01 Discount 1 EUR 4.00 1 PC EUR - 4.00
ZD02 Discount 2 5.000% EUR - 5.00
Subtotal 1 EUR 91.00
ZD03 Discount 3 EUR 9.50 1 PC EUR - 9.50
ZD04 Discount 4 10.000% EUR - 9.10
Subtotal 2 EUR 72.40
... ... ... ....... ...
In accordance with exclusion rule 10, the discounts ZD01 and ZD02 are excluded from the G001 exclusion group since conditions were determined from the G002 exclusion group with the discounts ZD03 and ZD04.
In accordance with exclusion rule 20, discount ZD03 (condition value EUR -9.50) excludes discount ZD04 (condition value EUR -9.10) since ZD03 is the more favorable discount in the G002 exclusion group.
After you create the exclusion and the conditions have been valuated again, you finally receive the following final pricing result:
Condtns Amt Condtns Val Inactive
ZPR0 Price EUR 100.00 1 PC EUR 100.00
ZD01 Discount 1 EUR 4.00 1 PC EUR - 4.00 A
ZD02 Discount 2 5.000% EUR - 5.00 A
Subtotal 1 EUR 100.00
ZD03 Discount 3 EUR 9.50 1 PC EUR - 9.50
ZD04 Discount 4 10.000% EUR - 9.10 A
Subtotal 2 EUR 90.50
... ... ... ....... ... .
Note that, if subsequently considered, discount 4 would now be more favorable than discount 3, since the exclusion of discounts 1 and 2 influenced the condition basis of the percentage discount 4, but it did not influence the absolute discount 3.
-
5. Use of KINAK 'Y' ('last price' logic) to exclude conditions:
In addition to the condition exclusions, which you can influence in Customizing and in the condition master data (see sections 2, 3 and 4), R/3 pricing still has a condition exclusion that was programmed using a hard-coded logic: the 'last price' logic.
This logic follows the simple rule:
In a pricing result for an item, there can only be one active non-statistical price condition (condition class KOAID = 'B').
If, after you execute all other exclusion options, several non-statistical price conditions were active, only the last price condition would remain active. All conditions (prices, surcharges and discounts) before this last non-statistical price condition are set to 'Y' (inactive) provided that they were not already deactivated by one of the other exclusion options.
Technically, the 'last price' logic is implemented in the following way. This logic is in the FORM XKOMV_BEWERTEN (Include LV61AA55). In this routine, the conditions are processed in succession from top to bottom in the sequence in which they are specified in the pricing procedure ("LOOP AT xkomv."). During this loop program run, the system notes the table index (variable: letzter_preis) of the last active non-statistical price condition. This first LOOP is followed by a second LOOP that deactivates the conditions, which precede the row with the letzter_preis table index, with 'Y', provided that they are not yet inactive elsewhere.
Note that the routine FORM XKOMV_BEWERTEN may run twice (see sections 3, 4 and 6) provided that the other exclusion options were used. In this case, the exclusion of the conditions excluded with 'Y' is reversed once again (FORM XKOMV_AUSSCHLUSS, Include LV61AA56) because the condition exclusion has priority over the other exclusion options. The second final valuation run then results in the final exclusion of conditions with 'Y' because only now do you know if the conditions were not already excluded elsewhere, that is, the conditions were not already excluded using the KMANU indicator or exclusion groups.
Furthermore, note that the exclusion with 'Y' also affects the determination of 'value-based' condition bases of follow-up conditions. The system takes account of conditions excluded with 'Y' if reference steps are maintained in the pricing procedure for the follow-up condition. This occurs because the exclusion with 'Y' is not yet known when the condition values of the affected reference steps are totaled.
If no reference steps are maintained, the system does not take account of conditions excluded with 'Y'. In this case, the condition basis is filled from the ZWISU variable, which is always reset if a more active non-statistical price condition is found when conditions are processed in sequence (for more information, see Note 834174).
This may result in a similar situation to that described in the example in section 4:
Example:
There are two price conditions, ZPR1 and ZPR2, at step 10 and 20. Furthermore, there is a percentage discount ZD01, which refers to steps 10 - 20, as well as an absolute discount ZD02.
Exclusion group Customizing is set in such a way that the price ZPR1 'exclusively' excludes the price ZPR2 and the most favorable discount between the discounts ZD01 and ZD02 is selected.
After the first valuation, the preliminary pricing result is as follows:
Step Condtns Amt Condtns Val Inactive
10 ZPR1 Price 1 80,00 EUR 1 PC 80,00 EUR Y
20 ZPR2 Price 2 70,00 EUR 1 PC 70,00 EUR
30 ZD01 Discount 1 10,000 % 15,00- EUR
40 ZD02 Discount 2 12,00 EUR 1 PC 12,00- EUR
.. .... ... ... ...... ...
The condition basis for discount ZD01 is EUR 150.00 and this results in a condition value of EUR -15.00, which is more favorable than absolute discount ZD02, which is EUR -12.00. Therefore, discount ZD02 is excluded.
After the exclusion has been created and the conditions have been valuated again, you finally receive the following item pricing result (before you carry out the entire document pricing):
Step Condtns Amt Condtns Val Inactive
10 ZPR1 Price 1 80,00 EUR 1 PC 80,00 EUR
20 ZPR2 Price 2 70,00 EUR 1 PC 70,00 EUR A
30 ZD01 Discount 1 10,000 % 8,00- EUR
40 ZD02 Discount 2 12,00 EUR 1 PC 12,00- EUR A
.. .... ... ... ...... ... .
Note that, if subsequently considered, discount 2 would now be more favorable than discount 1. The exclusion of price 2 with 'A' (instead of the exclusion of price 1 with 'Y') affected the condition basis the percentage discount 1, which now only results in a condition value of EUR -8.00 instead of EUR -15.00.
-
6. Summary/program steps for condition exclusion:
In conclusion, the following section provides an overview of when pricing should take place and in which routines the different condition exclusions are made (reduced display):
...
PERFORM xkomv_aufbauen_aus_komt1. [Include LV61AA67]
>> All of the conditions of the KOMT1 internal table
run in a loop:
>> PERFORM (bedingung_pruefen). [Include LV61Axyz or
Include RV61Axyz] (a)
>> PERFORM konditionen_lesen. [Include LV61AA29]
>> CALL FUNCTION 'SD_COND_ACCESS'. (b)
>> PERFORM xkomv_fuellen. >> KOMP-KZNEP = KONP-KZNEP. (c)
[Include LV61AA52]
...
PERFORM xkomv_bewerten. [Include LV61AA55] (d)
PERFORM xkomv_ausschluss. [Include LV61AA56]
>> "Exclusion with KMANU" (e)
>> PERFORM konditionsausschluss. [Include LV61AA28] (f)
>> If an exclusion was created:
>> PERFORM xkomv_bewerten. [Include LV61AA55] (g)
...
-
a) The requirement of a condition is checked at this time. In the requirement, the system may check the KOMP-KZNEP exclusion indicator and exclude the condition, if required.
-
b) The 'SD_COND_ACCESS' function module is used to access the condition tables on the database.
-
c) If a condition type or a condition record with exclusion indicators (KOMT1-KZNEP or KONP-KZNEP) was determined in (b), this is transferred to structure KOMP in FORM XKOMV_FUELLEN (include LV61AA52). For follow-up conditions, the exclusion indicator is available at time (a).
-
d) In FORM XKOMV_BEWERTEN, the determined conditions are valuated for the first time. This provides the basis for making the condition exclusion in accordance with exclusion groups in (f). In addition, the exclusion according to the 'last price logic' already takes place here for the first time, but it is only a final exclusion if no other exclusions take place at times (e) and (f).
-
e) The exclusion in accordance with the KMANU field first takes place in FORM XKOMV_AUSSCHLUSS.
-
f) Then, the exclusion in accordance with exclusion group Customizing takes place in FORM XKOMV_AUSSCHLUSS.
-
g) If exclusions occur in (e) or (f), the pricing result is valuated again. Therefore, the condition exclusion is also updated in accordance with the 'last price logic' and therefore definitely excluded.
-
7. No exclusion on header level
All exclusions explained in detail occur on item level of the document. Why is that ?
-
a) Use of the KZNEP exclusion indicator to exclude conditions:
Since this exclusion is linked to the condition access, it occurs on item level as well.
-
b) Use of the condition type attributes to exclude conditions:
Since the automatic condition determination occurs on item level, the decision whether the automatic or the manual condition is to be excluded can only be made on item level.
-
c) Use of exclusion group Customizing to exclude conditions:
The exclusion using exclusion groups in 'normal' documents (for example, sales and purchasing documents, applications 'V' and 'M') is also performed on item level. This also applies to group conditions.
Only during the pricing in 'actual' shipment cost documents (Application 'F') an exclusion is possible on header level. Compare section 1 (points d, e and g) as well as Note 217009, point 1 in section 'Reason and prerequisites'.
-
d) Use of KINAK 'Y' ('last price' logic) to exclude conditions:
The 'last price' logic is a rule that is valid for each item. This exclusion can only be carried out on item level.
Condition exclusion, exclusion groups, price last,
KINAK, KZNEP, KOWRR
This is due to the design of R/3 pricing in connection with both the existing Customizing settings and the condition master data.
In this note, answers in relation to the questions concerning the condition exclusion are provided in detail.
This note is a consulting note. Further questions about the functions described above are not processed by regular SAP support, but by consulting, and are subject to separate remuneration.
Header Data
| Release Status: | |
| Released on: | 25.06.2008 13:08:06 |
| Priority: | |
| Processor: | Robert Schweisthal |
| Responsible: | Ansgar Weissler |
| Category: | |
| Primary Component: | SD-BF-PR 定价码 |
Affected Releases
Release-Independent
Related Notes
Action Log
|