KOBEV is for header --> called by the KONDITIONSVORSTEP – which is pre-step
KOBED is for line items.
form Kobed is called on item level based on information of header and item
form Kobev is called on header level based on information of the header
SAP is doing price determination in several steps. in an early step form KOBEV is called. during this time of execution only header fields are available. If this information is sufficent to exclude the condition from pricing, you can save performance later on.
If KOBEV was succsessful (Sy-subrc = 0) SAP checks later on the form routine KOBED with header and item information. Only if Kobed is successful (sy-subrc = 0) pricing will be executed for this condition type. If there is no requirement entered for a condition type in pricing procedure, SAP will always try to determine a value for this condition type.
Long text
Symptom
This note describes how you can change the sourcecode in the requirements of pricing. In particular at the moment not all fields are filled with current values so that, when you check for certain conditions, you have to be carful.
1. Implementation in the source code
With the maintenance of Requirements & Formulas (Transaction VOFM), menu option 'Requirement -> Pricing', button 'Source text', you get tothe ABAP editor. Every requirement is represented by a three-digit number xxx (001 to 999). Note that for formulas and requirements, the customer name range starts with 600.
Every requirement xxx in pricing consists of two FORM routines:
- The precondition (FORM name KOBEV_xxx)
This is checked on header level and therefore is only a necessary requirement that the condition type or the access is taken intoaccount at all.
- And the actual requirement (FORM name KOBED_xxx)
This is checked during processing on item level and it finally determines whether condition type or access is taken into account.
The (pre)conditions are contained in Include LV61Axxx (SAP name range) or in Include RV61Axxx (customer name range). Since these Includes are contained in program SAPLV61A, here you can basically (that is, from the technical point of view) access all fields and tables which the pricing can also access. For restrictions see further down below.
In a (pre)condition, set system field SY-SUBRC to zero if the testresult is correct. The system interprets an SY-SUBRC unequal to zero asif the requirement does not apply.
2. Storing in the pricing procedure or in the access sequence
At two different positions you can use the requirements:
- In the Customizing of the pricing procedure, for every condition typeyou can store a requirement which determines whether or not this condition type should be used in the
document.
- You can also store a requirement in the Customizing of the access sequence for every access (that is, for every condition table or key combination).
3. Program flow and restrictions
The (pre)conditions are checked when you set up the internal tables from the Customizing tables of the pricing procedure (table T683S, Transaction V/08) and the accesses (table T682I,
This note describes how you can change the sourcecode in the requirements of pricing. In particular at the moment not all fields are filled with current values so that, when you check for certain conditions, you have to be carful.
1. Implementation in the source code
With the maintenance of Requirements & Formulas (Transaction VOFM), menu option 'Requirement -> Pricing', button 'Source text', you get tothe ABAP editor. Every requirement is represented by a three-digit number xxx (001 to 999). Note that for formulas and requirements, the customer name range starts with 600.
Every requirement xxx in pricing consists of two FORM routines:
- The precondition (FORM name KOBEV_xxx)
This is checked on header level and therefore is only a necessary requirement that the condition type or the access is taken intoaccount at all.
- And the actual requirement (FORM name KOBED_xxx)
This is checked during processing on item level and it finally determines whether condition type or access is taken into account.
The (pre)conditions are contained in Include LV61Axxx (SAP name range) or in Include RV61Axxx (customer name range). Since these Includes are contained in program SAPLV61A, here you can basically (that is, from the technical point of view) access all fields and tables which the pricing can also access. For restrictions see further down below.
In a (pre)condition, set system field SY-SUBRC to zero if the testresult is correct. The system interprets an SY-SUBRC unequal to zero asif the requirement does not apply.
2. Storing in the pricing procedure or in the access sequence
At two different positions you can use the requirements:
- In the Customizing of the pricing procedure, for every condition typeyou can store a requirement which determines whether or not this condition type should be used in the
document.
- You can also store a requirement in the Customizing of the access sequence for every access (that is, for every condition table or key combination).
3. Program flow and restrictions
The (pre)conditions are checked when you set up the internal tables from the Customizing tables of the pricing procedure (table T683S, Transaction V/08) and the accesses (table T682I,
Transaction V/07). There are four different callup points.
a) Header: Precondition from pricing procedure
During the line by line processing of the pricing procedure, the systemchecks the precondition first (T683S-KOBED). This is a preselection whether or not this condition type may generally occur for the document items. If SY-SUBRC equals zero here, this condition type is included in internal table KOMT1. Here only header fields (structure KOMK) may be checked. Note that the headers of tables T685 and T685A are not yet filled here, thus no checks for the Customizing of the condition type may be carried
out.
Also note that the check of the precondition at this time is carried out to improve the performance. However, this 'buffer mechanism' is only available in certain constellations and depends on the calling application as well as on the pricing type. For this reason it is not sufficient to implement a certain check logic only in the precondition. The identical checks must also be a part of the main requirement. Example: see SAP R/3standard requirements 001, 008, etc.
b) Header: Precondition from access sequence
Next, the precondition from the access is checked(T682I-KOBED). If SY-SUBRC equals zero here, this access is included in internal table KOMT2. Otherwise, when the condition records are accessed later, the corresponding condition table is not taken into account at all. Here also only header fields (structure KOMK) can
be checked.
The precondition from the access sequence is always checked if the field assignment for the access sequence only contains header fields (structure KOMK). However, if the field assignment contains at least one item field, the precondition is only carried outif in Customizing the access was optimized (in the IMG with the suboption 'Define access sequences' -> 'Optimize accesses', TransactionOVU0), that is, if a corresponding entry exists in table T682V.
c) Item: Requirement from pricing procedure
The requirement from the pricing procedure (T683S-KOBED) is checked for every document item. Thus, in addition to header fields (structure KOMK), item fields can also be checked here (structure KOMP).
d) Item: Requirement from access sequence
The requirement from the access (T682I-KOBED) is also checked for everydocument item. Here you can also use KOMP fields in addition to KOMK fields.
Only if all four (pre)conditions are fulfilled (SY-SUBRC = zero),
forthis condition type the system searches for condition records. This makes clear that in the requirements you cannot use fields from the found condition records (for example, STFKZ, KZNEP).
Only after the search for condition records has been carried outfor all conditions, the pricing with the valuation starts. Here also fields KOMP-KZWI1, XWORKA, and so on are filled. This in particular means thatin the (pre)conditions there may also be no check for these fields. In addition, only at this time important data from the document or the
document item are available in the pricing fields, for example the quantity. Thesemay also not be called in the (pre)conditions.
4. Programming details
When you call up pricing (for example, with function module PRICING),the requirements are called as follows:
CONDITION PRELIMINARY STEP
Loop over the pricing procedure (T683S)
Call KOBEV_{T683S-KOBED} and check SY-SUBRC EQ 0
Derivation of KOMT1 with fields from T685 and T685A
KOMT2_AUFBAUEN
Loop over the accesses (T682I)
Check table T682V (if item fields in access)
Call KOBEV_{T682V-KOBED} and check SY-SUBRC EQ 0
APPEND KOMT2
APPEND KOMT1
XKOMV_AUFBAUEN_AUS_KOMT1
Loop over KOMT1
Call KOBED_{KOMT1-KOBED} and check SY-SUBRC EQ 0
KONDITIONEN_LESEN
Call KOBED_{KOMT2-KOBED} and check SY-SUBRC EQ 0
Additional key words
VOFM
Cause and prerequisites
Consulting.
Solution
Consulting.
Source code corrections
________________________________________________________________________
Note is release independent
________________________________________________________________________
Page 4
Reference to related Notes
Number Short text
____________________________________________________________
449546 Access requirement in account determination does not work
410579 FAQ: Rebate processing
381348 Using user exit, customer exit, VOFM in SD
130416 Requirements in the condition preliminary step
41119 Q&A - Explanation of req. & formulas for pricing
a) Header: Precondition from pricing procedure
During the line by line processing of the pricing procedure, the systemchecks the precondition first (T683S-KOBED). This is a preselection whether or not this condition type may generally occur for the document items. If SY-SUBRC equals zero here, this condition type is included in internal table KOMT1. Here only header fields (structure KOMK) may be checked. Note that the headers of tables T685 and T685A are not yet filled here, thus no checks for the Customizing of the condition type may be carried
out.
Also note that the check of the precondition at this time is carried out to improve the performance. However, this 'buffer mechanism' is only available in certain constellations and depends on the calling application as well as on the pricing type. For this reason it is not sufficient to implement a certain check logic only in the precondition. The identical checks must also be a part of the main requirement. Example: see SAP R/3standard requirements 001, 008, etc.
b) Header: Precondition from access sequence
Next, the precondition from the access is checked(T682I-KOBED). If SY-SUBRC equals zero here, this access is included in internal table KOMT2. Otherwise, when the condition records are accessed later, the corresponding condition table is not taken into account at all. Here also only header fields (structure KOMK) can
be checked.
The precondition from the access sequence is always checked if the field assignment for the access sequence only contains header fields (structure KOMK). However, if the field assignment contains at least one item field, the precondition is only carried outif in Customizing the access was optimized (in the IMG with the suboption 'Define access sequences' -> 'Optimize accesses', TransactionOVU0), that is, if a corresponding entry exists in table T682V.
c) Item: Requirement from pricing procedure
The requirement from the pricing procedure (T683S-KOBED) is checked for every document item. Thus, in addition to header fields (structure KOMK), item fields can also be checked here (structure KOMP).
d) Item: Requirement from access sequence
The requirement from the access (T682I-KOBED) is also checked for everydocument item. Here you can also use KOMP fields in addition to KOMK fields.
Only if all four (pre)conditions are fulfilled (SY-SUBRC = zero),
forthis condition type the system searches for condition records. This makes clear that in the requirements you cannot use fields from the found condition records (for example, STFKZ, KZNEP).
Only after the search for condition records has been carried outfor all conditions, the pricing with the valuation starts. Here also fields KOMP-KZWI1, XWORKA, and so on are filled. This in particular means thatin the (pre)conditions there may also be no check for these fields. In addition, only at this time important data from the document or the
document item are available in the pricing fields, for example the quantity. Thesemay also not be called in the (pre)conditions.
4. Programming details
When you call up pricing (for example, with function module PRICING),the requirements are called as follows:
CONDITION PRELIMINARY STEP
Loop over the pricing procedure (T683S)
Call KOBEV_{T683S-KOBED} and check SY-SUBRC EQ 0
Derivation of KOMT1 with fields from T685 and T685A
KOMT2_AUFBAUEN
Loop over the accesses (T682I)
Check table T682V (if item fields in access)
Call KOBEV_{T682V-KOBED} and check SY-SUBRC EQ 0
APPEND KOMT2
APPEND KOMT1
XKOMV_AUFBAUEN_AUS_KOMT1
Loop over KOMT1
Call KOBED_{KOMT1-KOBED} and check SY-SUBRC EQ 0
KONDITIONEN_LESEN
Call KOBED_{KOMT2-KOBED} and check SY-SUBRC EQ 0
Additional key words
VOFM
Cause and prerequisites
Consulting.
Solution
Consulting.
Source code corrections
________________________________________________________________________
Note is release independent
________________________________________________________________________
Page 4
Reference to related Notes
Number Short text
____________________________________________________________
449546 Access requirement in account determination does not work
410579 FAQ: Rebate processing
381348 Using user exit, customer exit, VOFM in SD
130416 Requirements in the condition preliminary step
41119 Q&A - Explanation of req. & formulas for pricing
OSS Note 156230 contains a very clear and thorough description of this function.
331
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
