Pricing management [REV]
- SD Pricing
- Sales document
- Interface to Profitability Analysis
- Configurable Parameters and Formulas
- Pricing procedures
- Adjust Pricing Procedure ( stat. are also in subtotals ) 15.09.2021
- Currency conversion
- Condition record
- Condition is Inactive
- Condition origin
- Working with Intercompany Condition Types
- Data model
- Promotional Pricing Agreements
- Special functions
- Customer-Expected Price
- Pricing in the Assembly Order
- Cost
- Selling services
- Variant Conditions
- Minimum Order Value
- Sales Order Costing in Pricing
- Duplicating Conditions
- Cumulating Conditions
- Group Conditions
- Condition Exclusion/ Konditionsausschluss
- Pallet Discounts
- Data Determination in the Access
- Customer hierarchy in use
- Dummy condition line
- Conditions in External Services Management
- Pricing in procurement
- Condition Interchange
- FAQ
- Header conditions or header condition screen
- VPRS (cost) in pricing
- How to
- Add new fields
- Access with the partial table key
- Advanced Techniques, Tips, and Tricks
- Typical Practice Demands on Pricing and Their Solutions
- Additional information
- 834174 - How are 'value-related' condition bases determined? ( 15.09.2021 )
- Re-determine or not? (22.07.2021)
- Troubleshooting Guide for Message 108 in Pricing Analysis (22.07.2021)
- 2414653 - Price condition is inactive in the purchase order
- 183820 - Print of inactive conditions
- 722300 - Statistical val GRWR contained twice in intercompany billing
- 24832 - Pricing rules/TVCPF
- 2706031 - Consulting: How to use the parameter IV_CALLER_ID of the RFC-enabled function module PIQ_CALCULATE
- 930537 - Interval scales: Functions and restrictions
- 2739880 - Consulting: Manual change to net price of item
- 2927325 - Restrictions for pricing in S/4 Hana customer management
- 1391347 - Field KOMK-AUGRU in billing document
- 2953640 - Performance improvement due to prestep for accesses
- 2907944 - Field Gross Value is zero in invoice
- 109708 - Scale processing for group condition
- 912340 - Pricing: Condition access occurs in two steps
- 201830 - Calculation of the net price of an item
- 2993900 - Intercompany Pricing conditions are not showing on Sales Order after system upgrade
- 22963 - Rounding problems in condition basis
- 114756 - Customer hierarchy determination for pricing
- New fields in selection screen (Texts)
- Copy fixed conditions without recalculation ( 10.09.2021 )
SD Pricing
Sales document
Predefined Price Elements in the Item Overview Screen
Since SAP ERP 6.0 EHP 4, it is possible to enter or display predefined price elements in the table control of the Item Overview screen after the activation of the business function LOG_SD_SIMP_02.Price Agreements
Interface to Profitability Analysis
The Profitability Analysis distinguishes involves two different methods: account-based and costing-based Profitability Analysis. Both methods can be used in parallel.- When using the account-based CO-PA, only real conditions (posted in FI) are transferred to CO-PA. The only activity to acquire this information in CO-PA is to configure the relevant accounts (e.g., revenue and sales deduction accounts) as CO-related accounts.
- In costing-based CO-PA, data is already passed to CO-PA for incoming sales orders. Here, a line item is generated with a CO-PA document for each order item. The same happens during billing.
Configurable Parameters and Formulas
Business functions LOG_SD_COMMODITY_02 and LOG_ MM_COMMODITY_02 (available for a fee). It was designed to deal with the often complex and individual pricing rules in commodities trading.- Maintain the parameter catalog following the menu path IMG Sales and Distribution Basic Functions Pricing Configurable Parameters and Formulas in Pricing Define Entries for Parameter Catalog.
- To maintain or display custom structures, follow the menu path IMG Sales and Distribution Basic Functions Pricing Configurable Parameters and Formulas in Pricing Define Custom Structure
- After maintaining all the necessary parameters in the catalog, we can now start creating the actual CPF formula. The associated menu path is IMG Sales and Distribution Basic Functions Pricing Configurable Parameters and Formulas in Pricing Define Formula.
- Since we want to use BRFplus, we select the routine number 1 that is delivered by SAP. This routine will execute an assigned BRFplus function.
- Assigning a CPF Formula to a Condition Record
- On the next screen we enter our formula My_ CopperContent_Penalty and confirm the input. The system reads the formula from Customizing and offers the formula parameters for maintenance.
Pricing procedures
From-To
Manual Indicator
Print Indicator for Condition Lines
Subtotal
Condition Formula for Alternative Value Calculation
Condition Formula for Basis
Account Key
Account Key for Accruals
Statistical and Relevant for Account Determination
- The price condition is used for statistics only, that is, you have selected the Statistics indicator.
- You have selected an Account key that defines two accounts.
Currency Conversion
- Local currency
- The local currency is not stored in the document, but determined from the company code table T001.
- Document currency (also known as transaction currency)
- The document currency in the sales order is taken from the customer master data and can be changed manually. The associated exchange rate to the local currency is calculated at the exchange rate date.
- When adding new items, the pricing date is used as the exchange rate date.
- The exchange rate can be recalculated in the invoice if required. However, a different invoice amount in relation to the order confirmation may occur as a result.
- Exchange Rate for Accounting
- The associated date fields are not displayed. The specification in the exchange rate is not used for pricing purposes, but it is only passed to accounting within the accounting interface of the billing.
- To accounting, all values are transferred exclusively in the document currency. In the accounting document, the required values in local currency are then calculated using the exchange rate for SAP ERP Financials (FI) postings.
- When you create credit memo requests or returns, you should do so with reference to the billing document if possible. If they are created without reference to the billing document, the exchange rate for FI postings is recalculated for each new document
- Condition Currency and Exchange Rates
- The currency of a condition record with a calculation type other than Percentage is transferred within pricing into the document conditions. In the routine xkomv_ kkurs_ermitteln of the pricing program, an exchange rate is then determined.
- If the exchange rate between the condition currency and document currency is not maintained, the exchange rate between the condition currency and the local currency is determined.
- If the exchange rate between the condition currency and document currency is maintained, it will be adopted (programmatically, this situation is noted in the internal control indicator xkomv-kbflag). In this case, in the Condition Details screen only one exchange rate is displayed.
Condition record
Changes can be made
Condition is Inactive
- A if Condition is inactive with the message as A, then there would be another condition added in the condition Exclusion ( best condition within two condition types)
- K: During the shipment cost calculation, a condition type is not active, however, indicator 'Condition is inactive' is set to 'K' (because of calculation base/shipping material type inactive). This happens even if a valid condition record exists. Condition exclusion, header exclusion, calculation base, BERGL, TKOMV_EXKLUDE_K
- The indicator is set under the following conditions within the price determination (only for shipment cost calculation):
- In a shipment cost document, there are at least two subitems with the same calculation base or same combination calculation base/shipping material type in a shipment cost item.
- For at least one of these subitems, no valid condition record exists for condition type 'XXXX'
- Then for all subitems with this calculation base (or calculation base/shipping material type), condition type 'XXXX' is set to inactive with indicator 'K', if it exists
- Example: Condition type 'XXXX' contains the freight class in its key, for example.
- Two subitems exist with calculation base 'B' (delivery item) for a shipment cost item.
- The delivery items contain freight classes A and B.
- For freight class A, there is a valid condition record for condition type 'XXXX', for freight class 'B' there is not.
- Since the freight rate (condition type 'XXXX') cannot be calculated for all delivery items, it must not be used. This is ensured with the exclusion described above.
- In other scenarios, however, you do not want this exclusion, but it cannot currently be influenced by Customizing.
- Solution
- There are two possible ways to work around this problem
- 1. You can create a condition record, for example with price 0, in cases where no valid condition record exists.
- 2. Make a modification within the price determination program. The following describes three different options for deactivating the exclusion in certain situations by means of a modification.
- a) The exclusion should not be carried out for a certain calculation base only (for example, for calculation base 'C', group shipping units).
- Implement the changes in Include LV61AA37 as specified in the correction instruction under "Modifications for a.)".
- b) The exclusion should not be carried out for certain condition types only. For example, you can use the condition category (KNTYP) field to indicate to a condition type that this exclusion is not active. For this field, customer reserves are provided in the standard system, for example, the setting condition category = 'Z'. The following change avoids the exclusion for all condition types with this condition category.
- Implement the changes in Include LV61AA37 as specified in the correction instructions under "Modifications for b.) "
- c) The exclusion should not be carried out in any case
- Implement the changes in INCLUDE LV61AA37 as specified in the correction instructions under "Modifications for c.)".
- Note that you CANNOT implement the modifications listed here using SNOTE. You must implement the appropriate source code variant manually.
- L condition is set to inactive as L if the Header condition is not active or set as Header condition exclusion
- M: one condition type determined in sales order using Condition record and you also tried to enter a manual price for the same condition type which will inactive condition value triggered with condition record, in that case, condition type will set as inactive with M
- X this will result if any of the routines such as Requirements, alternative calculation type and condition base formulas are set correctly or not.
- Y if two or more condition types is determined in the sales order which is valid which have the same properties, then automatically one valid record will be active and all other lower conditions will set as inactive with Y for example, if you have one Price with 100$ and other has been entered manually with 110$, then the system will set the price with 100$ to inactive with status Y
Condition origin
- A Automatic pricing
- B Duplicated from main item
- C Manually entered
- D Header condition
- E Item total
- F Condition supplement
- G Original header condition
- H Correction Rebate
- I Cost Correctio
Working with Intercompany Condition Types
- PI01 Intercompany: fixed amount per material unit
- PI02 Intercompany: percentage of the net invoice amount
Data model
- The condition type shows what type of condition it is; price, surcharge, or discount in value or percentage or values.
- The pricing procedure specifies the sequence in which the condition types are used for determining prices and the rules used to determine prices.
- The access sequence is defined in the condition type and determines the sequence in which the system searches for valid entries in the condition tables. You can carry out a special search (here, for customer and material) or a more general search (for material group).
- The condition table represents the validity periods for the individual condition records You can link to the condition records using a single condition record number (knumh).
- The following are condition records:
- Konh: Condition header
- Konp: Condition items, possibly with supplementary conditions
- Konm/Konw : Quantity scale or value scale
Condition Records With Reference
If you want to create condition records based on records that already exist in the system, you can create condition records with reference. Creating condition records with reference reduce the data entry effort considerably. This method of creating condition records is especially useful for creating records that have similar data to the reference but have different validity periods.You can overwrite any of the specifications of a condition record, thus using it as a reference. When you save an altered condition record, the system creates a new condition record.
Condition Supplements
Example: You enter a condition record for the price of the material Mat1 and want to create it so that it is always calculated together with a customer rebate of USD 10 and a special offer discount of 10 %. For every sales order for this material, the system automatically calculates the sales price, the customer rebate, and the special offer discount at the same time.
Special Condition Record Functions
- You can include terms of payment as part of your promotional strategy.
- Tracking Cumulative Values With Condition Update
- Maximum Number of Sales Orders
Promotional Pricing Agreements
A promotion typically represents a high-level marketing plan for particular products or product lines - for example, a promotion for a range of products during a specific sales cycle. A promotion can include a number of different sales deals.- Budget planning in CO-PA
- Budget assignments in SD (condition record maintenance)
- Passive availability check in CO-PA
Special functions
Condition Type HM00 (Order Value)
Condition Types SKTV/SKTO (Cash Discount))
- The condition type SKTV comes into play only if the company code is configured so that the cash discount reduces the tax base. This is controlled by the requirement 014 (cash discount before tax). The condition type is positioned before the tax condition MWST, so that the condition base formula 016 (net value and XWORKD) can take into account the cash discount amount.
- The condition type SKTO uses the complementary requirement 009 (cash disc. after tax) to requirement 014. The condition type is positioned behind the tax condition type, so that the tax base is not affected. In this regard, you should know that the requirements 009 and 014 do not work if the tax is determined using tax jurisdiction codes. See the SAP Note 1080399 (Cash Discount and Tax Jurisdiction) for more information.
Condition Types RL00/MW15 (Invoice List Conditions)
Free Goods in Sales
- Inclusive free goods with item generation
- Buy x units of product A, but only pay for y units. In this variant, the order quantity of the product A is reduced to y and an additional free-of-charge order item is created with a quantity of x-y.
- Exclusive free goods
- Buy x units of product A and get y units of product B for free. An additional free-of-charge subitem is generated for product B.
- Inclusive free goods without item generation
- This is the same scenario as when buying x units of product A and only paying for y units. In contrast, however, no additional items are generated. The discounting is carried out exclusively by means of pricing conditions.
Tax Determination in Sales
- Simple Tax Determination
- One single tax rate percentage in the maintenance Transaction FTXPWe now consider the pricing procedure RVAA01 from sales and distribution. Here the condition type MWST calculates the tax.
- Tax Determination via Accounting (Tax Trigger)
- At least one tax code is assigned to more than one tax rate percentage
- The integration of the tax determination in the sales pricing procedure takes place using the tax trigger condition type MW01. This condition type is characterized as a tax trigger by having condition class G and being marked as statistical in the pricing procedure. In the pricing procedure that follows, note that the condition types MWAS and MWAA of the tax determination procedure are marked as manual.
- Tax Determination via External Tax Interface
- In the United States, it is possible to perform the calculation of sales taxes by an external software solution (e.g., Vertex and Taxware).
- In this scenario, the tax trigger is the statistical SD condition type UTXJ that determines the tax code using condition records. If a condition record is found, the external tax interface is called by condition value formula 300.
- Tax Increase
- If you are not using an external tax interface, you make a change to the tax rate on a specific date by first creating a new tax code with Transaction FTXP for the country concerned and assigning the new percentages to that tax code.
Condition Update
- For a found condition record, the statistics table S071 is updated in the case of a sales order and table S060 in case of a billing document.
- When maintaining condition records for a condition type with condition update, three additional fields
- limit the condition value
- maximum condition basis value
- maximum number of orders
- Goto Additional Data Cumulative Values
Pricing in Rental and Maintenance Contracts (Periodic Billing Plan)
Pricing in Fixed Price Contracts (Milestone Billing)
Pricing in Resource-Related Billing
Customer-Expected Price
To minimize process costs, you want to detect deviations between your own price and the one your customer expects as early as possible. You can then react at an early point in time after-sales document creation and apply counter measures, such as correcting wrong price master data or by contacting your customer.- Customer-expected price (EDI1)
- Customer-expected value (EDI2)
- To define threshold values, create condition records for this condition type.
- Add this condition type to the pricing procedure of the sales document type for which the tolerance check shall be applied.
- In the same pricing procedure, for this condition type, select the Expected value (8) routine in the Routine for Alternative Calculation of Condition Amount field. Alternatively, you can create your own routines and select one of these.
Pricing in the Assembly Order
- EK01 can be used as a basis for determining a price for the make-to-order item.
- EK02 is a statistical condition which can used instead of VPRS to calculate the profit margin for the assembly item. The VPRS value is purely informative in this case.
Cost
- Stock sale (no cross-company)
- In the standard pricing procedure RVAA01 we use the condition type VPRS (cost) for the representation of the costs. This condition is not determined by condition records, but is triggered by the attribute Condition Type = G (cost) of the condition type within the program. In the sales order, the value of the condition is determined from the table MBEW (material valuation). The condition represents at this stage the planned costs.
- If the billing takes place before the goods issue—this may be required for export operations—the invoices must be updated after successful goods issue. For this purpose, the SDVPRSUPDATE program is available.
- Drop shipment (third party)
- The costs are represented by the condition type VPRS. Like in a stock sale, the planned costs of the sales order are determined during pricing from the table MBEW (material valuation).
- The billing, which usually takes place after successful vendor invoice receipt, transfers the value of the vendor invoice as actual costs in the condition VPRS.
- If the creation of customer billing takes place before booking the vendor invoice of the supplier, the planned costs are used. Once the vendor’s invoice is posted, the VPRS condition will be updated automatically for the involved invoices, as with all subsequent costs or credits to this order.
- Cross-company stock sale
- In this process, the costs in the order are not represented by the condition type VPRS, but by the internal transfer condition types PI01 or PI02. PI01/PI02 are the price agreements between the two companies. In this process, two billing documents are created.
- Make-to-order with/without production order
- In this scenario, the planned costs for an order item are either formed by a manual unit costing or taken over from the production order, if such was created. The planned costs are transferred to the condition type EK02 (calculated costs).
- Actual-cost accounting (resource-related billing)
- During the creation of billing documents for these items (Transaction DP90), the cost will be transported via the condition type EK01 into the billing document, so that in this scenario, the cost statement in the invoice is correct.
Selling services
Variant Conditions
Minimum Order Value
- AMIW Minimum order value
- The condition type is configured as a statistical group condition with calculation type B (fixed amount).
- For this condition type, the condition records with the desired minimum sales order values are maintained. As part of the document-end processing (PRICING_COMPLETE), the determined AMIW value is distributed proportionally among the items. By configuring Subtotal = D, this value is temporarily stored in the working variable xworkd for later use in the condition type AMIZ.
- AMIZ Minimum value proposal
- The minimum sales order value is determined by the preceding condition type AMIW. If the net value of the sales order falls below this value, the difference is calculated and assigned as a surcharge by the condition type AMIZ (minimum value surcharge). AMIZ is configured as a reference to AMIW, causing the condition type to appear only if AMIW was determined before. It is not flagged as statistical or as a group condition. If the net value of the order value falls below the minimum order value (that is, komp-netwr is less than xworkd), the difference is assigned by condition value formula 013 (minimum value surcharge) to AMIZ as the condition value.
Condition Type AZWR (Down Payment/Settlement)
Condition Type GRWR (Statistical Value (Cross-Border))
Sales Order Costing in Pricing
- Product costing: Product costing calculates the cost of the sales order item on the basis of the sales order BOM. A sales order BOM could be part of a super BOM and the configuration object dependencies.
- Unit costing: Enter the items to be costed manually in unit costing.
- as a basis for pricing: If you want to use sales order costing as a basis for pricing in SD, you can use the standard SAP condition type EK01.
- at a statistical level. EK02 is the condition type provided for this in the standard system.
- In the requirements class, you can also store a condition type for the transfer of the proportion of the fixed costs of the planned costs. EK03 is the condition provided for this in the standard system.
Duplicating Conditions
Cumulating Conditions
The standard system condition type KUMU enables you to display the total of the net values of an item and all the sub-items belonging to that item.Group Conditions
- Quantity unit for cumulation
- Group key number
- Mark the condition type as a group condition (~Indicates whether the system calculates the basis for the scale value from more than one item in the document)
- To carry out cumulation across all items, but to read a separate condition record with this cumulated quantity for each item, set Quantity unit for cumulation and select or create a new group condition routine
- Rounding differences: If the indicator is set, the system compares the condition value at header level with the total of the condition values at the item level. The difference is then added to the largest item.
Group Condition Routine | Description |
Blank characters | To calculate the scale base value of the condition, the sales quantities for all items that have a condition record with the same condition type and the same variable key are added. |
1 (entire document) | To calculate the scale base value of the condition, the sales quantities for all items that have a condition record with the same condition type and the same variable key or a different variable key are added. If there are 2 condition records, both must be created with scales. |
2 (all condition types) | The scale base value of the condition is calculated by adding the sales quantities for all items that have a condition record with the same condition type or that have another condition type that represents a group condition with subroutine 2 AND the same OR another variable key. |
3 (material group) | The scale base value of the condition is calculated by adding the sales quantities for all items that have a condition record with the same condition type AND material pricing group AND the same OR another variable key. |
- Option 1): Create a dummy condition record (K029) with a zero value for all items that K029 would not normally find. Use group routine number 1.
- Option 2): Create a dummy condition type with the same variable key that was used for K029. Create a dummy condition record with a zero value for all items that K029 would not normally find. Use group routine number 2 both for the condition type K029 and for the dummy condition type.
Part 1: pricing for all items
Check field preisfindungsart_kopf if you need to know which type of pricing run will be triggered. Depending on the pricing type the necessary function modules are called.
If you go into this form routine, you’ll see the condition rate of header condition gets duplicated into items, condition origin (xkherk) is set to ‘D’, base value and condition value is set to 0.
Starting from here, this part of logic decides which condition from which item in the group will eventually take the rounding difference KDIFF (if an item is not fixed ( komp-kaend_typ(1) NE '*'). Logic has been explained by SAP Note 403254.
- SAP Note: 24944 Group conditions
- SAP Note: 403254 Distribution rule for rounding difference comparison
- SAP Note: 370487 Info: Distributn header conditions w/ calculation type 'B'
Condition Exclusion/ Konditionsausschluss
- For the simple condition exclusion using requirements, in the configuration for condition types, you can assign a default exclusion indicator to the field Exclusion in the field group Control data 2. For this condition type, the field Exclusion will be then be filled with this indicator by default when you create a condition record. You can also enter the indicator within the condition maintenance for selected condition records. In pricing, when such a condition record is found, the exclusion indicator is transferred to the field komp-kznep in the communication structure KOMP.
- Requirements in the pricing procedure can then check the field komp-kznep and, as a result, subsequent condition types may be not determined (excluded).
- Using the value formula xkomv-kinak = 'X'.
No exclusion at the header level.
- Create an exclusion group (die Ausschlussgruppe)
- Assign condition types (die Konditionsart) to the exclusion group
- Assign the exclusion group to a pricing procedure
- Set the rule to determined the best price:
- Selection of the most favorable condition type within a condition exclusion group
- Selection of the most favorable condition record for a condition type, if several valid condition records exist (e.g. selecting from different condition records for condition type PR00)
- Selection of the most favorable of two condition exclusion groups (in this case, all condition types from both groups are accumulated and the totals compared)
- Exclusive procedure: If a condition type from the first group exists in the document, all conditions types that are found in the second group are set to inactive.
- The condition either does not exist at all (condition exclusion with the exclusion indicator KZNEP) or
- The inactivity indicator (field KONV-KINAK) is filled with the relevant value If required, this is displayed on the condition detail screen.
- This condition exclusion takes place at the time of the automatic condition determination (condition access, FORM XKOMV_AUFBAUEN_AUS_KOMT1, include LV61AA67 and FORM KONDITIONEN_LESEN, include LV61AA29). We can use this exclusion variant to control only the following: whether or not a condition causes follow-up conditions to be excluded from the pricing procedure.
- OV31 Maintain Pricing Exclusion Group
- OV32 Assign Condition Types to Exclusion Group
- VOK8 Assign Exclusion Procedure to Pricing Procedure
- OV23 Exclusion Indicator
Pallet Discounts
- Condition Type KP00
- The aim of the pallet discount is to give a discount only for whole units, e.g. whole pallets.
- This is controlled using the base value calculation formula 22 from the pricing procedure, after the total amount of quantities has been taken into account.
- Condition Type KP01
- The aim of the surcharge for an incomplete pallet is to assign a surcharge for
- This is controlled in the pricing procedure using the base value calculation formula 24. This checks the partial quantity.
- Condition Type KP02
- The aim of the mixed pallet discount is to cumulate the quantities for individual items, but only to calculate the discount for whole pallets.
- This is controlled using the condition type KP02 (Group cond. = X and unit of measure = PAL) and the corresponding condition record.
- Condition Type KP03
- The aim of the surcharge for an incomplete mixed pallet is to cumulate the quantity of items. If there is a partial pallet quantity for a total quantity, a surcharge should be charged.
- This is controlled using the condition type KP03 (Group cond. = X, unit of measure = PAL and scale formula 23, which calculates the partial pallet quantity from the total quantity).
Data Determination in the Access
During pricing, you may want to determine data that is not available in the document and then use it for pricing.- Data determination for pricing
- Determination using communication structure KOMPAZD
- PBP (for data determination)
- PBBS (for using the data in pricing)
- Example: You want to grant prices from a wholesale price list to customer within a given period of time, without changing the master data
- Data determination using routines
- You cannot use communication structure KOMPAZD to determine data for fields that are not used in accesses, such as the scale quantity or the pricing date. In these cases, you must carry out the data transfer using routines.
- PBUD (Data determination)
- KXXX (Use of data) 202 (used to apply the pricing date determined using condition type PBUD for pricing)
- Example: You want to grant prices from a previous year to customers in a certain customer group. These prices are however no longer valid. You enter the pricing date 12.31 from the previous year for pricing.
- Data Determination for Sales Deals
- Condition type PB1 and access PBD are used to determine one or more sales deals.
- Use of data in pricing
Customer hierarchy in use
- HI01 Percentage discount based on the node
- HI02 Absolute discount based on material/node
The system automatically determines a default partner function (in the standard system 1A) in the sales order depending on the hierarchy type (T-Code OVH4).
The system then uses partner determination to find higher-level partner functions, until it has determined the complete hierarchy path for the sales order.
Dummy condition line
When SD price condition record is created in Tx- VK11 with value as 0 , then while creating the sales order for a product the item condition record for the condition type is marked as inactive but certain customizing can be made to make a condition record with value 0 as active condition if business require so.This can be controlled in the SD condition type customizing(Tx-V/06) in the control data 2 section.
Access sequence
- Requirement rule for the table
- Exclusive or Inclusive (Controls whether the system stops searching for a record after the first successful access for a condition type within an access sequence).
Conditions in External Services Management
Entering a condition for a service is to enter a total price condition (an overall estimate of the service to beperformed over a certain time period) using Transaction ML45499722 - FAQ: Pricing/Conditions in External Services Management (ESM)
Pricing in procurement
456691 - FAQ: Price determination in purchasing
- The net price must be zero (EKPO-NETPR = 0.00) after the system has carried out price determination.
- However, the net price is not zero after price determination has taken place and the system does not copy the conditions from the last PO if master conditions that are included in the net price calculation are maintained at, for example, vendor level or material group level.
- The last document is not a request for quotation.
- The info record has not been deleted.
- The vendor and the material in the info record are identical to the vendor and the material in the last document.
- The calculation schema of the last document is the same as the current schema that has been determined.
- The system simply executes a copy function to transfer the conditions from the last document. The system does not check for requirements for the calculation schema.
- The system does not copy the condition records of the subsequent settlement (the condition type has the condition class C); instead, they are always determined again to ensure that the condition records are consistent with the field contents (also see SAP Note 486757).
- If you generally do not want the system to transfer the conditions from the last PO, you can use the user parameter EVO to deactivate this (also see SAP Note 675523).
Condition Interchange
- E1KOMG for filter functions (1:obligatory)
- E1KONH Condition header (n:obligatory)
- E1KONP Condition item (m:obligatory)
- E1KONM Quantity scale (i:optional)
- E1KONW Value scale (j:optional)
- E1KONH
- E1KONP Condition item (m:obligatory)
- Application + Condition type + Condition table + VAKEY
- All data that should be transferred and which belongs to one logical unit, is combined into one Idoc and is dispatched. (that is to say specially for all time periods)
- This unit is also the basis for serialization in inbound processing. In inbound processing only earlier data can be processed for a logical unit.
FAQ
Adjust Pricing Procedure
Based on the condition types, the pricing procedure RVAA04 is configured in such a way that it can be used as the basis for evaluations on the structure of the base values, net values, subsequent compensation, and especially discounts (customer-specific discounts, discounts granted by sales employees, and standard discounts).Reporting and statistics are generally not used at document condition level, but at document item level. The net value (NETWR) and the cost (WAVWR), for example, are available here.
To evaluate how the discounts are distributed, for example, another way of determining the pricing result is necessary. The unrestricted subtotal fields KZWI1 to KZWI6 are available for this purpose. You use the ZWISCHENSUMME indicator to assign the condition types.
- Key figure 1: Base value (value resulting from a basic price to be defined)
- Key figure 2: Standard conditions: (all general conditions which are found automatically and are not customer-specific)
- Key figure 3: Customer-specific conditions (sum of all conditions that are found automatically, that is, customer-specific contractual agreements)
- Key figure 4: Conditions which a sales employee has entered manually in the document
- Key figure 5: Expected expenditure for subsequent compensation paid out during rebate processing
- Key figure 6: Net value
- Key figure 7: Cost (cost of sales transaction)Key figures 6 and 7, net value and cost, are stored in the fields NETWR and WAVWR.
The sum of the condition subtotals 1-4 results in the net value ((KZWI1 to KZWI4) = NETWR).
Standard conditions (KZWI2)
All automatically determined conditions that are not customer-specific (such as minimum price, 100% discount) are assigned to key figure 2.
Rebate conditions (KZWI5)
Here you can find all condition types that are set up as subsequent compensation and therefore have condition class C. These conditions are generally statistical in the documents and represent an estimated value. The actual value is only available later.
Field NETWR is hard-coded and contains the sum of all conditions that are not statistical but active and that are not taxes (indicator inactive = field is empty).
547570 - FAQ: VPRS (cost) in pricing
FAQ: Header conditions or header condition screen
'Actual' header conditions are conditions that are manually entered on the header condition screen. It is never possible to determine 'actual' header conditions using automatic condition determination (condition access). In R/3 standard pricing, the automatic condition access occurs only at item level of the document.
2. Which Customizing settings are required to enter an 'actual' header condition?
In Customizing of the condition type (for example, transactions V/06, M/06) make the following settings in the 'Change Options' section:
- a) Select the header condition checkbox (field KKOPF).
- b) In addition, select at least one of the two checkboxes 'Amount/Percent' (field KAEND_BTR) or 'Value' (field KAEND_WRT).
- c) For 'Manual entries' (field KMANU), do not select the setting 'B' (Automatic entry has priority) or 'D' (Not possible to process manually).
- d) 'Actual' header conditions cannot have access sequences (field KOZGF).
3. How is an 'actual' header condition distributed to the pricing result of the individual document items?
This depends on further Customizing settings of the condition type, in particular on the calculation type (field KRECH) and on whether the group condition (field KGRPE) is set or not.
Example: For a header condition with calculation type 'Fixed Amount', the amount entered on the header condition screen is duplicated in each item if the condition is not set as a group condition.
However, if the condition is set as a group condition, the amount entered on the header is distributed proportionally (that is, in the relationship of the relevant condition bases at item level) and a rounding difference adjustment may be carried out (compare section 7).
4. Which specification has the condition origin and the condition control for 'actual' header conditions?
a) For an 'actual' header condition, you create a row in the table of conditions (database table KONV or internal tables XKOMV and TKOMV) with item number '000000' (field KPOSN) with the following specification:
Condition origin (field KHERK) 'C' (Manually entered)
The condition control (field KSTEU) has the specification
- 'C' (Changed manually), if only a condition rate (not equal to zero) is entered,
- 'E' (Condition value and basis fixed), if a condition value is entered,
- 'A' (Adjust for quantity variance), if neither condition rate nor condition value are entered.
- Condition control (field KSTEU) 'C' (Changed manually)
- Condition origin (field KHERK) 'D' (Header condition)
5. How do 'actual' header conditions behave in copy procedures?
In R/3 standard pricing, conditions are copied only at item level. No 'actual' header conditions are copied. The KONV row from the source document with item number (field KPOSN) '000000' no longer exists in the target document. Only the 'item portions' of the header condition are copied to the target document at item level during the copy procedure.
As a result, these conditions become item conditions in the target document, for example, with the following values for the calculation rules 'Fixed Amount' and 'Group Condition'.
- Condition control 'E' (Condition value and basis fixed)
- Condition origin 'G' (Original header condition)
6. How do 'actual' header conditions behave in (milestone) billed documents?
If you display the (milestone) billed document in display mode, the system displays the 'actual' header condition in a single row, for example:
CType | Description | Amount | Curr. per UoM | Condition value | Curr. |
HB00 | Absolute discount | 20.00- | EUR | 20.00- | EUR |
However, if you call the (milestone) billed document in change mode, the system must split the header condition in two rows: One row for the already billed items and one row for the outstanding items.
The following section explains this system response using the example of an 'actual' header condition with the calculation type 'Fixed amount' (for example, the condition type HB00 in the R/3 standard system).
7. Examples for question 6
An order has 5 items. On the header, the HB00 discount is entered with an amount of EUR 20.00- and is distributed proportionally to the open items, for example, as follows:
Item | Cond. base | Cond. val. for HB00 | ||
10 | 15.76 | 15.76 / 56.57 * 20.00 = 5.5718... | ---> | 5.57- |
20 | 12.51 | 12.51 / 56.57 * 20.00 = 4.4228... | ---> | 4.42- |
30 | 8.26 | 8.26 / 56.57 * 20.00 = 2.9202... | ---> | 2.92- |
40 | 17.21 | 17.21 / 56.57 * 20.00 = 6.0844... | ---> | 6.09- |
50 | 2.83 | 2.83 / 56.57 * 20.00 = 1.0005... | ---> | 1.00- |
Total | 56.57 (EUR) | (EUR) | 20.00- |
There is a milestone billing for this order and the items 10, 20 and 30 are billed. The order is now called in change mode. Items 10, 20 and 30 and therefore their pricing result are fixed, whereas items 40 and 50 (for example, change of the sales quantity) or the order itself (for example, creation of further items) remain open for changes.
To display the condition on the header condition screen, the system proceeds as follows:
The fixed item portions of the billed items are added (5.57- + 4.42- + 2.92- = EUR 12.91-) and displayed in one row with condition control 'E' (Condition value and basis fixed) and condition origin 'E' (Items total). In addition, the amount of EUR 20.00- initially entered manually on the header is reduced by the fixed portions (20.00 - 5.57 - 4.42 - 2.92 = EUR 7.09) and displayed in one row with the specification 'C' (Changed manually) for the condition control and 'C' (Manually entered) for the condition origin.
CType | Description | Amount | Curr. per UoM | Condition value | Curr. |
HB00 | Absolute discount | 12.91- | EUR | ||
HB00 | Absolute discount | 7.09- | EUR | 7.09- | EUR |
In this case, the outstanding condition rate of EUR 7.09- is distributed in relation to the (new) condition bases of the outstanding items (in the example, items 40 and 50).
Example: The order quantity of item 50 (or the PR00 price) is tripled, which also triples the condition basis for HB00 to EUR 8.49. This has the following result:
Item | Cond. base | Cond. val. for HB00 | ||
*10 | 15.76 | 15.76 / 56.57 * 20.00 = 5.5718... | ---> | 5.57-* |
*20 | 12.51 | 12.51 / 56.57 * 20.00 = 4.4228... | ---> | 4.42-* |
*30 | 8.26 | 8.26 / 56.57 * 20.00 = 2.9202... | ---> | 2.92-* |
40 | 17.21 | 17.21 / 25.70 * 7.09 = 4.7478... | ---> | 4.75- |
50 | 8.49 | 8.49 / 25.70 * 7.09 = 2.3421... | ---> | 2.34- |
Total | 25.70 (EUR) | (EUR) | 7.09- | |
Overall total | (EUR) | 20.00- |
In this case, the newly created item is included in the distribution of the outstanding condition rate of EUR 7.09-.
Example: Item 60 is created with a condition rate of EUR 13.97 for HB00. This has the following result:
Item | Cond. base | Cond. val. for HB00 | ||
*10 | 15.76 | 15.76 / 56.57 * 20.00 = 5.5718... | ---> | 5.57-* |
*20 | 12.51 | 12.51 / 56.57 * 20.00 = 4.4228... | ---> | 4.42-* |
*30 | 8.26 | 8.26 / 56.57 * 20.00 = 2.9202... | ---> | 2.92-* |
---------------------------------------------------------------------------------------------------- | ||||
40 | 17.21 | 17.21 / 34.01 * 7.09 = 3.5877... | ---> | 3.59- |
50 | 2.83 | 2.83 / 34.01 * 7.09 = 0.5899... | ---> | 0.59- |
60 | 13.97 | 13.97 / 34.01 * 7.09 = 2.9122... | ---> | 2.91- |
Total | 34.01 (EUR) | (EUR) | 7.09- | |
Overall total | (EUR) | 20.00- |
In this case, the changed condition rate is distributed to the outstanding items in relation to the condition bases of HB00.
Example: The condition rate for HB00 is reduced from EUR 7.09- to EUR 5.00-. This has the following result:
Item | Cond. base | Cond. val. for HB00 | ||
*10 | 15.76 | 15.76 / 56.57 * 20.00 = 5.5718... | ---> | 5.57-* |
*20 | 12.51 | 12.51 / 56.57 * 20.00 = 4.4228... | ---> | 4.42-* |
*30 | 8.26 | 8.26 / 56.57 * 20.00 = 2.9202... | ---> | 2.92-* |
---------------------------------------------------------------------------------------------------- | ||||
40 | 17.21 | 17.21 / 20.04 * 5.00 = 4.2939... | ---> | 4.29- |
50 | 2.83 | 2.83 / 20.04 * 5.00 = 0.7060... | ---> | 0.71- |
Total | 20.04 (EUR) | (EUR) | 5.00- | |
Overall total | (EUR) | 17.91- |
d) What happens if the three examples a), b), and c) are combined?
In this case, EUR 5.00- for HB00 is distributed to items 40, 50 and 60 in relation to their condition bases with the amounts EUR 17.21, EUR 8.49 and EUR 13.97.
Item | Cond. base | Cond. val. for HB00 | ||
*10 | 15.76 | 15.76 / 56.57 * 20.00 = 5.5718... | ---> | 5.57-* |
*20 | 12.51 | 12.51 / 56.57 * 20.00 = 4.4228... | ---> | 4.42-* |
*30 | 8.26 | 8.26 / 56.57 * 20.00 = 2.9202... | ---> | 2.92-* |
---------------------------------------------------------------------------------------------------- | ||||
40 | 17.21 | 17.21 / 39.67 * 5.00 = 2.1691... | ---> | 2.17- |
50 | 8.49 | 8.49 / 39.67 * 5.00 = 1.0700... | ---> | 1.07- |
60 | 13.97 | 13.97 / 39.67 * 5.00 = 1.7607... | ---> | 1.76- |
Total | 39.67 (EUR) | (EUR) | 5.00- | |
Overall total | (EUR) | 17.91- |
8. What is the significance of the KAWRT and KWERT fields in the KONV database table for an 'actual' header condition?
There is no significance. In the KONV database table, only the condition rate (field KBETR) is relevant for an 'actual' header condition.
The condition basis (field KAWRT) and the condition value (field KWERT) of an 'actual' header condition are (re)calculated during R/3 pricing, if they are required (for example, when displaying the header pricing screen).
The system calculates them by adding up the condition bases and condition values of the relevant items.
Therefore, in user-defined programs (for example, in print), you must not access the contents of KAWRT and KWERT, but in the same way as R/3 standard pricing, the system should determine these values dynamically at runtime.
The values saved in the database table (generally) correspond to the values that were determined the last time the header condition screen was displayed (FORM XKOMV_AUFBAUEN_KOPFSUMMEN in the PRICING_SUBSCREEN_PBO function module).
If you now enter an 'actual' header condition and, for example, save the document immediately afterwards (that is, without activating the header condition), the system no longer displays the header condition screen. In this case, the PRICING_SUBSCREEN_PBO function module no longer runs and the KAWRT and KWERT fields of the 'actual' header condition are still filled with the initial value 0.00.
9. What is meant by 'item totals'?
'Item totals' are condition rows on the header condition screen that represent a summation of item conditions. These item conditions are conditions that (unlike 'actual' header conditions) have their origin on the items of this document, for example:
- Automatically determined conditions:
Condition control 'A' (Adjust for quantity variance)
Condition origin 'A' (Automatic pricing)
- Automatically determined and manually changed conditions:
Condition control 'C' (Changed manually)
Condition origin 'A' (Automatic pricing)
- Manually entered conditions:
Condition control 'C' (Changed manually)
Condition origin 'C' (Manually entered)
- Original 'actual' header conditions on already (milestone) billed items (compare with items 10 - 30 in the example for question 6):
Condition control 'E' (Condition value and basis fixed)
Condition origin 'G' (Original header condition)
- Original 'actual' header conditions copied from a source document using a copy procedure (compare with section 5):
Condition control 'E' (Condition value and basis fixed)
Condition origin 'G' (Original header condition)
'Items totals' have the specification 'E' (Items total) for the condition origin on the header condition screen. The condition control has the specification of the first item condition that was incorporated in this 'items total' ('First item condition' according to the sorting described in section 10).
10. How are 'item totals' displayed?
The summation of the item conditions for the display on the header condition screen occurs in the XKOMV_AUFBAUEN_KOPFSUMMEN FORM (include LV61AA60). In this case, item conditions are summarized as much as possible. In other words: If certain criteria are not fulfilled, there is a split into two or more rows.
In detail, the system proceeds as follows:
The internal table TKOMV, which contains all conditions of the document, is sorted according to the following key:
KNUMV STUNR ZAEKO KSCHL KSTAT KRUEK KHERK KRECH KWAEH KGRPE IX_GKOMV KINAK KBETR KNUMH
After that, the table entries are run in the sequence that was just created.
The row that was just edited is added to the row currently in the structure for the header condition screen (= 'Items total'), provided that none of the following split criteria is fulfilled.
However, if at least one of the split criteria is fulfilled, the system starts with the structure of a further row for the header condition screen (= a further 'Items total').
The following split criteria are taken into account by the system:
- Different condition type in both rows (field KSCHL).
- Different step number in both rows (field STUNR).
- The condition of one row is statistical, the condition of the other row is not (field KSTAT).
- The condition of one row is relevant for accrual, the condition of the other row is not (field KRUEK).
- The condition rows do not originate from the same 'actual' header condition (field ZAEKO).
- There is a different alternative currency in both rows (field KWAEH).
- There is a different inactivity indicator in both rows (field KINAK).
- For variant conditions: There is a different condition record number in both rows (field KNUMH).
- For automatically determined group conditions: Different condition rate (field KBETR), different calculation type (field KRECH) or processing in different groups (field IX_GKOMV) in both rows.
For the cumulation of the item totals, the following system response was established with correction note 2902489:
- If the item conditions included in an item total differ in at least one of the fields for the condition amount (KBETR), condition currency (WAERS), price unit (KPEIN), or condition unit (KMEIN), none of these four fields is displayed in the item total.
- If the item conditions included in an item total differ in the calculation rule (KRECH) or condition unit (KMEIN), the condition bases (KAWRT) cannot be cumulated and the calculation rule, condition base, and condition unit are not displayed in the item total.
- If the item conditions included in an item total differ in the scale base price (KZBZG), scale base unit (KONMS), or scale base currency (KONWS), the scale bases (KSTBS) cannot be be cumulated and the scale base price, scale base, scale base unit, and scale base currency are not displayed in the item total.
- If the items included in an item total differ in their debit/credit indicator (SHKZG), the relevant plus/minus signs of the items are taken into account during the cumulation of the condition bases and scale bases.
Also note the following:
- a) Item conditions excluded with an inactivity indicator (field KINAK) not equal to 'Y' or 'A' (see Note 836243) are not included at all in the header condition screen. In other words: Only active conditions or inactive conditions with 'Y' or 'A' are included in the header condition screen.
- b) Statistical conditions (for example, the condition type VPRS) appear on the header condition screen, provided that they are not inactive as described in a).
- c) The 'item totals' are only 'virtual' condition rows. They are only created (dynamically) at runtime during the display of the header condition screen and are not saved in the database table KONV.
- d) Cumulated conditions (field KDUPL = 'B') are not displayed on the header condition screen (see Note 844141).
11. How do 'actual' header conditions or 'item totals' behave during the deletion?
Note 647240 answers this question.
How to
Access with the partial table key
Create access with several steps. For each step map only several fields ( not all ).Add new fields
- USEREXIT_PRICING_PREPARE_TKOMK in RV60AFZZ .
- USEREXIT_PRICING_PREPARE_TKOMP in RV60AFZZ.
Advanced Techniques, Tips, and Tricks
Data Determination via Condition Technique
- Data determination in the access, use in subsequent accesses
- ->KOMPAZD
- Data determination in the access, transfer to document item via the requirement
- KOMP->VBAP/VBRP
- form kobed_902. If not kompazd-zzmvgr1 is initial. komp-mvgr1 = kompazd-zzmvgr1. endif. If not kompazd-zzmvgr2 is initial. komp-mvgr2 = kompazd-zzmvgr2. endif. If not kompazd-zzmvgr3 is initial. komp-mvgr3 = kompazd-zzmvgr3. endif. perform kobed_002. endform.
- The disadvantage is that you cannot handle every field this way. The method is only possible for fields that are used in the sales order exclusively for pricing or for follow-up functions such as SAP BW, CO-PA, statistics, output, etc.
- Fields of the header (VBAK) or of the commercial data (VBKD) cannot be determined with this method.
- Transfer to document condition via formula (manipulation of the calculation)
- XKOMV
- Transfer to KOMK via requirement (manipulation of the condition access)
- KOMK
- Use of data from other document conditions in formulas
- KOMP->VBAP/VBRP
Fields with Multiple Values
Important Programs for Pricing
PRICING function module
PRICING_COMPLETE Function Module
PRICING_COPY Function Module
PRICING_REFRESH Function Module
System Adaptation Using Requirements, Formulas, and User Exits
Pricing Types
Requirements
Formulas for Pricing Conditions
Condition base formulas (also called base formulas)
Scale base formulas (also called scale formulas)
Condition value formulas (also called value formulas)
Group key routines
User Exits
Routine USEREXIT_PRICING_COPY
Routine USEREXIT_PRICING_RULE
Routine USEREXIT_PRINT_HEAD
Routine USEREXIT_PRINT_ITEM
Routine USEREXIT_XKOMV_BEWERTEN_END
Routine USEREXIT_XKOMV_BEWERTEN_INIT
Routine USEREXIT_XKOMV_ERGAENZEN
Routine USEREXIT_XKOMV_ERGAENZEN_MANU
Routine USEREXIT_XKOMV_FUELLEN
Routine USEREXIT_XKOMV_FUELLEN_O_KONP
Routine USEREXIT_CHANGE_PRICING_RULE
Routine USEREXIT_FIELD_MODIFICATION
Routine USEREXIT_FIELD_MODIFIC_KOPF
Routine USEREXIT_PRICING_CHECK
Typical Practice Demands on Pricing and Their Solutions
Budgeting Requirements
Prices with More Than Two Decimal Places
Handling Freight Surcharges
- For freight surcharges that are configured as group condition types with a fixed value, the condition amount is valid for the entire order. We find this same property in the manual header condition types. We know that for these condition types, the amount is distributed among the items. This means in the case of partial deliveries, that the shipping costs are calculated in proportion to each partial invoice. However, it is common to bill the total shipping cost with the first (partial) invoice and then the remaining deliveries are free.
- This functionality is not provided in the standard SAP system. However, there is an SAP Note 25144 (Freight Conditions for Milestone Billing) that meets this demand via a user exit.
- No Freight Surcharges for Free Goods and Returns
- The request for the free goods items can be met by assigning to the respective condition types the requirement 057 (not for free goods) in the pricing procedure. However, with regard to the handling of returned goods, this requirement resolves only the problem of return items within a sales order. It provides no solution for return documents that are created, for example, with reference to a sales order or a billing document. Both demands are fulfilled by the requirement 957 (not for free goods/returns)
Authorizations for the Pricing Screen
Adding Subtotal Fields
Copied Conditions and Subsequent Quantity Changes
Increased Prices in Returns and Credit Notes
Pricing in Selected Applications
Pricing in Sales Orders
Routine USEREXIT_PRICING_PREPARE_TKOMK
Routine USEREXIT_NEW_PRICING_VBAP
Routine USEREXIT_NEW_PRICING_VBKD
Pricing in Billing Documents
Pricing in Purchase Orders
Pricing in Transport Management (Shipment Cost Calculation)
Pricing in Accounting
- TX: Tax determination in accounting
- KA: Cost center accounting: overhead costing
- KE: Profitability analysis: planning
Rebate Processing in Sales
Additional information
3038656 - VPRS and Cumulation
In case of an invoice created from delivery document with batch split and 'Cumulative Cost' flag set for main and batch items in Copy Control. If the Higher-Level Batch item (LIPS-UEPOS) of the subitem is referring to other main item, then the cost of this subitem will be cumulated to the other main item resulting in duplication of cost.With this proposal you can set your own specific criteria to restrict the changes.
*IF < specific criteria >.
IF TVCPF-KVPRS IS NOT INITIAL.
LOOP AT ALIPS WHERE VBELN EQ LIPS-VBELN
AND ( UECHA EQ LIPS-POSNR OR
UEPOS EQ LIPS-POSNR ).
IF NOT ALIPS-UECHA IS INITIAL.
CLEAR ALIPS-UEPOS.
MODIFY ALIPS.
ENDIF.
ENDLOOP.
ENDIF.
*ENDIF.
722300 - Statistical val GRWR contained twice in intercompany billing
You create a billing document in an intercompany billing process.In the copy control between delivery document and billing document, the following settings are maintained among other things for the relevant item category:
- Pricing type (field KNPRS) G Copy pricing elements unchanged
- Redetermine taxes
- Price source (field PRSQU) A Purchase Order
In the created billing document, two rows with condition type GRWR exist on the item condition screen.
1. Condition type GRWR is delivered in the R/3 standard system with the following condition category (field KNTYP):
Application (field KAPPL) Condition category (field KNTYP)
'V' (Sales) 'L' (In general new when copying)
'M' (Purchasing) ' '
2. Condition type GRWR is on a different step number in the pricing procedure of Sales and Distribution than in the pricing procedure of Purchasing.3. Design of pricing in the R/3 system with respect to redetermination of conditions and the transfer of existing conditions
2414653 - Price condition is inactive in the purchase order
183820 - Print of inactive conditions
24832 - Pricing rules/TVCPF
- No condition types are redetermined. Only the scale prices are adapted due to a changed basis.
- Completely new pricing (as if you created a new item), manual conditions are lost.
- Completely new pricing, manual ones are copied.
- Caution: Here you have to make sure that all condition types that can possibly be changed manually have T685A-KMANU = 'C' (Manual entry has priority) in Customizing. Otherwise, the conditions may be displayed twice (automatic and manual) and both may be active.
- As in pricing type A but the prices are fixed (no scales are read). Condition basis and condition basis value are redetermined.
- As in pricing type D but neither the condition basis nor the condition basis value are redetermined.
- Only used within the program.
- Condition class KOAID = 'D' (Taxes)
- Condition class KOAID = 'C' (Rebate)
- Condition category KNTYP = 'I' (Intercompany billing conditions)
- Condition category KNTYP = 'R' (Remuneration list conditions)
- Condition category KNTYP = 'L' (Generally new when copying)
- Condition category KNTYP = 'G' (Cost)
- Condition category KNTYP = 'E' (Cash discount conditions)
- Condition type KNTYP = 'B' (Delivery costs)
- Condition type KNTYP = 'F' (Freight conditions)
- Condition category KNTYP = 'L' (Generally new when copying)
- Rebate conditions and scales are redetermined.
- Condition types with condition category KNTYP = 'D' (Confirmed purchase net price/value) are redetermined.
- Condition class KOAID = 'D' (Taxes)
- Condition class KOAID = 'C' (Rebate)
- Condition category KNTYP = 'R' (Remuneration list condition)
- Condition category KNTYP = 'I' (Price for intercompany billing)
- Condition category KNTYP = 'E' (Cash discount)
- No conditions are redetermined; the condition values are multiplied by -1 when copied.
- Condition types with condition category KNTYP = 'G' (Cost) are redetermined.
- Please note that this pricing type has NO effect on the billing document since here the goods issue value from the delivery is usually directly transferred to pricing. Redetermination of the costs by subsequently reading the material valuation segment when executing pricing type "N" would result in the goods issue value information being irretrievably lost.
- This standard behavior can be changed by a modification only.
- Condition types with condition category KNTYP = 'O' (Variants) are redetermined.
- The system does not redetermine any conditions; only the revaluation occurs.
- 'Q' (Redetermine calculation conditions)
- Condition types with condition category KNTYP = 'Q' (Costing) are redetermined.
- Condition types with condition category KNTYP = 'U' (Discount/surcharge for precious metals) are redetermined.
2706031 - Consulting: How to use the parameter IV_CALLER_ID of the RFC-enabled function module PIQ_CALCULATE
If you want to use the RFC-enabled function module PIQ_CALCULATE for the price inquiry you have to provide the value ‘PL’ for the parameter IV_CALLER_ID, if you want to use your own customizing or own fields within the net pricelist calculation.This ensures that standard customizing for the price inquiry is applied and is extended or overwritten by customer-specific customizing settings.
Only in the rare case that your own customizing and your own fields shall not be considered, then you have to provide the value ‘STD’ for the IV_CALLER_ID.
930537 - Interval scales: Functions and restrictions
2739880 - Consulting: Manual change to net price of item
2927325 - Restrictions for pricing in S/4 Hana customer management
- Condition exclusion using exclusion indicator KZNEP
- Cost conditions
- Tracking cumulative values with condition update
- Data sources
- Quantity adjustment
- Agreed conversion factors
- Configurable parameters and formulas in pricing (CPF)
- Commodity pricing
- Pricing Analysis
1391347 - Field KOMK-AUGRU in billing document
Caution: The performance may worsen!
The attached solution proposal offers a possible solution in the include RV60AFZZ, subroutine USEREXIT_PRICING_PREPARE_TKOMK.
2953640 - Performance improvement due to prestep for accesses
To improve system performance, you can optimize the accesses for a condition type by having the system carry out a prestep. You use the prestep to determine whether the system should first only search for condition records using the document header data. If the search is unsuccessful, then this access is no longer used for the individual items.In pricing, you use a customer/material discount. The condition records you maintained are based on customer data from the document header and material data from each document item. However, this type of customer/material discount is valid only for 2% of your customers. This would mean that the system would needlessly search through every available item in 98% of cases. In this case, the prestep would improve system performance.
2756425 - Conditions AMIW/AMIZ: Minimum Order Value exceeded
If the sales order value is low, the AMIZ surcharges are applied to the order items, raising the order's net value to the required minimum.
In some cases, however, the order's net value is raised to a value that is higher than the minimum required.
Reason and Prerequisites
The issue occurs when the sales order contains a large number of low-value items, and is compounded when the items are identical.
In this case the rounding difference on a fixed-amount group condition AMIW (a difference between the condition value on the document level and the total of all condition values calculated on the item level) tends to be quite significant. In accordance with the distribution rules for rounding difference adjustment (see SAP Note 403254), the rounding difference is added to the item with the largest condition base, to minimize the impact on the item’s value.
If the initial value of a chosen item is low, and the rounding difference happens to be negative, then the value of the AMIW condition will be reduced significantly and may even become negative.
This drastic change to the value of AMIW condition affects the calculation of a required minimum value surcharge (condition AMIZ) in the alternative condition value formula 013. The surcharge is not applied (the condition value is determined as zero), and the total value of the AMIZ surcharges applied to other items is greater than the value that would bring the order value to the required minimum. As a result, the sales order's value is higher than expected.
Solution
Since the issue only occurs in certain unusual scenarios, which are degenerate (limiting) cases, the standard logic in formula 013 will not be altered.
If you require the consulting solution that covers these special cases, proceed as follows:
- Use transaction VOFM (see SAP Note 327220) to create a condition basis formula in the customer namespace, which contains the source code from the attached condition basis formula 999.
- Assign the condition basis formula from (1) in the affected calculation schema to the AMIZ condition.
2907944 - Field Gross Value is zero in invoice
The Gross Value is only filled if a corresponding subtotal line is defined in the pricing procedure, otherwise it does not really make sense to display this column, so by default, this field is not updated.Check your pricing procedure in V/08. You have to use the sub-total line in the pricing procedure. It has to be assigned to the sub-total 'Copy values to KOMP-BRTWR (gross value)' (sub-total '9')
109708 - Scale processing for group condition
In a document, if items occur in which condition records are generatedfor condition type ZGRS for which no scale is stored, the system does not take the scale base value for these items into account in the cumulation.Example (group condition with key routine 2 and quantity scale)
Item 10 5 pcs ZGRS Condition record 20.00 $ for each piece to 6 pcs
19.00 $ for each piece to 20 pcs
Item 20 5 pcs ZGRS Condition record 22.00 $ for each piece w/o scale
Although for item 10 because of the total quantity you might expect an amount of 19,00 $ for each piece, you receive 20,00 $ since the quantity of item 20 is not taken into account in the scale base value cumulation.
As a result, the restriction applies that all condition records of thecorresponding condition type must have the same scale type, which, in addition, must also match the value in the user exit. Sensibly, this scale type is predefined in Customizing of the condition type.
Adjust the specified user exits in accordance with the attached source code. Scale type 'A' was chosen as an example. For other values you must change the source code accordingly. Also consider the different variants for condition types with value scales or quantity scales.
Scale type
The scale type specifies whether the scale values stored are from-, to-or graduated scales. You can maintain this in Customizing of the condition type or, under certain circumstances, you can determine this in the condition record.
912340 - Pricing: Condition access occurs in two steps
- A tables, such as A004, A305, A999
- KONH conditions (header)
- KONP conditions (item)
- KONW conditions (quantity scale 1-dim.)
- KONW conditions (value scale 1-dim.)
- Table KONH, for example, stores general administrative data, such as the name of the person who entered the data (ERNAM) or the entry date (ERDAT).
- Table KONP stores the actual condition record information, such as the condition rate (KBETR) and the currency (KONWA).
- Tables KONM and KONW (where they exist) store the quantity scale and value scale data.
- Similar to the two-step data model, condition access also occurs in two steps.
- To begin with, in the first step, the field attributes specified by the pricing communication structures [header (T)KOMK and item (T)KOMP] are used to search for a suitable condition record in the A table (function module SD_COND_ACCESS, program SAPLV61Z).
- If a valid condition record is found, the KNUMH of this record is returned to pricing (FORM KONDITIONEN_LESEN, include LV61AA29, program SAPLV61A). Then, using this KNUMH, tables KONH, KONP, KONM, KONW or appropriate buffered internal tables are read in a second step within the context of pricing.
- 10 305 Customer/material with KFRST X
- 20 304 Material with KFRST X
- Condition 1 > > access sequence 1 > > 1 access to table A305
- Condition 2 > > access sequence 2 > > 1 access to table A304
201830 - Calculation of the net price of an item
The net price is not as expected. In particular, the origin of its unit of measure and/or condition pricing unit is unclear.- a) The unit of measure (KOMP-KMEIN or YKMEIN) and the pricing unit (KOMP-KPEIN or YKPEIN) are taken from the last active, non-statistical price if its calculation type is neither percentage-based ("AHI") nor absolute ("BT").
- b) If an active, non-statistical price does not exist, the unit of measure and pricing unit are taken from the first active statistical price. As in point a), however, this is only done if it does not have either a percentage-based or absolute calculation type.
- c) If neither an active, non-statistical price nor an active, statistical price exists with a corresponding calculation type, the base unit of the material (KOMP-LAGME) is used as the unit of measure, and 1 is used as the pricing unit.
3. Determination of value:
a) The value of the net price (KOMP-NETPR) is determined by dividing the net value of the item (KOMP-NETWR) by the quantity, taking account of the pricing unit.
However, if the net value of the item is the same as the condition value of the active price, special logic is used:
In this case, the value of the net price is filled directly from the condition amount (YKBETR) of the active price. This prevents avoidable rounding differences.
If the condition currency of the active price differs from the document currency, the condition amount is converted to the document currency. Currency conversion is carried out in the same way as conversion of the condition amount to the document currency during determination of the condition value of the pricing condition.
This not only applies when the active price is a (final) non-statistical price (see the "standard case" 1.a), but also when the active price is a (first) statistical price (see "exceptional case" 1.b).
For a condition that is neither percentage-based nor absolute, the conversion factors XKOMV-KUMZA and XKOMV-KUMNE are a value other than zero in the R/3 standard pricing (as otherwise, the quantity conversion from base unit of measure to condition unit would also fail, for example). This fact is used to determine the pricing unit and unit of measure of the net price.
If a pricing condition (for example ZPR0) is determined automatically, but it does not have an access sequence and the condition amount is determined using FORM USEREXIT_XKOMV_FUELLEN_O_KONP (include RV61AFZB) or a customer-specific condition basis formula or value formula, for example, this can cause the above logic to function incorrectly.
Example:
Let us assume that ZPR0 (with a non-percentage-based and non-absolute calculation rule) is the last active, non-statistical pricing condition, followed by (at least) one active, statistical pricing (for example cost VPRS).
If the conversion factor XKOMV-KUMZA of ZPR0 equals zero, variable YKUMZA is filled with zero during the processing of ZPR0. During the subsequent processing of VPRS, the system cannot tell that an active, non-statistical price (namely ZPR0) has already occurred, and it fills YKPEIN and YKMEIN with the pricing unit and unit of measure from VPRS.
During condition determination in modifications, you must therefore note that the system not only fills fields such as the condition amount (XKOMV-KBETR), pricing unit (XKOMV-KPEIN), and unit of measure (XKOMV-KMEIN), but is also fills the conversion factors XKOMV-KUMZA and XKOMV-KUMNE (at least with the initial values 1 and 1).
2993900 - Intercompany Pricing conditions are not showing on Sales Order after system upgrade
- Create the sales order via VA01 or create the invoice via VF01;
- Go to item condition, intercompany pricing condition is not determined.
LV61A022 checks whether the "Determine Cost" (TVAP-EVRWR) flag is set. If KOMP-EVRWR is not set in Tcode VOV7, the requirement 022 fails and intercompany pricing condition is not determined. And this check on TVAP-EVRWR occurs after system upgrade due to note 2150258 - Transfer prices determined twice during batch split.
22963 - Rounding problems in condition basis
If the condition unit is different from the sales unit, rounding errors may occur in pricing.- The base unit of measure and the sales unit of a material are KG. The price PR00 is 100.00 EUR for each American pound (LB). 4536 KG equals 10000 LB. Then you create an order with the quantity of 0.5 KG. The net value is then 1.102 LB * 100 EUR/1 LB = 110.20 EUR. However, the exact value is 110.23 EUR (rounded up from 110.229 EUR).
To use the table T006 in the formula, you must change LV61ATOP for the specified releases.
data: zvrkme like komp-vrkme,
zkmein like xkomv-kmein,
zkwert like xkomv-kwert.
data: zdim1 like t006-dimid,
zdim2 like t006-dimid.
check: komp-kposn ne 0,
preisfindungsart ne 'E',
xkomv-krech ca 'CDEF'.
data: xxarbfeld(16) type p.
data: rett_kawrt like xkomv-kawrt.
data: rett_kofrm like xkomv-kofrm.
* determine dimension ZDIM1 of sales unit
if komp-vrkme <> zvrkme.
select single * from t006 where msehi = komp-vrkme.
if sy-subrc = 0.
zdim1 = t006-dimid.
zvrkme = komp-vrkme.
else.
clear: zdim1, zvrkme.
endif.
endif.
* determine dimension ZDIM2 of condition unit
if xkomv-kmein <> zkmein.
select single * from t006 where msehi = xkomv-kmein.
if sy-subrc = 0.
zdim2 = t006-dimid.
zkmein = xkomv-kmein.
else.
clear: zdim2, zkmein.
endif.
endif.
* if dimensions are identical use regular unit conversion
* sales unit -> condition unit
if zdim1 = zdim2.
check zdim1 ne space.
* increase accuracy by 3 digits
xxarbfeld = komp-mgame * 1000.
if komp-vrkme ne xkomv-kmein.
if komp-vrkme ne komp-meins.
call function 'UNIT_CONVERSION'
exporting
matnr = komp-matnr
meins = komp-meins
meinh = komp-vrkme
mgame = xxarbfeld
umrez = komp-umvkz
umren = komp-umvkn
importing
o_mglme = xxarbfeld
exceptions
error_message = 4.
check sy-subrc = 0.
endif.
if xkomv-kmein ne komp-meins.
call function 'UNIT_CONVERSION'
exporting
matnr = komp-matnr
mglme = xxarbfeld
meins = komp-meins
meinh = xkomv-kmein
importing
o_mgame = xxarbfeld
exceptions
error_message = 4.
check sy-subrc = 0.
endif.
endif.
* do not recursively execute this formula 602
rett_kofrm = xkomv-kofrm.
clear xkomv-kofrm.
* save original condition base for later use
rett_kawrt = xkomv-kawrt.
xkomv-kawrt = xxarbfeld.
perform xkomv_kwert_ermitteln.
zkwert = xkomv-kwert / 1000.
* restore former values
xkomv-kawrt = rett_kawrt.
xkomv-kofrm = rett_kofrm.
else.
* different dimensions of sales unit and condition unit:
* use conversion factors for sales unit -> condition unit
* determination of condition base can be done with higher accuracy
if ( xkomv-krech = 'C' and komp-meins ne xkomv-kmein )
or ( xkomv-krech = 'D' and komp-gewei ne xkomv-kmein )
or ( xkomv-krech = 'E' and komp-gewei ne xkomv-kmein )
or ( xkomv-krech = 'F' and komp-voleh ne xkomv-kmein ).
case xkomv-krech.
when 'C'.
xxarbfeld = komp-mglme.
when 'D'.
xxarbfeld = komp-brgew.
when 'E'.
xxarbfeld = komp-ntgew.
when 'F'.
xxarbfeld = komp-volum.
endcase.
* condition base in condition unit with accuracy increased by 3 digits
xxarbfeld = xxarbfeld * 1000 * xkomv-kumne / xkomv-kumza.
* do not recursively execute this formula 602
rett_kofrm = xkomv-kofrm.
clear xkomv-kofrm.
* save original condition base for later use
rett_kawrt = xkomv-kawrt.
xkomv-kawrt = xxarbfeld.
perform xkomv_kwert_ermitteln.
zkwert = xkomv-kwert / 1000.
* restore former values
xkomv-kawrt = rett_kawrt.
xkomv-kofrm = rett_kofrm.
else.
* determination of condition base has already been done with maximum
* accuracy, therefore condition value is correct
zkwert = xkwert.
endif.
endif.
xkwert = zkwert.
endform.
...
*&--------------------------------------------------------------------*
114756 - Customer hierarchy determination for pricing
Prerequisite: This function is not implemented in the standard system.Cause: The customer hierarchy is not read with the pricing date (PRSDT), but always with the current date (SY-DATUM).
This will ensure that the system reads the customer hierarchy for the pricing with the pricing date, when you enter orders or create a billing document using user exits.
To ensure that the system performs a new pricing for the affected hierarchy conditions, the condition category must be set to "L" (KNTYP = 'L').
Then, when you create a billing document, the system always carries out a new pricing for these conditions.
This means that the system not only takes the customer hierarchy into account again, but the new pricing also incorporates any changes to the condition record.
Comment 2:
To keep the above solution performing for Releases up to and including Release 4.5B, change structure KOMK (Pricing Header) as follows:
Move the fields used for the customer hierarchy.
- HIENR01 to HIENR15
- HIEBO01 to HIEBO15
- HIEZU01 to HIEZU10 (from .INCLUDE TKOMKHIE )
behind field SUPOS.
This means that the following applies:
...
Field Name Data Element Type Length Check tab
TXJCD3 TXJCD3 CHAR 15 TTXJ
HITYP_PR HITYP_PR CHAR 1
>>>>>> Begin of Deletion <<<<<<
HIENR01 HIENR01 CHAR 10
HIENR02 HIENR02 CHAR 10
...
HIEBO14 HIENR14 CHAR 10
HIEBO15 HIENR15 CHAR 10
>>>>>> End of Deletion <<<<<<
....
.INCLUDE KOMKHIE <<<<<<<<<<<<<<<<<<< delete
....
...
...
.INCLUDE KOMKAJ1 0
SUPOS NETWR CURR 15
>>>>>> Begin of Insertion <<<<<<
HIENR01 HIENR01 CHAR 10
HIENR02 HIENR02 CHAR 10
...
HIEBO14 HIENR14 CHAR 10
HIEBO15 HIENR15 CHAR 10
.INCLUDE KOMKHIE
>>>>>> End of Insertion <<<<<<
To do this, use transaction SE11 "ABAP Dictionary: Initial screen". To move the field block, choose "Edit" from the menu. Then choose "Select block", "Cut" and then "Paste".
Afterwards, check and activate the structure.
Comment 3:
The customer hierarchies determined in this way are not copied to the Sales Information System (SIS) since the determination of the hierarchies in the SIS is carried out using the table VBPA of the partner data and not using the pricing header communication structure (structure TKOMK).
Re-determine or not? (22.07.2021)
SAPLV61A/LV61AA65/XKOMV_AUFBAUEN_PRUEFEN
Troubleshooting Guide for Message 108 in Pricing Analysis (22.07.2021)
- Condition line has been deleted manually
- The customer deleted the line in XKOMV manually. This case represents the original intention of the message.
- New condition record created/record changed
- Message 108 could be an indicator that no condition record existed for this condition at the time of the original pricing and a record has been created meanwhile. This also applies to changed condition records with regarding to their validity periods.
- Requirement was not fulfilled
- A requirement set for this condition in pricing procedure or in access sequence was not fulfilled during initial pricing and now it’s fulfilled.
- Pricing determination key fields with initial value
- A field used in one of the accesses was initial during original pricing or had a different value. It might in most cases be a userexit problem.
- Pricing date issue
- The pricing date was not correct during original pricing determination (maybe due to customer modification).
- Inconsistency detected during pricing determination
- A condition record was found during original pricing but no line in table XKOMV was created due to detected inconsistency (e.g. calculation type is D Gross weight, but no weight unit of measure available in KOMP).
FORM XKOMV_FUELLEN
Include LV61AA55
FORM XKOMV_BEWERTEN
Include LV61AA52
FORM XKOMV_FUELLEN
New fields in selection screen (Texts) 31.08.2021
Copy fixed conditions without recalculation ( 10.09.2021 )
834174 - How are 'value-related' condition bases determined?
This consulting note describes how the condition basis (field XKOMV-KAWRT) of conditions is determined with calculation type "Fixed amount" (KRECH 'B') or 'Percentage' (KRECH 'A', 'H' or 'I').The condition basis for these calculation rules is formed from one or more condition values in the document currency, making it a 'value-related' condition basis (in EUR, USD, and so on) - in contrast to quantity-related, weight-related, or volume-related condition bases (such as PC, KG, M3, and so on)
The determination of the condition basis depends on the settings in the pricing procedure that is used.
In all cases, it should be noted that the conditions and subtotal lines are edited successively from top to bottom in the sequence in which they are specified in the pricing procedure.
If no from-to reference steps are maintained in the pricing procedure (fields STUNB and STUN2), the condition basis is filled from the current value in the internal variable ZWISU. In the variable ZWISU, the condition values of the (current) last pricing condition (condition with condition class KOAID = 'B' and inactivity indicator KINAK not set to 'Y') as well as the subsequent conditions (for example, surcharges and discounts, taxes, and so on) are added together, as long as they were not deactivated with one of the 'AKLMXZ' indicators (see Note 836243).
Due to the successive processing of the conditions in the pricing procedure, ZWISU therefore generally increases step by step with every (active) positive condition, reduces with every (active) negative condition, and is reset with the occurrence of a new (active) pricing condition and filled with its value.
2. One or more reference steps are maintained:
Only step numbers that are smaller than the current reference step can be chosen as reference steps. This is because the condition values of following step numbers have not yet been determined due to the successive processing of the pricing procedure (see above).
If only the from-reference step is maintained, the system internally fills the to-reference step with the from-reference step. In this case therefore only this one reference step is relevant.
If both the from-reference step and the to-reference step (greater or equal to the from-reference step) are maintained, all step numbers are relevant, that are greater than or equal to the from-reference step and smaller than or equal to the to-reference step.
To determine the condition basis, the system now adds the condition values of all relevant conditions that are not inactive with an 'AKLMX' indicator (see Note 836243).
It should be noted that in this case pricing conditions with the inactivity indicator 'Y' are taken into account during the determination of the condition basis, as long as their step number is in the relevant area.
In addition, the system also takes subtotals into account, as long as their step number is in the relevant area.
3. Using a condition basis formula
You can also use a condition basis formula to fill the condition basis. In this case, you must enter the number of the relevant formula in the pricing procedure in the 'BasFrm' column (field KOFRA). The use of a condition basis formula is more binding than the possible maintenance of reference steps. Therefore, the system rejects a condition basis that is first determined according to section 1 or 2 if the formula determines a different condition basis.
For example, the standard condition basis formula 002 fills the condition basis from the current accrued net value of the item (KOMP-NETWR). Here, the net value is the total of the active non-statistical conditions (KINAK not set to 'AKLMXZ' and not set to 'Y', as well as KSTAT not set to 'X').
Due to the successive processing of the conditions in the pricing procedure, the net value generally increases step by step with every (active) surcharge, is reduced with every (active) discount, and is reset with the appearance of a new non-statistical (active) pricing condition and filled with its value.
4. Tax conditions
For (percentage) tax conditions (condition class KOAID = 'D'), we generally recommend the condition basis formula 016.
In the case of intercompany billing or rebate settlement documents, the system always determines the condition basis with the condition basis formula 002, even if it is not explicitly maintained in the pricing procedure.
However, this does not apply if a different condition basis formula is maintained in the pricing procedure. In this case, the condition basis formula entered in the pricing procedure is used.
Comments
Post a Comment