SD定价问题

wood zhang

thanks stcao & jyyster,
I have made changes based on your advise, but there is still a error i don't understand, please see the screen dump.
the record exists, but the price was not carried out, after updating pricing by clicking button Update, the price was carried out successfully, can you tell me if I missed some steps ?

thanks again.

jyyster@gmail.c

How about your access sequence? Is it created by yourself or just copy from standard one? Do you add your condition table to access sequence?

jyyster@gmail.c

Entry of a sales document with alternative division in the item. Due to the alternative division, other terms of payment than in the document header are found for the item. The following message is issued when entering the item: Mandatory condition PR00 is missing.
(It can also be another condition that is mandatory). If you check on the condition screen, the condition exists.

jyyster@gmail.c

Symptom

Although a valid condition record exists, it is not set in the pricing result during the editing of an item. The pricing analysis displays message VE 108 "Condition record exists, but has not been set.
Alternatively, message VE 008 "Condition record exists (removed manually)" may occur.
If you navigate to the details of the relevant access in the pricing analysis, the system displays the information that all access fields are filled correctly.
Other terms

VE 108, removed manually, VE108, pricing analysis, condition is missing, condition record is missing,
USEREXIT_PRICING_PREPARE_TKOMP, USEREXIT_PRICING_PREPARE_TKOMK, MV45AFZZ, RV60AFZZ, TKOMP, TKOMP, VE008, VE 008
Reason and Prerequisites

The following sections describe the causes for this system response. There is also an explanation how to proceed during the analysis of such problems.

I. Function of the pricing analysis
The pricing analysis simulates a pricing run with pricing type 'B'. This pricing type redetermines all conditions that have an access sequence by accessing the condition master data. The pricing result determined in this case is compared with the existing result of pricing of the item. In the log of the pricing analysis, the result of the comparison is displayed by corresponding messages and supplemented with corresponding detailed information.
The message VE 108 / VE 008 points out that at least one of the fields relevant for the access was not filled correctly at the time of the item processing, with the result that the condition record could not be determined. At the time of the pricing analysis, however, all access fields are filled correctly, which means that the access to the condition record can be carried out successfully.
The most common cause for an empty access field at the time of the pricing run are customer-specific program enhancements with whose help either user-defined fields in the KOMK and KOMP structures are to be supplied, or user-defined logic that overrides the standard logic for the filling of the required fields.

II. Technical details
The KOMP and KOMK structures, relevant for the condition access, are filled by the calling applicatons. The corresponding source code for the most important applications can be found in the following routines:
              FORM                      Include
Order:        PREISFINDUNG_VORBEREITEN  FV45PF0P_PREISFINDUNG_VORBEREI
Billing doc:  PREISFINDUNG_VORBEREITEN  LV60AA58
Purchasing:  PREISFINDUNG_VORBEREITEN  MM06EFKO_PREISFINDUNG_VORBEREI
              >> KOND_KOMK_FUELLEN    MM06EFKO_KOND_KOMK_FUELLEN
              >> KOND_KOMP_FUELLEN     MM06EFKO_KOND_KOMP_FUELLEN

In the mentioned form routines, there is generally also a jump to corresponding user exits. These serve to fill user-defined fields in structures KOMP and KOMK (customer fields, fields in the customer namespace) or to fill R/3 standard fields differently than the standard source code:

              FORM                            Include/function module
Order:        USEREXIT_PRICING_PREPARE_TKOMK  MV45AFZZ
              USEREXIT_PRICING_PREPARE_TKOMP  MV45AFZZ

Billing doc:  USEREXIT_PRICING_PREPARE_TKOMK  RV60AFZZ
              USEREXIT_PRICING_PREPARE_TKOMP  RV60AFZZ

Purchasing:   CUSTOMER-FUNCTION '001'        EXIT_SAPLMEKO_001
              CUSTOMER-FUNCTION '002'         EXIT_SAPLMEKO_002

III. Procedure during the analysis of the access
If symptom described at the beginning occurs in your system, check first , whether the access fields are filled correctly at the time of the relevant pricing call.
To do this, we recommend the following procedure:

      1. Determine the access sequence of the affected condition type. This can be found in Customizing of the condition type (SD Transaction V/06, MM Transaction M/06).

      2. Determine the relevant access and its access fields (SD Transaction V/07, MM Transaction M/07). Comment: The technical field name is required.

      3. Set a breakpoint at the beginning of the routines mentioned above, which are used for the filling of the pricing interfaces. The breakpoint must be set dependent of the affected scenario (sales, billing document, purchasing).

      4. Carry out the steps for the creation/change of the document where the symptom occurs.

      5. The system holds at the breakpoint.

      6. Set watchpoints on the used access fields in the TKOMK or TKOMP structure and continue the debugging session with F7. The system no holds at all places where the access fields for the pricing run are filled or manipulated.


Example for the analysis of the access (forSD)
Affected condition type: ZPR0
-> Using Transaction V/06, you find the access sequence ZZPR.
-> In Transcation V/07, the access sequence ZZPR has two accesses:
     Access no.  Table  Name
    10          005    customer/material
    20          985    customer/material/special group
-> You want to set a condition rate based on access no. 20. You must then determine the technical names of the fields of this access:
     Condition  I/O  Doc struct  Doc fld  Name
     KUNNR      <    KOMK        KUNNR    sold-to party
     MATNR      <    KOMP        PMATN    pricing reference material
     ZZGRP      <    KOMP        ZZGRP    special group
-> The problem occurs during the creation of an order, that is, the breakpoint must be set at the beginning of the FV45PF0P_PREISFINDUNG_VORBEREI include. If the system stops here, set watchpoints on the following fields:
      TKOMK-KUNNR
       TKOMP-PMATN
       TKOMP-ZZGRP


IV. Procedure during the analysis of requirements
If the analysis of the condition access did not correct the system response, check next, whether for the affected condition type a requirement is not fulfilled at the time of the relevant pricing call and therefore no condition access is carried out:

      1. Determine the requirement of the affected condition type. This can be found in Customizing of the pricing procedure (SD Transaction V/08, MM Transaction M/08). In addition, a requirement can also be assigned to an access of an access sequence. This can be found in Customizing of the access sequence (SD Transaction V/07, MM Transaction M/07).

      2. Set a breakpoint at the beginning of the KOBEV part and also at the beginning of the KOBED part of the determined requirement.

      3. Carry out the steps for the creation/change of the document where the symptom occurs.

      4. The system holds at the breakpoint. Using field KOMT1-KSCHL (and KOMT2-KOLNR), check whether the requirement for the affected condition type (and the affected access) is run. If not, continue in debugging (F8)  until you have reached the affected condition type (and the affected access).

      5. In debugging mode, run through the source code of the requirement unto the end (statement ENDFORM). The requirement is only fulfilled, if variable SY-SUBRC displays the value 0 at the end of the requirement. C heck whether the requirement results in the same outcome in all relevant calls.


Example for the analysis of requirements
In a requirement, you check whether the net value of the item is not initial ("CHECK KOMP-NETWR NE 0."). During the creation of the item, the net value is not yet known. Therefore, the requirement is not fulfilled and the condition is not set. If a pricing analysis is then carried out, the requirement is fulfilled, since the net value is known in the mean time. Accordingly, the analysis displays message VE 108 (or VE 008).
Solution

The solution of the symptom is dependent on the results of the analysis. Generally, a correction of the customer-specific logic is necessary. If you need further support, contact the SAP Consulting Service.
For problems with access fields that are filled by the standard logic, contact SAP Support.

For more information, see the following notes:
  363212 'Pricing analysis' mode of operation
  130417 Pricing preparation in billing document (user exit)
  117189 KOMK-AUDAT, KOMK-AUART_SD in the billing document

jyyster@gmail.c

This message means that a condition record has been found in
analysis but is not in the document. Analysis does a simulated
repricing using pricing type B (everything is redetermined) and
the list of found conditions is compared to those that are in
the document that you are analyzing.

if you are creating the sales/billing document with reference to any
preceeding document it will copy the condition record from the preceeding
document. In case the preceeding document did not have the correct condition
record or did not have the record..the succeeding document will replicate
the same. Or  condition record was created with a from-date in the past.
Existing orders would get this record if you reprice.

In copy control settings u can set whether u just want to copy or u want to
redetermine pricing. Set pricing type to be G at item category level.

大哥，你的ZU10设置的是必输项，把它改成手工就可以了

wood zhang

多谢,we263536505 .

我不准用户手入,我是用于Sales Return

wood zhang

ZU10不能自动取数的原因是,因为ZIT003用在Sales Return,而Sales Order的pricing procedure ZIT001中没有ZU10,所以开Sales Return Order时Copy功能就无法Copy ZU10的记录,在ZIT001中加ZU10 即可.
但有新问题请大家帮忙,虽然ZU10的记录找到,但ZNEA不能算出行项目的金额,要点Update按钮.
图1. ZIT003的设置
图2. 在点Update之前的condition情况.
图3. 在点Update之后的condition情况.