学步园

转note 26115.

Summary

A new condition table which uses, for example the terms of payment (ZTERM) as a key field is used. If the terms of payment are changed in the sales order, the corresponding condition is not automatically determined again from the condition table.

This can also happen if the terms of payment are used by another condition record. The correct condition is only found by a new pricing (condition access).
The problem also occurs for some standard condition tables. If you change the fields

• Price list type           (PLTYP)

• Material pricing group    (KONDM)

• Commission group          (PROVG)

the changes do not cause the corresponding condition types to be redetermined.

Additional key words

Pricing, change
KONDM, PLTYP, KONDA, PROVG

Cause and prerequisites

The program does not automatically recognize during a document update whether a condition which uses the changed field exists.
Amoung other things, the following changes are dealt with during final processing of the item in the standard system:

• Pricing type = 'A'

•  
  • Exchange rate for pricing and statistics            (VBKD-KURSK)

•  
  • Terms of payment key                                (VBKD-ZTERM)

•  
  • Cumulative order quantity in sales units            (KWMENG or MGAME)

• Pricing type = 'B'

•  
  • Material number                                    (VBAP-MATNR)

• Pricing type = 'C'

•  
  • Date for pricing and exchange rate                  (VBKD-PRSDT)

• Pricing type = 'G'

•  
  • Ship-to party                                      (KUNWE)

•  
  • Payer                                              (KUNRG)

•  
  • Batch number                                        (VBAP-CHARG)

•  
  • Plant                                              (VBAP-WERKS)

•  
  • Date on which services rendered                    (VBKD-FBUDA)

• Pricing type = 'H'

•  
  • Incoterms (part 1)                                  (VBKD-INCO1)

How the program behaves for the corresponding pricing type (KNPRS) that is, which condition types (KNTYP) and condition classes (KOAID) are determined again, can be seen in FORM routine KONDITIONSVORSTEP (up to Release 3.1I in Include LV61AF0K, as of Release 4.0A in Include LV61AA12). For a detailed description of the pricing types, see Note 24832.

Solution

1. In the user exits

• USEREXIT_NEW_PRICING_VBKD or

• USEREXIT_NEW_PRICING_VBAP

              (both in Include MV45AFZB), you can react to certain field changes by entering a certain pricing type in the 'NEW_PRICING' field. For a change of the price list type, for example, you can force a completely new pricing.

           If VBKD-PLTYP NE *VBKD-PLTYP.

             NEW_PRICING = 'B'.

           ENDIF.

In addition to the standard pricing types (see Note 24832) you can define your own pricing types. This can be done in USEREXIT_PRICING_RULE (in Include RV61AFZA). In it, you can apply your own pricing types (KNPRS; for example, 'X') to internal table STEU. In the fields of the STEU structure, you can store up to ten condition types (KNTYP) and condition classes (KOAID) which describe those condition types for which a new pricing is executed.

2. You can also use the condition types reserved for you in the standard system ('5' to '9' and 'X', 'Y' or 'Z') in Customizing of the condition type (T685A-KNTYP).

With these three methods you have the tools to make the system use the required condition type in the case of a field change.

Header Data

Affected Releases

Release-Independent

Related Notes