條件技術中需求公式的 kobed和kobev的不同之處
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.
相關文章
- 32、條件格式和公式公式
- 不同地區技術人才需求量的統計和分析
- SAP SD 基礎知識之定價中的條件技術(Condition Technique in Pricing)
- [譯] 事件迴圈中microtask和macrotask的不同之處事件Mac
- ARM技術 —— 條件執行
- 條件概率與全概率公式公式
- Linux技術的成功之處Linux
- 04 Windows批處理中的條件執行Windows
- Mybatis-技術專區-Criteria的and和or進行聯合條件查詢MyBatis
- 簡述HTTP和HTTPS協議的不同之處HTTP協議
- drools中的條件 when
- 「譯」編寫更好的 JavaScript 條件式和匹配條件的技巧JavaScript
- NLP 中不同詞嵌入技術的比較 - KDnuggets
- final,finalize,finally的不同之處
- 華納雲:SAS盤和SATA盤的不同之處
- doxygen 宏定義/宏編譯/條件編譯/預處理/預編譯 不處理、忽略條件、分析所有條件、滿足所有條件的方法編譯
- 條件概率、全概率、貝葉斯公式理解公式
- oracle中的條件語句Oracle
- 【SQL】SQL中if條件的使用SQL
- 「分散式技術專題」SQL最佳化的前置條件和最佳化技巧分享分散式SQL
- shell指令碼中的運算子和條件判斷指令碼
- 『Java 語法基礎』final、finalize 和 finally 的不同之處Java
- 程式返回條件的0和1
- SAP ABAP DDIC 結構欄位的一些技術限制條件
- 不同體系分散式儲存技術的技術特性分散式
- linux中條件變數和訊號量的區別!Linux變數
- 【SHELL】Shell中的條件判斷
- C++中的條件變數C++變數
- Linux和Unix有什麼不同之處?Linux
- Python和Java之間有什麼不同之處?PythonJava
- 談談raft fig8 —— 迷惑的提交條件和選舉條件Raft
- SqlServer中迴圈和條件語句SQLServer
- T-SQL——關於Join on的的連線條件和where的篩選條件的區分SQL
- 條件機率、全機率、貝葉斯公式理解公式
- Java 設定Excel條件格式(高亮條件值、應用單元格值/公式/資料條等型別)JavaExcel公式型別
- 7.Makefile中的條件語句
- php中條件語句的使用整理PHP
- 介面自動化的前置條件怎麼處理
- Android學習 —— 測試init.rc中的條件觸發的處理順序Android