Just reread the question and think that the link you are looking for is via the table record ”A” assigned to the price condition You define in the worksheet which conditions a) are valid and b) are necessary for the calculation of the selling price. SAP® distinguishes itself between master data and transaction because, on the one hand, it must store the predefined quantity as indicated above; on the other hand, it is possible to modify the conditions within a sales order or an SD invoice. This means that it is not enough to store the master data, SAP® also needs to understand what conditions (and what actual values) were actually applied in each SD sales order/SD invoice. I do not know if that is what you were looking for when I explained the above very well. The condition registration number is stored in the VBAK and VBAP records and, after the billing document is created, also on VBRK/P. You can then use the knumh to retrieve the condition record, whether it is the condition record itself or the transactional condition record. KNUMH is the condition registration number, so if you have price conditions, you have a KNUMH that can then be read in the actual values. This has (as far as I know) nothing to do with the determination of lots. This gives the key for konv, which displays the conditions by sales order line, and finally there is a field in konv, which is KNUMH, which is the key to the KONNEP table. This table contains the details of the condition record.

KONH/KONP: All condition master data is stored in this table. Each condition is stored under a unique item number. In KONH, you have the information about the validity period of a condition. Shortcuts PR00, K007, etc. are called ”Standard Conditions”. They are used in SAP® SD to uniquely identify a condition. To create conditions, the corresponding types of conditions must be available. They are important because they define both the general properties of the conditions and the types of calculations. The most important types of calculation are: In this article, I gave you a first overview of the topic of ”conditions” and explained how conditions are maintained and used in customer orders. Due to the complexity of the subject, only a small aspect could be covered. Important elements for efficient pricing are the costing system and the order of access.

These aspects and the corresponding analyses cannot be covered here, as many complex scenarios need to be examined in detail. If you have more detailed questions, please contact me at any time at the email address info@dab-gmbh.de. In this article, I will describe the elements of ”Pricing & Conditions” in the SAP SD (Sales & Distribution) module®. Prices and conditions are an important topic for data analysis. Very often we receive questions such as ”What do I need to know about conditions in SAP?” ® ”How do I know if conditions can be changed manually?” ”In which tables can I find condition sheets and transaction history for conditions?” Here I will explain what types of conditions exist and how they affect the pricing process. B for example the calculation of the net value of the product. And if you`re looking for status records used for sales orders/invoices, you can get them via VBAP/VBRP >KNUMH, as Karen rightly pointed out. There are many important tables that contain information about prices and conditions in SAP®.

Two important elements are explained here, KONH/KONP (condition master data element) and KONV (condition transaction data). The price of the document) and KONP (the price sheet) is KONV-KNUMH. Ie. KONV-KNUMH = KONP-KNUMH. The corresponding Axxx table also contains the KNUMH number, and this is the connection between the Axxx table and the KNUMH KONP record. For example, the terms of sales order 12075 displayed with the SAP VA03 transaction® are displayed. It represents the worksheet of a sales order line that contains two flat screens. The schema consists of four different conditions (price elements): If you know which condition table to access for condition records, you can use the A* approach. The KONV table also contains the conditions used in the SD settlement documents. When an invoice is created from an order, the conditions are copied and stored under a new document condition number.

Hello, the status record numbers are stored in Table A*. First you need to find the right table, depending on your order of access. e.B. – Records with the client/hardware as access sseq are stored in A005. I hope this helps. VivekOn Fri, 15 Jun 2007 12:44:29 GMT sap-log-sd@Groups.ITtoolbox.com wroteHow can I determine the state registration number? I need this information for a BW report, i.e. a sales order item /condition type/value. Thank youKikas Vbrk / vbak – KNUMV gives you the link to KONV. These are obviously the details of the file of the state of the document. KONP is the condition master record table, that is, when you create a Here, it lists the types of conditions that can be used for a specific pricing scheme.

This table forms the basis for pricing a sales order. The complete table represents an abstract and global ”pricing scheme”. The pricing system applied depends on the material/product, the customer or a combination of material and customer. Each line of the pricing system represents a condition: the price is a condition in itself, the discount is a condition in itself, etc. In SAP, conditions® are represented by ”types of conditions”: the net value of flat panel displays is 2407.30 EUR and is calculated on the basis of the conditions ”PR00” and ”K007″. The outgoing tax is not included in the net value of the item in the sales order, as it only becomes relevant when the SD invoice is created. The money becomes relevant at the time of payment of the bill. In a command-line worksheet, there can be multiple conditions with different types. For example, the net value of a command line can be calculated from the following types of conditions: KONV: This table lists all the conditions used and their values for each command line. This means that all records listed on the Conditions slide are saved,” as shown in Figure 1.

Therefore, from experience, the table is very large. The reason why the table not only refers to the condition master data, but also to the data stored redundantly, is that the calculated values are listed, and on the other hand, the condition can be changed when creating the order. In many cases (for example, delivery) in the KONP table, no record was created, but the user entered the condition value manually. In such cases, it is a manual state. I would like to stress once again that it is not necessary for there to be a basic data record for every type of condition. The prerequisite is that a type of condition with the required properties has been defined in Customizing. I need this information for a BW report, i.e. a sales order item/condition type/value….