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 )
When adding new objects with VOFM include the line into TR with R3TR XPRA RV80HGEN.
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.Pricing Predefined Price Elements.
Price Agreements
Using price agreements, create contract-specific and item-specific prices.
Not only are values entered in the header or item Conditions screen, but in this
case new condition records are created in the background, that have in their keys,
the document number that they were created, and which take effect immediately.
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.
The corresponding settings are available as well using the menu path IMG
Controlling Profitability Analysis Flow of Actual Values Transfer of
Billing Documents Assign Value Fields and IMG Controlling Profitability Analysis Flow of Actual Values Transfer of Billing Documents
Assign Value Fields.
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
The reference attribute field From allows you to define an alternative base for calculating the condition value. By entering a From-To range, define subtotals like Discount Amount. The values of the condition lines contained in the From-To range are then automatically summarized and assigned to the respective line in the pricing procedure.
Manual Indicator
Conditions with the Manual attribute in the pricing procedure are only included in price determination if they are entered manually during document creation or if they are transferred from an external process, such as costing.
Print Indicator for Condition Lines
The Print Indicator field controls the issuing of condition lines when printing
documents such as order confirmations or invoices. There are two sets of logic
that can be used: The original logic—which is still today applied in most cases—
uses only three values:
_ (blank): Condition line is not printed
X: Condition line is printed at item level
S: Condition line is printed in totals block.
And also for IDoc outbound.
Subtotal
The Subtotal field controls whether and in which fields condition amounts or subtotals (for example, a customer discount or the cost of a material) are stored.
Condition Formula for Alternative Value Calculation
The CalType attribute field offers the possibility of entering an alternative formula to determine the value of the current condition line of the pricing procedure.
Condition Formula for Basis
The BasType attribute field offers the possibility of entering a formula to determine the condition basis as an alternative to the standard. Only Sales document.
Account Key
The AccKey attribute field enables the system to post amounts to certain types of
revenue accounts. For example, the system can post freight charges (generated by
the freight pricing condition) to the relevant freight revenue account.
Account Key for Accruals
The Accruals attribute field enables the system to post amounts to certain types
of accrual accounts. For example, rebate accruals that are calculated from pricing
conditions can be posted to the corresponding account for rebate accruals.
Statistical and Relevant for Account Determination
Defines whether a statistical price condition is relevant for account determination.
In the pricing procedure, the following settings for the price condition have been made:
- 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.
Note: The Accruals key is not taken into account.
You use this indicator to define that the statistical price condition is posted to account-based Profitability Analysis (CO-PA) as journal entry to an extension ledger of Financial Accounting.
Currency Conversion
In sales orders and billing documents, we are dealing with conversions using
three currency fields (and the associated exchange rates):
- 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.
The exchange rates are always related to a conversion date.
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
Indicates where the condition originated (for example, whether you entered the condition manually or whether the system determined it automatically).
- 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
When a delivering plant invoices a sales organization, the plant can use one of the following condition types:
- PI01 Intercompany: fixed amount per material unit
- PI02 Intercompany: percentage of the net invoice amount
These condition types specify that the price charged by the delivering plant to the sales organization is shown as a statistical value in the sales order and an effective charge in the internal invoice.
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.Working with sale promotion and SD budgets can be split up into three stages:
- 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)
The manually entered order value is distributed proportionally among the
items. Since the condition type is configured as a price, all previously determined conditions types are inactive because of a subsequent price (inactivity
indicator = Y).
This configuration has the disadvantage that a differentiated account assignment
for revenues and sales deductions is not possible. For this reason, the following
approach inspired by the AMIW/AMIZ process (minimum sales order value) provides a reasonable alternative.
Condition Types SKTV/SKTO (Cash Discount))
The statistical condition types SKTV/SKTO (cash discount) are configured as Condition category = E. They are not determined by condition records, but the percentage is read via table T052 (terms of payment) instead. The difference between
both condition types is that they either affect the tax base (SKTV) or they don’t
(SKTO).
- 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)
The condition types RL00/MW15 (invoice list conditions), flagged as statistical in
sales orders and customer invoices, are used to handle del credere commissions.
These are used, for example, if within the sale to members of purchasing associations, the payment of invoices is done by a central payer.
Since the payments are facilitated by this type of organization, a discount can be
granted to the central payer in the form of condition type RL00. As this is a kind
of service provided by the central payer, the condition type MW15 is used to calculate the tax on this commission, which is configured by a special access
sequence so that the full tax rate is always applied.
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
In Customizing for condition types , the attribute
Condition Update is available in the field group Master Data. This indicator can
be set only if the condition type has assigned an access sequence, which means
that condition records can be created for this condition type. Condition Update
consists of the following functionality:
- 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)
For rental and maintenance contracts, normally periodic billing, implemented by
a billing plan, is used. At the item level, a detailed billing plan with multiple billing dates can be stored in the sales document instead of a single billing date
Pricing in Fixed Price Contracts (Milestone Billing)
In fixed-price contracts, which are used, for example, in plant construction, milestone billing is used, in which the total to be invoiced is divided according to certain rules on the individual dates of the billing plan. An example from the standard
SAP system is the item category TAO (Milestone billing).
Pricing in Resource-Related Billing
Since with service contracts not all services are generally covered by the contract,
an executed service order is billed using resource-related billing.
If a service order is created with reference to a service contract, the system calculates the price for the billing request (Transaction DP90) using the price agreements in the underlying service contract.
The pricing procedure PSER02 (resource related billing) is used in the standard
SAP system for this process
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
Unit costing is performed in the production order and the network. If you use the static assemble-to-order procedure, the unit cost estimate can be copied into the sales order item.
There are two condition types in the standard pricing procedure which can be used to record the cost estimate in the sales order item. In Customizing for the sales order type, you define which of these condition types is to be used. The condition types are designed to be used as follows:
- 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
Determining the cost of a sale is very important. In the sales order or the quotation, we strive to obtain a precise idea of the actual costs that are inherently
known only at a later date. Finally, we want to know what financial latitude we
have in negotiating an offer, because we do not want to operate at a loss. At this
stage, we speak of planned costs.
At the time of billing creation, we want to determine the actual costs. This is
important, because in most processes the billing transmits this cost information
to Profitability Analysis (CO-PA) to run the cost-of-sales accounting method. In
this method, the revenues are compared to the actual costs.
Costs are handled in the pricing procedure by special statistical condition types,
which vary depending on the process. It is worthwhile to read a brief overview of
the various processes and their treatment of the costs:
- 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.
The condition type VPRS goes into the valuation segment in the material master and determines from this the standard price or average price.
For a third-party business transaction, the costs are determined from the purchase order.
Selling services
When selling materials or services to end customers, in some countries or regions, the selling price must include taxes. The standard system contains the predefined pricing procedure Standard - Gross Prices, which you can use as a reference for this kind of sales process.
Variant Conditions
Use variant conditions in Sales and Distribution and Purchasing to define surcharges and discounts for the basic price. Variant conditions consist of a variant key and an amount that is identified by the variant key.
Minimum Order Value
Use condition types:
- 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)
The condition type AZWR (down payment/settlement) is used in processing the
down payment.
The condition class of AZWR is modified
during billing by the function module PRICING_COPY from discount/surcharge to
price, so that all preceding condition types are thereby deactivated. In partial billings and in the final invoice, the condition type is used in separate items to settle
the advance payments.
Condition Type GRWR (Statistical Value (Cross-Border))
The statistical condition type GRWR calculates the statistical cross-border value.
This value is used in export transactions to create the necessary export documents
and provide the necessary information to the authorities. The condition type is
configured with Subtotal = C, whereby the value of the condition is passed to
the komp-gkwrt field. Requirement 008 (export business) ensures that the condition type is determined only in export operations.
Sales Order Costing in Pricing
Use sales order costing to determine the manufacturing costs and total production costs of a material managed as sales stock. Sales order costing can be carried out using the following methods:
- 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
In the standard system, you can use condition type DUPL, which is copied during pricing to all of the sub-items assigned to the item. For this reason, it only makes sense to use duplicated conditions for bills of materials and configurable materials.
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.When you copy a sales document to a billing document, the condition rate and the condition value of a cumulative condition is “frozen”. This means that the condition is not redetermined when it is copied regardless of the pricing type. The net value of the total is not redetermined even if the individual net values have changed.
Switch on debugger and click on ‘Activate’ button, set breakpoint at function module pricing_complete.
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.
Group Conditions
If you want the system to carry out cumulation across all items, but to read a separate condition record with this cumulated quantity for each item, you must make the following additional entries for the condition type:
- Quantity unit for cumulation
- Group key number
Prerequisites will be the following:
- 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.
Header conditions are condition types without an access sequence that are entered
manually in the Header Conditions screen of the sales order. Header conditions
with the calculation type Fixed Amount are distributed to the individual order
items according to a freely definable distribution key. A rounding difference comparison is carried out and a potential rounding difference is then added to the
item with the largest value.
Header conditions with the calculation type Percentage are also distributed to the
items.
For a condition record with scales, the scale base is determined over all items in
which the condition record was found. In this case, no group key routine is used.
If a group key routine is used for a condition record with scales, the accumulation
of the scale base is performed on a level different from the level given by the key
of the condition record itself. The accumulation level is determined by the group
key routine. In the case of quantity scales, you must always specify the attribute
Unit of measure in the configuration of the condition type (in the field group
Scales). All item quantities must then be convertible into this unit. For example,
you can accumulate the scale base for the following:
All items in the sales document that have the same condition as the group condition currently being processed (group key routine 001, total document).
All items in the sales document independent of which condition types have
been found (group key routine 002, across all condition types).
All items in the sales document that have the same material pricing group
(group key routine 003, mat. pricing group).
The cross-item activities presented here are performed in the function module
PRICING_COMPLETE.
| 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. |
If you want to calculate the scale base value as a total quantity of all items in the document, regardless of whether or not the individual items have the group condition, you should work around the problem as follows:
- 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.
If we need to set the condition by the formula, but at the header level. Then, ensure Group attributes are set for the condition type and add CHECK komp-kposn IS INITIAL. that is moment GKOMV_BEWERTEN
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.
After execution of the above form routine, header condition HB00 is available in item conditions in xkomv.
Then go to part 2: build up group tables.
Build GKOMV per item
Check group condition indicator (kgrpe) setting, then fill data into GKOMV_KEY, GKOMV.
If a group condition routine is assigned, it will be executed here.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.
Now it comes to Part 3: Calculation on header level based on groups
Calculate group condition value at header level in GKOMV-KWERT.gkomv_bewerten.
Part 4: Distribute to the items
- 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
In pricing for sales and billing documents, more than one condition record may apply to a particular item at any one time. You can use the condition exclusion process to compare possible conditions in order to determine such things as the best price for a customer.
How to use?
#Simple Condition Exclusion Using Requirements
- 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).
#Condition Exclusion Using Exclusion Groups
#Condition Exclusion Using Formulas
- Using the value formula xkomv-kinak = 'X'.
Conditions can be linked to requirements in the Pricing Procedure. A requirement can evaluate the condition exclusion indicator and ignore the condition if set. The condition exclusion indicator can be set in either the condition type or the condition record. If we want to use an exclusion indicator to prevent the system determining condition records for a condition type during pricing, then in the pricing procedure, you must assign a requirement to this condition type that carries out a query for indicator KOMP-KZNEP.
Condition records that the system ignores are not deleted from the sales order but are simply deactivated. You can still see the excluded condition records on the pricing screen in the sales order.
No exclusion at the header level.
Procedure:
- 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 fact that a condition was excluded can be recognized by the following:
- 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.
Debug:
- 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.
T-codes:
- 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.
The standard version of the SAP System includes four standard partner functions for this purpose: 1A - 1D. You can add as many additional partner functions as you require, up to a maximum of 26 levels.
In the access sequnce we can set several tables with different field assignment for hierarchy levels.
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
Using the access sequence we can link:
- 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)
Question: Why are service conditions for a service master record not transferred to the service specifications of a contract?
Answer: Service conditions that were created for a service master record are not transferred correctly to a contract (or rather, converted, since master conditions exist in contracts). Conditions within contracts are the result of negotiation with the vendor. They must therefore be specified for each contract individually and are not determined using the service master.
Question: The gross price is changed for a service. Why are the supplementary conditions in the contract then provided with a deletion indicator?
Answer: Negotiated conditions in a contract are retained for a longer time period, so it must be assumed that if the price changes, the conditions are renegotiated. Therefore, the system behavior is correct.
Question: When you change prices in the service specifications of a quotation, the original price is still displayed in the overview of the conditions. However, the price in the purchase order item overview changes.
Answer: The master condition PB00 of the item is not updated for service items in quotations, since only the price from the purchase order overview is important in this case. For service items, only the field EKPO-NETPR is updated.
Question: Master conditions are selected for a model service specification. Why does the system not take into account the subsequent setting of a deletion indicator in the master condition in the model service specifications?
Answer: The system design does not currently allow for an update of the service in the model service specifications.
If you create master conditions (that is, service conditions) and you select these master conditions in a model service specification, these are then document conditions in the model service specification, and they are not updated when the master conditions change. Therefore, if you access the model service specification in a purchase order, then you access the document conditions of the model service specification during the service selection.
Question: In a purchase requisition (PR), you maintain services for which service conditions are maintained. You change the price in the PR manually. When you create a purchase order (PO), the system uses the price from the condition, not the manually changed price from the PR.
Answer: The system uses the net price from the service master in a PO. The field selection in transaction OIOE causes the net price to be transferred from the PR to the PO. This price is transferred if the system cannot find any conditions. If conditions exist in the service master, for example, these are transferred. This means that a price that differs from the service master must also be changed in the PO.
Question: How can you distribute the service conditions together with the services to the subsystems using ALE master data distribution?
Answer: The service conditions can be distributed using the transport function from purchasing. A separate distribution takes place. (Master data -> service conditions).
The distribution is carried out by:
a) sending immediately (initial download)
b) a change pointer (only the changed records are sent).
Refer also to the general ALE documentation.
Question: When you create a purchase order or an activity (network, maintenance order), services are selected from a contract and the prices are also transferred. If you switch to the conditions and carry out repricing, the prices are deleted again.
Answer: No master conditions are stored for the selected services. No real reference is created between these two documents as a result of the service selection from a reference document (such as a contract). It is not a contract release order.
The service selection should only be regarded as an input aid. Therefore, during a new price determination, the system searches only for master data for the services, but not for the conditions from the contract that was used as a reference. The system handles the service line as if it had been entered manually. Therefore, if no master data is stored, the price disappears during a new price determination.
In the purchase order, you can create the purchase order with reference to the contract. In this case, it is a contract release order. The data is written back to the contract, and during a new price determination, the system first searches for conditions from the contract.
This option does not exist for networks and plant maintenance (PM) orders. In those cases, the system always only searches for master data for the services.
Question: Why are prices not found and entered prices not retained? (Message SE 377 or SE 316)
Answer: See SAP Note 25357.
Question: When you create a contract, why does the system issue an error message informing you that the condition table is not found or the condition category is incorrect?
Answer: See SAP Note 25357.
Question: Header conditions in external services documents refer only to the total service value. Can these be displayed for each individual service line?
Answer: As of Release 4.5A, you can maintain header conditions at outline level within the service package for each outline level. For further information, see SAP Note 353482.
Question: Why are specific condition types such as discounts, which are maintained in quotations and global percentage bids for service items, not transferred to contracts?
Answer: Any condition types which do not have a condition category maintained are not transferred. This ensures that the price is transferred.
The reason for this is that, at the latest, if conditions are maintained within the service schema, the conditions at item level must be deleted since these are master conditions. In addition, when you manually create a contract, you are not allowed to maintain conditions for service items. Therefore, it would be inconsistent to transfer these via the request for quotation (or purchase requisition).
Question: Why do pricing errors occur for follow-on documents for a contract?
Answer: Check the service conditions in the contract. Here, you can maintain surcharges or discounts (PRS0, PRS1, PRS2 or PRS3) and the gross price (PRS). The condition PRS can be deleted here, however, and the contract is then saved with PRS0, PRS1, PRS2, and PRS3 only. Therefore, note that the condition PRS should not be deleted from contracts.
Question: When you call the conditions for a service in the service overview, the system issues error message VK233:
"Program error: Condition table or condition type does not exist".
If you branch to the outline overview and choose "Conditions" for an outline level, nothing is displayed.
Answer: The fact that no header conditions are displayed at outline level is due to the settings in Customizing for the conditions. Compare the settings with client 000 and copy them if necessary. Condition types KR01 (header discount) and KZ01 (header surcharge) must be maintained. Schema MS0002 (supplementary conditions header) must also exist.
Question: Why are the service conditions for the vendor not taken into account during the source determination?
Answer: There are no info records for services. Instead, conditions can be used if the "Condition index" indicator is selected.
Procedure:
For the condition type PRS, set the "Condition index" indicator in Customizing for the service:
Materials Management -> Service -> Maintain Conditions for Services -> Conditions: Condition Types -> Details for PRS.
Question: With transaction MEDL, you can change prices for the condition type PRS only. For other condition types, the system issues error message 06 615
"No selection possible".
Answer: In the subroutine Konditionen_selektieren_srv, the condition type is selected from the table A081. However, this table contains only the total price PRS. Supplementary conditions are not taken into account for services. Make changes only to the total price.
Question:The net price is calculated incorrectly for service items. What should I do?
Answer: See also SAP Note 196798 for more information.
Question: How can you prevent rounding of the gross price?
Answer See also SAP Note 131080 for more information.
Question: A service quantity of less than 1 is entered in a quotation. When you call the price simulation, why is this quantity rounded up to 1 when it is displayed?
Answer: See also SAP Note 576025 for more information.
Question:In a purchase order, the net price in the item overview is increased by a certain amount every time you press ENTER. How can you avoid this?
Answer: See also SAP Note 598297 for more information.
Question: For which documents can you maintain the group condition at outline level?
Answer: You can do this only for quotations, purchase requisitions, purchase orders, and contracts. You cannot maintain the group condition at outline level in requests for quotation or service entry sheets.
Question:A service specification has multiple outline levels. The same master service exists at various outline levels. Why is the condition from the higher outline level always transferred, regardless of the outline level from which the service line is selected?
Answer:The program assumes that the same service master in a document does not exist with different conditions. The programs only take into account the first service found when selecting from the service specifications. The service specifications are searched from top to bottom. If a condition record exists, it is transferred by the system. This means that the system transfers the header condition of the level where the service is first found.
Question:Why does the system calculate the net price incorrectly and issue error message SE181 when conditions (POCOND / POCONDX) are used in the purchase order APIs (BAPI_PO_CREATE1 / BAPI_PO_CHANGE)?
Answer: For purchase orders for external services, conditions are maintained at service level. The item condition is a summary of all service lines. Since the purchase order APIs for purchase orders for external services do not expect any POCOND or POCONDX values and the ERP system has its own pricing, this leads to an incorrect calculation of the values.
Pricing in procurement
456691 - FAQ: Price determination in purchasing
Question: What is the difference between master conditions (time-dependent conditions) and document conditions?
Answer: The conditions in the info record and in the contract are master conditions.
The differentiation for quotations and scheduling agreements is made through the document type (indicator "Time-dep. conditions"). The master conditions are restricted to a specific validity period, they have the characteristics of master data, and they are usually valid over a long period of time.
Master conditions that refer to more general price agreements, such as the vendor or the material type, can also be mapped (general conditions, transactions MEK*).
Generally, the conditions in the POs are document conditions. They are only valid for this document. The document conditions may also be available for quotations and scheduling agreements if you have configured this in Customizing.
Question: How does the price determination determine the conditions using the last purchase order?
Answer: If the info record does not contain any valid conditions, but a "last document" exists for the info record, the system copies all of the conditions from this document if the following prerequisites are met:
- 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).
Question: Why does the system not carry out price determination when a scheduling agreement is created?
Answer: Check Customizing for the document type of the scheduling agreement (transaction OMED). When a scheduling agreement is created, the system carries out price determination only if the "Time-dependent conditions" indicator is deactivated.
Question: Rounding errors occur during a price determination process that takes into account the conditions in the info record.
Answer: Check the standard quantity and the price unit in the info record.
When you do this, take into account SAP Notes 30658 and 39963). To avoid rounding errors, choose a standard quantity that is at least as high as the price unit.
Question: Why does the system not use a condition type when a purchasing document is created?
Answer: On the condition screen, go to the condition analysis (choose the "Analysis" pushbutton). The condition screen displays all conditions for the calculation schema. Double-click the condition type (or the access) to open the detail screen on the right-hand side. Navigate to the technical view ("View" pushbutton) for information about the field contents that were used for accessing the condition table, and which fields have not been filled for accessing the table.
Question: Why does the system not transfer the conditions from the contract to the scheduling agreement when a scheduling agreement with reference to a contract is created?
Answer: See SAP Note 160630.
Question: Why does the system not find any prices when I post a goods receipt (GR) for a scheduling agreement or during the price simulation for a scheduling agreement (the scheduling agreement has been created with reference to a contract)?
Answer: See SAP Note 431460.
Question: How can I maintain conditions for a material group item in the contract?
Answer: Conditions for material group items in the contract are not permitted. (see SAP Notes 62729 and 105899).
Question: A plant-dependent info record and a plant-independent info record exist. The deletion indicator (EINE-LOEKZ) is set for both info records. However, the system uses the price of the plant-independent info record when I create a purchase order (PO). Why is this the case?
Answer:The relevant condition tables are read by an external SD module. The information about the deletion indicator for the info record is therefore not available in this place.
You can only configure that the conditions of the plant-INdependent info record are read if the plant-dependent info record has been deleted. To control this, use a relevant transfer parameter (komp-no017, set in the function module ME_FILL_KOMP_PO).
If both info records have been deleted, you can change the validity period of the conditions to a date in the past, or you can archive the info record.
Question: Why is the "Refresh" (Refresh prices) pushbutton inactive on the header conditions screen in a PO?
Answer: At header level, this pushbutton does not have a function. The pushbutton does not trigger a new price determination process for all items in a document. This can be executed only for one item at a time. The pushbutton is therefore not active at header level. (This is the standard system design.)
You can use transaction MEI2 for the mass adjustment of documents due to changes in conditions. Take into account the functional restrictions as described in the online documentation or in SAP Note 457511 "FAQ: Purchase order change and goods receipt in purchasing".
Question: Why does the system not determine the conditions automatically when I maintain a quotation (transaction ME47)?
Answer: The price determination is not carried out when quotations are maintained. You must maintain the conditions manually.
Question: Why does the system not transfer the price from the purchase requisition to the PO?
Answer: See SAP Note 393367.
Question: Transaction ME22N: Why does the system not convert the price of the PO into the new currency when the vendor is changed (different currency)?
Answer: See SAP Note 445509.
Question:When I change data, such as the material group or the account assignment category, in a PO item, the new EnjoySAP transaction (ME21N/ME22N) automatically carries out a new price determination process. This is not the case in the old transaction ME21/ME22.
Answer: This is not an error. The new EnjoySAP transaction has been designed to include this function as well as several other additional functions regarding price determination.
Question: Why does the system adjust the absolute conditions of a purchasing document to the goods receipt (GR) quantity, or proportionally calculates them, when I post a GR?
Answer: See SAP Note 304178.
Question: How does a new price determination process affect the values that were posted during the GR when a GR is canceled?
Answer: See SAP Note 508009.
Question: In what circumstances does the system update the header conditions when a PO item is deleted?
Answer: When a PO item is deleted, the system marks this item as "statistical" (field EKPO-STAPO = X) and the header conditions reflect these changes.
However, if the final invoice indicator (EKPO-EREKZ) or the "Delivery Completed" indicator (EKPO-ELIKZ) is set for this item, the system does not mark the item as "statistical" (EKPO-STAPO is not set) and the system therefore does not update the header conditions.
Question: When I display or change a purchasing document (scheduling agreement/contract), a runtime error occurs because the price (net price or effective price) is negative. How can I correct this problem?
Answer: To determine the condition that causes the negative price, proceed as follows:
Scheduling agreement: Use transaction ME3N to display the document. Choose the item and follow the menu path "Edit -> Price Simulation" to navigate to the price simulation.
Contract: Use transaction MEKA to display the conditions for the contract. You can change these conditions directly in this transaction.
Question:When I change or display a PO, why does the system display other or additional conditions that were not displayed when I created the document?
Why does the system suddenly display the gross price (PB00) in addition to the manual gross price (PBXX), or vice versa?
Answer: These problems indicate that the calculation schema was changed after you created the PO. You must avoid this.
Question: Why does the price determination not determine a price even though the master conditions (info record, contract, scheduling agreement) contain valid prices (with scales)?
Answer: Check whether a scale exists for the quantity the price determination is based on. We recommend that you set the quantity of the first scale to the smallest order quantity to avoid these problems.
Question: Conditions that are valid at the time are maintained in a contract or in a scheduling agreement (that has time-dependent conditions). Why does the item overview display an obsolete price?
Answer: When you maintain condition validity periods, the system uses the price of the period that is currently valid for the item (field EKPO-NETPR) However, when a validity period expires, the system does not automatically update the net price of the item. You can use the report RM06ENP0 (for contracts) or RM06ENP1 (for scheduling agreements) to update it afterwards.
When you create a PO with reference to such a document, the obsolete price does not affect this process because the system always uses the current price from the conditions without taking into account the price of the item (EKPO-NETPR).
Question: A PO item contains a manual gross price (PBXX in the standard system). I use transaction ME21N or ME22N to change fundamental data, such as the plant.
Under what circumstances does the system retain the price (the conditions), and when does it delete it (the system issues message 06 218 "Net price must be greater than 0")?
Answer: When you change fundamental data, the system triggers a new price determination process. If the price determination does not find a price, the system checks whether the price that previously existed was a "manual price".
(A price is a manual price if the net price equals the gross price (PBXX); that is, if no further conditions were included in the net price. In this case, the "Net price" field on the item overview is ready for input.)
If this is the case, the system uses the price that previously existed. You therefore get the impression that the system did not change the price when you made changes to the item.
In the alternative scenario (the net price does not equal the gross price; the "Net price" field on the item overview is not ready for input), the system cannot transfer the price that existed previously (the conditions). You must maintain the price again; the system issues error 06 218 "Net price must be greater than 0".
Question: Why does the system not use the better price, which results from the scales, for a PO (several items for the same material, scales are maintained in the master conditions)?
Answer: The system does not group together the PO quantities of the items so that the scales are taken into account until the document is saved or checked.
Question: I create a PO with reference to a quotation with document conditions. The quotation contains further conditions, such as discounts or surcharges, in addition to the gross price (PBXX in the standard system).
When a price determination of the type "C" ("Copy manual pricing elements and redetermine the others") is carried out for the PO item (either manually, or triggered by the system when, for example, the account assignment category is changed), the system doubles several conditions. Why is this the case?
Answer: When you use a reference to a quotation, the system copies the conditions from the quotation. If the price determination of the type "C" is carried out afterwards, the conditions that were maintained manually (from the quotation, as PBXX) are retained, and the gross price from the master conditions (for example, info record) is included. However, this gross price is set to "inactive". This is displayed on the detail screen for the condition.
Question: I post a GR for a PO item with pricing date category "5" (new price determination at GR). Why does this price determination determine a condition twice?
Answer: You have manually changed or manually maintained this condition in the PO. In addition, this condition is maintained in the master conditions (for example, info record).
The price determination of the type "C" is carried out during the GR. As a result, the system retains the condition, which you manually changed or maintained, from the document, and also determines it from the master conditions.
To correct this problem, make the following setting for the condition in Customizing (transaction M/06):
Manual entries: C ‘Manual entry has priority’
If the price determination of the type "C" during the GR now determines an existing condition from the master conditions, the system sets this condition to "inactive" because the manual condition from the document has priority (this is displayed on the detail screen for the condition).
Read SAP Note 548900 for more information.
Question: I post a GR for a PO item with pricing date category "5" (new price determination at GR). The system issues error message ME 573 "Transaction cannot be posted due to errors in price determination".
Answer: The price determination may use condition records that did not yet exist when the document item was created; for example, an additional discount at vendor level. The net price may have a negative value or a value of 0 due to these conditions, which are determined additionally.
To establish which conditions cause the incorrect price, it may be helpful to create an identical PO item that has identical data. On the condition screen, navigate to the analysis. In the analysis, you can establish which condition record causes the incorrect result.
Question: When is the net price in the item overview for a PO ready for input, and when is the net price not ready for input?
Answer: The net price is not ready for input (you can change the price on the condition screen only) in the following scenarios:
The document currency differs from the condition currency of the price.
The system includes further conditions in addition to the basic price PB00 when the gross value is calculated (for example, variants).
The net value differs from gross value.
Question: When is the condition value for the condition of a returns item negative, and when is it not negative?
Answer: A negative plus/minus sign is assigned to the condition value for the condition of a returns item if the following settings are made in Customizing for the condition type:
- The condition category is not set to "B" (Delivery costs).
- The "Accruals" indicator is not set.
- The "Statistical" indicator is not set in the calculation schema for the condition.
'Statistical' is set.
A negative plus/minus sign is assigned to the condition value for a condition that has the category "B" ("Delivery costs") only if the calculation type for the condition is set to "A" ("Percentage").
(See LV61AA43, FORM xkomv_kwert_ermitteln.)
Question: How are the prices determined in the info record or in the contract if fixed conditions (calculation rule "B", fixed amount) are included in the net price?
Answer: See SAP Note 586856.
Question: If I use the user exit EXIT_SAPLMEKO_002, price determination in transaction ME21N differs from price determination in transactions ME21 and ME59.
Answer: A frequent cause for the different behavior of the price determination in transaction ME21/ME59 when you use the user exit EXIT_SAPLMEKO_002 is that the user exit uses the fields EKPO-BANFN/EKPO-BNFPO. The system fills these two fields only if transaction ME21N is used. In transactions ME21 and ME59, these fields are initial; however, the document number and the item number for the purchase requisition are contained in the table EKET.
The system behavior differs because the features of the EnjoySAP purchase order transaction have been enhanced. This is not an error in the R/3 standard system.
If you want these transactions to behave in the same way, extend the interface of the user exit EXIT_SAPLMEKO_002 and the interface of the function module ME_FILL_KOMP_PO accordingly.
Question: I copy a PO item ((ME21/ME22 or ME21N/ME22N). The reference item contains taxes. Why does the system copy the corresponding condition, but it does not copy the condition amount and the condition value?
Answer: The system does not copy the amount and the value to the new PO item. The system determines the amount and the value when a PRICING_COMPLETE is executed. This is executed when the document is checked or posted, and when you navigate to the header conditions.
Question: When I post a GR for a scheduling agreement with pricing date category "5" (new price determination at GR), the system may determine a price that has a value of zero; this price is also displayed in the PO history (and in the goods receipt/invoice receipt (GR/IR) clearing account). Why does this happen?
Answer: See SAP Note 683646.
Question: Can I change conditions after the GR/IR has taken place? Is it still possible to carry out a new price determination process at this stage?
Answer: You can no longer change the delivery costs after the GR has been posted.
If you have implemented SAP Note 549408, you cannot change conditions that have the category ‘B’ (Delivery costs) after an invoice has been posted or parked either.
If you change data in the PO and this data usually triggers a new price determination process of the type "B" or "C", the system does not execute this automatic price determination if a GR or an IR has already been posted.
See SAP Note 457511, question 3.
Question: I want to use the report RM06ENP0 to update the net price in the contract. The document contains valid conditions. Why does the report not determine the net price?
Answer: The system uses the release quantity to determine the net price. If the release quantity is smaller than the price unit, the net price may be rounded to zero if the gross price is low.
The release quantity should always be the same as the price unit or higher than the price unit.
Question: In a scheduling agreement that has time-dependent conditions, I maintain a condition that has scales. The system always uses the first scale level to calculate the net price. Is this the intended system behavior?
Answer: You cannot compare the price determination in the scheduling agreement to the PO, if the scheduling agreement is a document that has time-dependent conditions (master conditions). The system always uses the first scale level when the price is displayed in the scheduling agreement.
For further information about the GR for scheduling agreements with scales, read Note 401941.
Question: I maintain supplementary conditions in a quotation; for example, discounts (condition type RA01). Why does the system ignore these conditions when I compare quotations (transaction ME49)?
Answer: This problem occurs if you use a supplementary calculation schema (RM0002 in the standard system), which contains conditions that are not included in the calculation schema for the document (RM0000 in the standard system). All of the condition types that are used in a supplementary calculation schema must be specified in the calculation schema for the document.
Question: Can I use net prices that have more than 11 digits (including decimal places)?
Answer:
The field for the net price can be filled only with 11 characters (including 2 decimal places). A larger value usually leads to an overflow error ('price overflow error'). You can avoid this error by i) reducing the related quantity, ii) splitting the material item into several items, or iii) changing the price unit of measure accordingly.
The same applies for effective prices, which cannot exceed 13 digits (including 2 decimal places).
If you have further questions about this, we recommend that you open a customer message and forward it to SAP Development Support.
See also SAP Note 584997.
Question: How can I prohibit changing the amounts on the condition screen in the conditions PB00 or PBXX using transaction ME22N?
Answer:
Use the user exit USEREXIT_FIELD_MODIFICATION, and use transaction SE38 to insert the source code in the include LV69AFZZ to prevent the changes.
Question: When can a calculation schema be changed?
Answer: Changes to the calculation schema are strictly forbidden as soon as documents exist in the system that use the schema concerned.
If you require changes to a calculation schema, you must ensure that no documents exist for the schema concerned.
If documents already exist, you can only create a new schema and then make your changes in it before the first document has been created.
Question:PBXX with error message VE 207 is taken into account for purchase order price condition.
You create a purchase order with contract reference for an item. On the Purchase Order Item Conditions screen, the contract price is displayed in the PB00 condition as intended. However, the system displays a red light for the condition PBXX. When you check the price analysis screen, you notice that the error message " Condition has been found (without condition record)" is present for PBXX. You can save the purchase order with the error in PBXX. You use the standard calculation schemas RM0002 for the contract and RM0000 for the purchase order.
Answer: In order to avoid error VE 207 for the unwanted price condition PBXX in your purchase order, you need to change the price condition settings in your Customizing and set the exclusion indicator. In transaction M/06, select the pricing condition PB00 and set the exclusion indicator on the "Control Data 2" tab page.
Condition Interchange
IDOC_A with the structure of an IDoc
- 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.
Customer-specific conditions (KZWI3)
To ensure that key figures 3 (customer-specific conditions) and 4 (conditions which a sales employee has entered manually in the document) can be kept apart, all automatic condition types have to be set to “Cannot Be Changed Manually”.Manual conditions (KZWI4)
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.
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.
Net value (NETWR)
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).
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
1. How is the cost determined in pricing?
In the order, the cost is generally taken from the valuation segment of the material master.
In the billing document, however, it can have other sources. Depending on the business transaction, the costs can be taken from the goods issue of the invoiced delivery or, in the case of third-party order processing or individual purchase order, the relevant purchase order, the goods receipt, or the invoice verification in purchasing.
In the following, only the goods issue case is used, as an example.
Still, the information also applies to costs from purchase orders, goods receipts, and invoice verification runs. For details, refer to the SAP Notes 372760 and 547590. These costs are passed to pricing externally and included in the value of the condition VPRS.
You then obtain the amount by through the recalculation Amount = Value / Quantity.
2. Which customizing settings must the condition VPRS have to do so?
To ensure that the true costs of the business transaction are included in the condition VPRS, the condition must have category 'G' – Cost. Only then are the costs taken from the goods issue if needed (or from the invoice verification, goods receipt, or purchase order).
If the setting is 'S' or 'T', the value is taken exclusively from the valuation segment of the material master.
The condition category should not have an access sequence and should be flagged as statistical in the pricing procedure for pricing.
In addition, we recommend that you define the condition 004 and the subtotal field 'B' in the pricing procedure for pricing.
3. In the copy control between delivery and billing document, you enter a pricing type that does not recalculate the cost. Despite this, it was not copied from the order. Why?
Conditions with category 'G' are subject to special logic during billing. Their value is always determined from the value of the goods issue (if available).
This behavior is independent of whether the condition was merely copied or was determined in the billing document.
If you actually want to copy the cost from the order, refer to SAP Note 24832, example 1.
4. Where can I see how the cost is determined?
Go to the detailed display of the condition VPRS.
If the condition control (KSTEU) is set to 'H' here, the cost is taken from the goods issue.
If an 'A' appears here, it was calculated from the valuation segment from the material master; if it is 'D' or 'E', it was copied from the preceding document.
5. In the billing document, the amount of the condition VPRS has a different currency than in the order. Why?
If the cost is taken from the goods issue in the billing document, the amount is derived from the value (which is always in the document currency):
Amount = Value / Quantity.
As a result, the amount is always in the document currency as well. No currency translation is performed. This is the standard system behavior and cannot be changed. If you want to make modifications at this point, please contact SAP Consulting. Refer to SAP Note 45673 for more information about how the VPRS is displayed.
6. Can an item have more than one condition with category 'G', that is, several costs?
In general we do not recommend using more than one condition of type 'G' for each item. This is because only the first condition of the type 'G' for each item contains the goods issue value as the condition value. For further conditions, however, the special logic of the condition category 'G' is lost.
SAP Note 15462 provides a possible solution here.
7. Why is the condition VPRS in an item is not zero, this item if the related goods issue had the value zero?
For technical reasons, it is not possible to determine whether a goods issue with the value zero no goods issue at all within pricing. As a result, the system determines the costs from the valuation segment of the material master in both cases. For more information, see SAP Note 84229.
8. Why is currency translation for the condition VPRS performed differently than for other conditions?
In contrast with other conditions, conditions with the condition category 'G' are always converted with the exchange rate type 'M', regardless of which exchange rate type is defined in the customer master (exception: Intercompany billing).
This is intended to ensure that the costs posted in Financial Accounting (module FI) and Controlling (module CO) are identical.
For more information, refer to SAP Notes 185225 and 50478..
9. Can the condition VPRS as the basis for other, non-statistical conditions?
We do not recommend using the condition VPRS as the basis of other conditions, because otherwise the following problems may occur:
a) During currency translation, the specific rules are implicitly transferred to the dependent conditions.
b) As part of third-party business transactions or individual purchase orders, the costs in the billing document (and therefore also the value of the condition VPRS) might be changed again subsequently (also see SAP Note 372760).
If the document is already in accounting, however, an adjustment of additional conditions is no longer allowed and is not carried out. As a result, you risk inconsistencies if other conditions depend on the value of the condition VPRS.
10. During the processing of billing plans, the system always sets the full cost. What should I do?
Check the pricing type in the copy control between the order/contract and billing document. This pricing type must NOT recalculate the costs, because otherwise the full cost would be recalculated in every invoice.
Note 24832 describes which pricing type recalculates which conditions.
11. Why does the system not change the condition VPRS when pricing is carried out again in the billing document?
In general, the transfer price is taken from the goods issue in the billing document. However, the information about the goods issue is only available when the document is created.
Therefore, during a repeated price determination, the real costs would be irrevocably lost if the condition VPRS were recalculated.
The same applies to costs from costing EK01, EK02 (condition category 'Q'), which is why it is not recalculated in the billing document either.
12. During delivery-related billing of a partial quantity of a delivery, in some cases the prorated billing value is set and in other cases the full billing value is set. Why?
There are various business processes with the billing of a partial quantity of the delivery:
a) Delivery-related invoices for partial quantity
b) Billing document for proof of delivery (POD)
For a) Delivery-related invoices for partial quantity
With this business process, the following is intended:
1) The planned distribution of the delivery quantity over partial invoices
2) After the first invoice for a partial quantity, further invoices with partial quantities
3) Overall, invoicing of total delivery quantity
This is enabled using an item category with one of the following billing relevances:
- "K Delivery-related invoices for partial quantity"
- "O Deliv.-related invoices for part. quant. - no zero quantities"
Example: A business process with a partial quantity billing of the delivery quantity that is processed via the selection of the billing document item
In this case, a prorated billing value is set for each billing document with a partial quantity of the total delivery quantity.
Following the last partial quantity billing document, the entire billing value is distributed.
For b) Billing document for proof of delivery (POD)
With this business process, the following is intended:
1) Posting of goods issue for delivery with the entire delivery quantity
2) Final completion of delivery billing after the first invoice
Example: A business process with a quantity confirmed by the customer that differs from (is normally less than) the delivery quantity
In this case, the entire billing value is set for the single billing document.
Refer also to SAP Note 372772.
FAQ: Header conditions or header condition screen
1. What is meant by 'actual' header conditions?
'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:
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
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'.
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:
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:
The condition bases in the left column result in the condition values displayed in the right column. In this case, item 40 (the item with the largest condition basis) receives the resulting rounding difference of EUR 0.01-.
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.
a) What happens if the condition basis for HB00 changes on one of the open items?
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:
b) What happens if a further item is created?
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:
c) What happens if the outstanding condition rate of EUR 7.09- is changed for HB00?
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:
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.
Keep in mind: Due to the 'subsequent' intervention in the already 'partly fixed' distribution, the distribution of the overall condition value for HB00 - seen for all document items - no longer corresponds to the relationship of the condition bases. In fact, the relationship in general is only correct within a group of items that were fixed together (10 -30) or that are all outstanding (40, 50 [and 60]).
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.
'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, the contents of the KAWRT and KWERT fields in the KONV table are not important for an 'actual' header condition. Standard R/3 pricing does not access these values. In standard R/3 pricing, these values are not the basis for any function.
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.
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
If it is required to create a condition table with a custom field the following steps should be followed.
Add the field in KOMKAZ or KOMPAZ structure. If the field is at the header level, add the field to KOMKAZ, and if the field is at the item level add to KOMPAZ structure. This step should be done SE11 transaction.
Activate the structure.
Add the new field to field catalog.
Create the condition table.
Adding the field to field catalog and condition table creation can be done in VOK0 transaction.
At run time the custom field should be filled with the appropriate value. To to this the following user exits should be used.
- USEREXIT_PRICING_PREPARE_TKOMK in RV60AFZZ .
- USEREXIT_PRICING_PREPARE_TKOMP in RV60AFZZ.
Below is an example to add sales representative , who is a partner at item level to KOMP structure.
1. Go to Se11, and add the field WWSR1. KOMPAZ Structure of KOMP
2. Open the program RV60AFZZ using SE38 transaction.
3. Add the field to field catalog. To do this go to VOK0 transaction. Then environment -> condition table -> field catalog.
4. Create the condition table. To do this go to VOK0 transaction. Goto environment-> condition table create. Enter the condition table number 980 .
Once the condition table is created, this table can be used in the access sequence. Access sequence is assigned to the condition type. Condition type is inserted in the required pricing procedure. Condition records can be created in VK11 transaction. All the condition records are created with reference to the condition type. As the condition type is linked to access sequence, and access sequence to condition table, system displays all the condition table assigned to access sequence , in the initial screen. User should select one table, and enter condition records.
Advanced Techniques, Tips, and Tricks
Data Determination via Condition Technique
Which method is the right one for your requirement is
left to your judgment. You should always keep in mind that there are usually several possible solutions.
These are the options:
- 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
In the standard SAP system, we have condition types that have characteristics
with multiple occurrences. The task now is to perform the condition access for
condition types that use such a feature several times for all specified values.
In the standard SAP system, we have the following examples of condition types
with multiple value fields:
VA00: Variants (VARCOND)
PB1D: Sales deal determination (KNUMA_AG)
KAD0: Material costs (ADDNR) from the condition application M (purchasing)
To solve this problem, we use the Data Dictionary (DIC) structure KOMPLOOP. This
structure contains the characteristics listed here as well as additional information,
such as a quantity that is needed to calculate the condition.
The structure is part of the item structure KOMP. Within the pricing program,
there is a corresponding internal table called XKOMPLOOP.
Important Programs for Pricing
PRICING function module
The PRICING function module performs pricing for an item. The caller prepares
the communication structures KOMK and KOMP and passes them along with a
pricing type to the function module.
The particular parts of this code have the following meaning: The routine
preisfindung_vorbereiten (pricing prepare) fills the communication structures (T)KOMK and (T)KOMP.
The preisfindungsart field (pricing type) must be set depending on the situation
and determines which condition types should be recalculated. The possible values are stored in the domain KNPRS.
PRICING_COMPLETE Function Module
The PRICING_COMPLETE function module is required, at the latest, at the time of
saving the document: Here, the whole document is passed with all items and all conditions.
Here, all condition types that are configured as a group condition are definitively
valuated, including the manually entered header conditions.
Here, the cross-item activities are carried out (e.g., determination of the scale
base and rounding difference comparison).
PRICING_COPY Function Module
When creating documents with reference, the PRICING_COPY function module
reads the document conditions of the reference document from the database
table KONV and takes them over in the current document to XKOMV.
The pricing type is determined from the copying control (in this case, table TVCPF)
and handed over in the mode parameter. During a copying operation, the document currency can change. It may also be
that the quantities of source item and destination item are different (partial delivery).
PRICING_REFRESH Function Module
System Adaptation Using Requirements, Formulas, and User Exits
Pricing Types
The pricing types are set up in the konditionsvorstep routine in the internal
table STEU. Customer-specific pricing types can be established via the userexit_
pricing_rule.
If the control possibilities available using pricing types are insufficient, you can
override the behavior of the pricing types via the internal tables TKSCHL and
TKSCHLEXCL.
In the komp-kaend_typ field (unchangeable condition categories), you can enter
up to five condition categories that must not be changed within the pricing.
Requirements
If a requirement check returns a negative outcome (sy-subrc ne zero), no database accesses are performed on the condition tables, or the condition type is not
included in the internal table of condition types KOMT1. Thus, it is clear that it is
always advantageous, if possible, to prevent database access with skillfully prepared requirements.
The prestep requirement is processed at the time of the setup of the internal
tables of the condition types, KOMT1, and of the access sequences, KOMT2. If
this test is negative, the condition type or the access is not included in the internal table and thus the condition type or the access is not taken into account.
In the prestep requirement, only the field contents of the structure KOMK can be
evaluated. Item information, meaning the fields of structure KOMP, can only be
evaluated in the definite requirement.
(KOBED) The actual definite requirement is called in the xkomv_aufbauen_aus_komt1 and
konditionen_lesen routines.
Formulas for Pricing Conditions
Condition base formulas (also called base formulas)
Examples:002 (Net value)
004 (Net value + tax)
008 (100% discount; used in condition type R100)
029 (Free goods/inclusive; used in condition type NRAB)
022 (Whole number; used in condition type KP00)
Scale base formulas (also called scale formulas)
023 (partial quantity)
Setting a partial quantity in condition type KP03 for determining a mixed pallet
surcharge, if necessary.
Condition value formulas (also called value formulas)
008 (expected value)
The price expected by the customer is compared to the calculated price and the
item will be blocked for delivery if the differen
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
Here you can finally evaluate the pricing result, that is the internal table XKOMV, and possibly change KOMP fields within the framework of what
is permissible.
Routine USEREXIT_XKOMV_BEWERTEN_INIT
Here you can initialize your customer-specific fields that
you added to the KOMP structure and that are processed by formulas, which in
general is necessary for an error-free functioning.
Routine USEREXIT_XKOMV_ERGAENZEN
This routine serves first to fill the fields of the dynamic part
KONVD of XKOMV (the database only stores the fields of the table KONV), and
then updates information collected from the condition master records
Routine USEREXIT_XKOMV_ERGAENZEN_MANU
The userexit_xkomv_ergaenzen_manu routine is called at the end of the xkomv_
ergaenzen_manuelle routine and it provides the XKOMV data for manually added
condition types. In this case, the MKOMV structure contains the manual entries.
Routine USEREXIT_XKOMV_FUELLEN
The userexit_xkomv_fuellen routine is called at the end of the xkomv_fuellen
routine, which fills the structure XKOMV for a condition type for which there is
a condition record. In particular, you can prevent the handover of the condition
type by setting the returncode field to something other than zero.
Routine USEREXIT_XKOMV_FUELLEN_O_KONP
The userexit_xkomv_fuellen_o_konp routine is called at the end of the xkomv_
fuellen_ohne_konp routine and fills the structure XKOMV for condition types that are not determined by condition records. These are condition types without
an access sequence.
User Exits of Function Group V69A
The function group V69A gathers the user exits of the dialog part of the pricing
program. The routines are processed when you call the Conditions screens in the
sales order, billing document, and purchasing order screens in the SAP GUI.
Routine USEREXIT_CHANGE_PRICING_RULE
The user exit is called at the end of kot_ende routine and runs at the end of the
Document Conditions screen to process the changes.
Routine USEREXIT_FIELD_MODIFICATION
The userexit_field_modification routine is called at the end of the feldauswahl
routine (field selection) in which the SAP GUI Document Conditions screen is
prepared with respect to the visibility and readiness for input of the fields. This
routine is processed for all lines in the pricing procedure that contain a condition
type.
Routine USEREXIT_FIELD_MODIFIC_KOPF
The routine userexit_field_modific_kopf is used to process the subtotal lines in
the Header Conditions screen. The interfaces are the same as in the userexit_
field_modification routine.
Routine USEREXIT_FIELD_MODIFIC_KZWI
The userexit_field_modific_kzwi routine is used to process the subtotal lines in
the Item Conditions screen. The interfaces are the same as in the userexit_
field_modification routine.
Routine USEREXIT_FIELD_MODIFIC_LEER
The userexit_field_modific_leer routine is used to process the blank lines in
the Header and Item Conditions screen. The interfaces are the same as in the
userexit_field_modification routine.
Routine USEREXIT_PRICING_CHECK
The userexit_pricing_check routine is called at the end of the kondition_pruefen
routine, where manual inputs in the Conditions screen are checked. This is the
only place where you are allowed to display error messages or warnings to prevent
invalid entries.
Typical Practice Demands on Pricing and Their Solutions
Budgeting Requirements
We use this functionality of the condition update to limit the application of certain condition records to meet general budgeting requirements.
All sales transactions to customers of the customer hierarchy node 421 should not
exceed a maximum weight of 600 kg and a maximum value of EUR 1,000. Orders that
are above these limits will be checked and have to be released specifically.
With Transaction V.25 (see Figure 12.8), you can select the blocked sales orders
and optionally release them for further processing.
Prices with More Than Two Decimal Places
Currencies in the SAP system have a fixed number of decimal places. For example, the USD currency has two decimal places. This means that all prices and values in this currency are always displayed with two decimal places.
In this case, you can use SAP Note 38881 (Pricing with Different Decimal Places)
in which a parallel currency USD with a maximum of five decimal places is introduced. Prices in the condition records are then maintained in that currency. However, the document currency always remains USD
Our recommended solution is to use the condition unit, especially since this is a
standard functionality. If the representation, for example, in the invoice printing
is to take place with five decimal places, then this could be achieved by a small
modification in the editing for printout via existing user exits.
Handling Freight Surcharges
Shipping costs are usually configured as fixed value condition types and often
have a value scale. If the delivery takes place is in several parts, there are demands
on the billing that are not met in the standard. In addition, you must clarify how
these condition types are to be handled in the subsequent documents such as
credits notes and returns. There is also the question of how to proceed with shipping costs for free goods items.
Complete Billing of Freight Surcharges with the First Delivery
- 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
It is only prepared in
the form of the BAdI PRICING_AUTHORITY_CHECK_UI and the sample implementation VF_PRC_AUTH_EXAMPLE. In SAP Note 1165078 (Authorization Check for Conditions or Subtotals), you can find a description of the required steps.
Adding Subtotal Fields
The fields are mainly used for SAP BW or
other statistical evaluations. If these six fields are not sufficient, you can add more
value fields with a little effort. Simply create more data elements in the customer
namespace and insert them by using an APPEND to the tables and VBAP VBRP and
to the structures KOMPAZ and KOMPAXA. You can then fill the new KOMP fields
with appropriate condition value formulas. Additionally, you should initialize
these new KOMP fields in the routine userexit_xkomv_bewerten_init of the
function group V61A. For detailed instructions, see SAP Note 155012 (Further
Subtotal Fields in Pricing).
Copied Conditions and Subsequent Quantity Changes
There are some condition types that are problematic when you create follow-up
documents. These are primarily conditions types with the calculation type B
(Fixed amount).
One approach to automatically adjust the copied fixed amount condition types at
quantity changes is the modification via a user exit in program RV61AFZA displayed in Listing 12.5.
form userexit_pricing_copy.
if vbtyp_new ca vbtyp_verk and konv-ksteu ne 'A' and
( konv-kschl = RB00' or
konv-kschl = 'HM00' or
konv-kschl = 'HB00' or
konv-kschl = 'AMIW' or
konv-kschl = 'AMIZ' ).
konv-ksteu = 'F'.
konv-kherk = 'G'.
endif.
endform.
Increased Prices in Returns and Credit Notes
The condition type PR02 (price increased) is configured in the standard SAP system with scale type D (interval scale) In this situation we see,
depending on the order quantity, multiple entries of the condition type. For each
quantity change, a new pricing is carried out, as this may change the number of
entries again. For invoices based on partial deliveries, the conditions are taken
from the sales order and all values are adjusted proportionately to the partial
quantity.
When we now create a return or credit memo with reference to this invoice, the
condition is recalculated so that, with the reduced credit quantity, another price
as in the invoice can result. Therefore, the conditions need to be copied and
adjusted proportionately to the quantity.
For a possible solution to this problem, see SAP Note 39774 (returns for invoices
using graduated scale pricing), where a new condition type that represents the
average price is introduced to solve the problem.
An alternative and much simpler solution is the new requirement 906 (copied not
new) that has to be set up. You simply assign this requirement to your affected
condition type.
Pricing in Selected Applications
Pricing in Sales Orders
Routine USEREXIT_PRICING_PREPARE_TKOMK
In the userexit_pricing_prepare_tkomk routine, you can influence the field
assignment of the interface structure TKOMK. In particular, you will fill your customer-specific fields here, if they are not anyway filled by move-corresponding.
Some of the important fields of USEREXIT_PRICING_PREPARE_TKOMK and USEREXIT_
PRICING_PREPARE_TKOMP
Routine USEREXIT_NEW_PRICING_VBAP
In the userexit_new_pricing_vbap routine you can evaluate
changes of item fields handing over an appropriate pricing type in the transfer
parameter NEW_PRICING.
If in doubt, you should use the pricing type C. This may recalculate some conditions unnecessarily. However, this will do no harm, assuming you have not previously deleted a condition type. This deleted condition type would then be
found again. Thus, it is always better to set the condition amount to zero instead
of deleting the condition type.
Routine USEREXIT_NEW_PRICING_VBKD
In the userexit_new_pricing_vbkd routine , you can evaluate
changes in the document header or the business data
Pricing in Billing Documents
A special role in the billing document plays the tkomp-wavwr field. Via this field,
the actual cost of a sales transaction is transferred within pricing into the respective transfer price condition type (defined by the Condition Type = G). Some of
the important fields of USEREXIT_PRICING_PREPARE_TKOMK and USEREXIT_PRICING_PREPARE_TKOMP.
Pricing in Purchase Orders
The pricing in the purchase order is called in program SAPMM06E for the application M. The relevant program calls can be found in:
preisfindung(SAPMM06E): Calls the PRICING function module
preisfindung_complete(SAPMM06E): Calls the PRICING_COMPLETE function module
preisfindung_vorbereiten(SAPMM06E)
Function MEPOBADI_PROCESS_KOMK: BAdI for the KOMK interface
Function MEPOBADI_PROCESS_KOMP: BAdI for the KOMP interface
Pricing in Transport Management (Shipment Cost Calculation)
Within the transport process, a shipment cost calculation is performed using the
pricing functionality with the application F.
The determination of the pricing procedure depends on the transportation planning point, the freight item category, the service provider, and the shipping
method.
The shipment cost calculation is integrated in the sales order and to the billing
document. In the sales order, planned freight costs can be transferred to a statistical condition type by calling a freight simulation. In the billing document, actual values from the shipment cost calculation can be passed to the billing item as statistical values, or they are billed as freight costs to the customer. At this point the
field Price source (F = shipment costs) from the copying control for billing documents comes into play.
Pricing in Accounting
In accounting, the pricing functionality is used in the following applications:
- 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.As the cost cumulation works for both batches and BOM items. If from delivery items, the subitem has both Higher-Level item of Batch (LIPS-UECHA) and Higher-Level item of BOM (LIPS-UEPOS) filled, when the Higher-Level item (LIPS-UEPOS) is referring to another main item, then the cost (VPRS) will also be cumulated to that higher level item.
A solution is only possible with Userexit. Implement the following proposal in the subroutine FORM USEREXIT_FILL_VBRK_VBRP in include RV60AFZC.
With this proposal you can set your own specific criteria to restrict the changes.
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.
Reason and Prerequisites
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
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
Solution
You can choose one of the following options to make sure that only one GRWR condition is set :
1. Use the same step number for condition type GRWR in the pricing procedure of Purchasing and in the pricing procedure of Sales And Distribution.
2. Use condition category ' ' instead of 'L' for condition type GRWR in Sales and Distribution and in Purchasing.
3. Add a condition (for example 999) to condition type GRWR in the Sales and Distribution pricing procedure that prevents the redetermination in the case of an intercompany billing. For this purpose, copy the following source code to the KOBED part of the condition while no additional source code is added to the KOBEV part:
form kobed_999.
sy-subrc = 4.
check komk-vbtyp ne '5'. " not for intercompany invoice
check komk-vbtyp ne '6' " not for Intercompany credit memo
sy-subrc = 0.
endform.
* Prestep
form kobev_999.
sy-subrc = 0.
endform.
4. Use USEREXIT_PRICING_COPY in the include RV61AFZA and reset the price source for condition type GRWR as follows:
* only for condition GRWR and intercompany invoice/credit memo
if konv-kntyp = 'L' and
konv-kschl = 'GRWR' and
vbtyp_new ca '56'.
konv-prsqu = ' '.
endif.
2414653 - Price condition is inactive in the purchase order
Even though the purchase order item is not deleted (EKPO-LOEKZ = blank), the statistical item flag is set (EKPO-STAPO = X). This should not be the case, since this flag is set when the item is deleted.
183820 - Print of inactive conditions
If you use the new print IDs (DRUKZ = A, B, C, D, a, b, c, d), during the printing of a billing document or order confirmation, the system incorrectly also prints condition records that are inactive due to exclusion.
24832 - Pricing rules/TVCPF
The pricing type controls which condition types are redetermined and which are copied unchanged.
(However, the item is always revaluated). Below, you will find a description of the pricing type characteristics that are used in the standard system (for the enhancement options for customers, see SAP Note 26115). Note that the specified standard pricing types sometimes do not exist in older releases, or that the standard pricing type characteristic may be different in the individual releases. Therefore, the given consulting note should not be considered to be exhaustive. It merely serves to explain the principle of how a pricing type is structured and how its characteristics can be influenced. The exact characteristic of a pricing type in the release being used can be seen directly in the source code of the form routine KONDITIONSVORSTEP in the main program SAPLV61A.
*********************** Example 1 ********************************
You want to copy the condition type 'VPRS' (cost) from the order into the billing document. You are using the pricing type G. However, as a consequence, the value of the VPRS condition in the billing document may differ from the value of the goods issue posting.
Pricing type 'X' is to be set in such a way that the condition 'VPRS' (which has the condition category 'G') is not redetermined during billing. Otherwise, it behaves as pricing type 'G'.
Up to Release 4.0B, USEREXIT_PRICING_RULE can be implemented as follows:
FORM USEREXIT_PRICING_RULE.
STEU-KNPRS = 'X'.
STEU-KNTYP = 'LRIE......'.
IF KOMK-KNUMA IS INITIAL.
STEU-KOAID = 'CD........'.
ELSE.
STEU-KOAID = 'D.........'.
ENDIF.
STEU-MAUEB = ' '.
APPEND STEU.
ENDFORM.
In order to ensure that pricing type 'X' acts exactly like pricing type 'G', the FORM routine USEREXIT_PRICING_COPY in Program RV61AFZA is to be used in releases lower than Release 4.0A ( this is called when you create a document with reference to another document: copying control; here, the MODE is the pricing type):
FORM USEREXIT_PRICING_COPY.
IF MODE CA 'X'.
IF KONV-KSTEU NA 'CEF'.
KONV-KSTEU = 'D'.
ENDIF.
ENDIF.
ENDFORM.
In this case, you should note that the billing document contains a special rule concerning the cost condition 'VPRS'. If the goods issue is posted for the delivery note to be billed, the value of the goods issue is copied into condition 'VPRS'. This is hard coded. You can prevent this by setting the field TKOMP-WAVWR to zero in the include RV60AFZZ, USEREXIT_PRICING_PREPARE_TKOMP.
In higher releases, pricing type 'K' is also available, which copies the VPRS of the order to the billing document and does not redetermine it unless there is no goods issue posting
(otherwise, the above-mentioned special rule applies.)
*********************** Example 2 ********************************
You want to copy the condition type 'PI01' ("Price for intercompany billing") from the order into the billing document. You are using the pricing type G.
Pricing type 'Y' is to be set in a way that this works as pricing type 'G' but without redetermining the intercompany billing conditions 'PI01' and 'PI02'. They have condition category 'I'.
Changes in program RV61AFZA:
FORM USEREXIT_PRICING_RULE.
STEU-KNPRS = 'Y'.
STEU-KNTYP = 'GLRE.......'.
IF KOMK-KNUMA IS INITIAL.
STEU-KOAID = 'CD........'.
ELSE.
STEU-KOAID = 'D.........'.
ENDIF.
APPEND STEU.
ENDFORM.
In order to ensure that pricing type 'Y' acts exactly like pricing type 'G', the form routine USEREXIT_PRICING_COPY in the program RV61AFZA is to be used:
FORM USEREXIT_PRICING_COPY.
IF MODE CA 'Y'.
IF KONV-KSTEU NA 'CEF'.
KONV-KSTEU = 'D'.
ENDIF.
CLEAR: KONV-SAKN1.
ENDIF.
ENDFORM.
*********************** Example 3 *********************************
The cost 'VPRS' is to be redetermined when copying a credit memo request from a billing document. This is required if you defined the credit memo item in such a way that no costs are to be determined. Since the pricing conditions are no longer checked when copying, you have to proceed as described above to eliminate the VPRS condition.
*********************** Example 4 *********************************
The "New pricing" function on the item condition screen is to keep the manual condition. This means the function should behave like pricing category C.
*********************** Example 5 *********************************
The "New pricing" function for the entire order is to keep the manual conditions; this means the function should behave like pricing category C.
*********************** Example 6 *********************************
Billing is to be performed using the pricing type G. However, condition types with condition category S and T (standard cost or moving cost) are also to be redetermined in the billing document. In the standard system, this pricing type copies those condition types from the order.
You can display the standard behavior of the pricing types in the form routine KONDITIONSVORSTEP (up to Release 3.1I in the include LV61AF0K, as of Release 4.0A in the include LV61AA12). There, for each pricing type, a line exists in the internal table STEU. The fields have the following meaning:
KNPRS
This is the pricing type used.
KNTYP
This field contains a positive list of the pricing categories (up to 10
values can be entered).
KOAID
This field contains a positive list of the condition classes (up to 10 values can be entered).
MAUEB This XFELD specifies whether manual changes should be copied.
STFKZ
This field contains a positive list of the scale indicators (up to 5 values can be entered).
NOTYP
This field contains a negative list of the condition categories (up to 5 values can be entered).
KDUPL
This field contains a positive list of the structure conditions (up to 3 values can be entered).
NOKDUPL
This field contains a negative list of the structure conditions (up to 3 values can be entered).
KFKIV
This field specifies whether intercompany billings should be redetermined ('.' or 'X' can be entered).
KVARC
This field specifies whether variant conditions should be redetermined ('.' or 'X' can be entered).
PRSQU
This field specifies whether the price source should be taken into account ('.' or SPACE can be entered).
'A' (Copy price components and redetermine scales)
- No condition types are redetermined. Only the scale prices are adapted due to a changed basis.
'B' (Execute new pricing)
- Completely new pricing (as if you created a new item), manual conditions are lost.
Restriction: Condition types which are not determined via condition technique (for example, condition type 'VPRS' or condition types with KNTYP = 'G' which are determined using formulas) are NOT redetermined even if you did not change them manually.
'C' (Copy manual pricing elements and redetermine the others)
- 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.
'D' (Copy pricing elements unchanged)
- As in pricing type A but the prices are fixed (no scales are read). Condition basis and condition basis value are redetermined.
'E' (Adopt price components and fix values)
- As in pricing type D but neither the condition basis nor the condition basis value are redetermined.
'F' (Copy pricing elements, turn value and fix)
- Only used within the program.
'G' (Copy pricing elements unchanged and redetermine taxes)
The following condition types are redetermined:
- 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)
All remaining condition types are dealt with like pricing type D. In particular, with pricing type G, the system does not only redetermine the taxes but also the cost conditions and the intercompany billing conditions.
'H' (Redetermine freight conditions)
The following condition types are redetermined:
- Condition type KNTYP = 'B' (Delivery costs)
- Condition type KNTYP = 'F' (Freight conditions)
- Condition category KNTYP = 'L' (Generally new when copying)
'I' (Redetermine rebate conditions)
- Rebate conditions and scales are redetermined.
'J' (Redetermine confirmed purchase net price/value)
- Condition types with condition category KNTYP = 'D' (Confirmed purchase net price/value) are redetermined.
'K' (Adopt price components and costs. Redetermine taxes)
The following condition types 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)
'M' (Copy pricing elements, turn value)
- No conditions are redetermined; the condition values are multiplied by -1 when copied.
'N' (Transfer pricing components unchanged, new cost)
- 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.
'O' (Redetermine variant conditions)
- Condition types with condition category KNTYP = 'O' (Variants) are redetermined.
'P' (Revaluation only)
- 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.
'U' (Redetermine precious metal conditions)
- 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
The following enhancement to the pricing procedure is therefore recommended in order to simplify matters:
(1) First, create a condition type with the following main properties:
Condition key and description, for example, 'ZNET' and 'Net Price'
Without an access sequence
Condition class 'B' (Price)
Calculation type 'C' (Quantity)
Rounding rule 'B' (Commercial)
No group condition
Changes which can be made:
- 'No limitations' for 'Manual entries'
- Select the following checkboxes: 'Item Condition', 'Amount/Percent', and - if desired - 'Delete'
(2) Add the price ZNET created in (1) to your pricing procedure at a level after the last condition in your pricing procedure that can make a contribution to the net value.
Or in other words: Add the price ZNET at a level immediately before the tax in your pricing procedure.
We also recommend that you select the 'Manual' checkbox (field KAUTO) for the price ZNET in your pricing procedure.
Effect of the enhancement
Since the price ZNET has no access sequence and is set as 'MANUAL' in the pricing procedure, nothing changes in your pricing result initially.
A line with ZNET appears in the pricing result only if the condition key ZNET is entered manually on the condition overview screen. If a condition amount is entered at the same time as ZNET or even afterwards, ZNET becomes an active price in the pricing result. As a result, all conditions before ZNET become inactive with 'Y' in accordance with the 'Last Price' logic (see SAP Note 836243, section 5). The net value of the item is therefore formed only from the condition value of ZNET, since ZNET is the only remaining non-statistical active price, surcharge, or discount due to its position in the pricing procedure. The net price of the item is then the same as the condition amount of ZNET, as per the explanations in Section 3.b of SAP Note 201830.
This means that if you manually enter a condition amount for ZNET, you automatically also change the net price of the item to precisely this amount.
Additional remarks:
1. If you want to avoid the exclusion of the conditions before ZNET with 'Y' and, instead, prefer an exclusion with 'A', you must maintain an exclusion group customizing entry accordingly:
An exclusion group ZNET with the condition type ZNET that, with the exclusion rule 'D' (exclusive), excludes an exclusion group that contains all other non-statistical condition types that come before ZNET in the pricing procedure (see Section 5 of SAP Note 836243).
2. If ZNET is not flagged as 'Manual' in your pricing procedure, even if you do not enter the condition key manually, a line with ZNET that is generated by default is already part of the pricing result. However, this is inactive with 'X' as long as you do not enter a condition amount other than zero for ZNET (see Section 1.a of SAP Note 836243). In this case, the net value and the net price calculated from it are still based on the conditions before ZNET.
3. If you want to discard the manually entered condition amount for ZNET (or the net price) again, you can do so by deleting the line with ZNET as long as you have allowed this option (see above) or by overwriting the condition amount with zero (which places you back into the state described in point 2).
2927325 - Restrictions for pricing in S/4 Hana customer management
The following pricing functions are not supported in SAP S/4HANA for 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
If the configuration of a pricing procedure contains one or more pricing functions that are not supported, and the pricing procedure is used for pricing in customer management, an error message is triggered if such a condition is determined.
If such a pricing procedure should not be used exclusively for customer management but also for sales documents, and the condition type that uses an unsupported pricing function is not relevant for customer management, you can suppress the condition type during pricing in the customer management context by assigning an appropriate requirement in the pricing procedure. The requirement could contain a check of field KOMK-KVORG (value C1 is used in the customer management context). This prevents an error message from being triggered in customer management.
1391347 - Field KOMK-AUGRU in billing document
Background:
The required functions were not converted for performance reasons.
Explanation:
The order reason is stored in the table VBRP of the billing document item data in the field AUGRU_AUFT. The assignment of this field to the field KOMK-AUGRU results in various entries in the structure KOMK for the communication header of pricing if different order reasons are used in a collective invoice in the underlying sales documents (for example, due to manual entry).
This results in decreased performance in pricing during billing.
Other fields that transfer information from the sales document, such as
- KDGRP_AUFT Customer group of sales order
- PLTYP_AUFT Price list type of sales order
are transferred from the sold-to party and are therefore unique in a collective invoice.
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
A condition type ZGRS is marked as a group condition and provided witha group key routine.
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)
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.
With adjustments in USEREXIT_XKOMV_ERGAENZEN and USEREXIT_XKOMV_ERGAENZEN_MANUELLE, the scale indicators can be set again sothat in group condition processing a cumulation occurs. For indicator STFKZ, which specifies the scale type, you must set this indicator to afixed value. This is necessary because in the standard system the information is obtained from the condition record and is not available in the items without scale.
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.
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
#Data model for condition records
The following database tables are relevant for condition records in pricing in SAP R/3 (using 'A'):
- 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.)
The fields MANDT, KAPPL, KSCHL, and DATBI are key fields of every A table. Additional key fields for an A table are can be freely defined from the field catalog KOMG (including KOMKAZ and KOMPAZ). The field KNUMH (condition record number) is the data field of the A table.
In addition, the field KNUMH is the key field of the tables KONH, KONP, KONM, and KONW. Therefore, KNUMH is a unique indicator that points from a condition record of an A table to tables KONH, KONP, KONM, and KONW.
While the A table only contains the keys for finding a condition record, the actual data of the condition record is stored in the other tables:
- 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.
#The condition access process in pricing
- 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.
Effect on certain settings in Customizing for condition access
a) An access sequence uses several condition accesses that are flagged as exclusive (KZEXL), for example:
AcNo Tab Name Excl.
- 10 305 Customer/material with KFRST X
- 20 304 Material with KFRST X
Tables A305 and A304 each contain a valid record.
Example 3.a.1: The record in table 305 is deleted using a deletion indicator (field LOEVM_KO).
In this case, the condition access works as follows.
Access 10 to table 305 determines the valid record from table 305 and returns its KNUMH to pricing. At this time, it is not known in the access whether the record is flagged for deletion. This can be determined only when the record is read from the KONP, since the deletion indicator is not a key field of a condition record (A table) but part of the data information (table KONP).
FORM KONDITIONEN_LESEN (include LV61AA29):
SELECT * FROM konp WHERE knumh = xknumh
AND loevm_ko = space.
If this SELECT fails, the record is flagged for deletion and the system continues with access 20.
Example 3.a.2: The system does not reach the first scale level of a scale condition record.
With access 10 to table 305, a valid condition record with a scale is determined, for example
from 10 pieces 3.00 EUR
100 5.00
This is entered in the pricing result. Access 20 is not executed. As part of the evaluation of the pricing result (later stage in the program, see also Note 900089, steps 3.d and 3.e), a scale base value of 7 pieces is determined. In this case, the system does not even reach the first scale level. Therefore, a condition rate of zero is used. You may have expected the condition record from access 20/table 304 to be used with a condition rate other than zero.
b) An access is set as a hierarchy access.
This means that a part of the key fields is allowed as a free key part. During condition access, the system finds several valid records. The module SD_COND_ACCESS determines the record with the highest priority and returns its KNUMH to pricing. In pricing, when the table KONP is read, you realize that the record with the highest priority is deleted using deletion indicators. The system is unable to access the record with the second-highest priority.
c) An access is set as a multi-valued access,
that is, multiple-value attributes are used for some of the key fields. During condition access, the system processes the individual acesses of an exclusive access sequence step by step. As soon as a valid condition record without deletion indicator is found for an access of at least one attribute, the subsequent accesses in standard price determination are no longer executed.
This means if no valid condition record was found for a given attribute at this point, the system does not search for further condition records.
# Recommendations
You can change this behavior, for example, by making the following settings:
a) In the Customizing for the condition type (for example, transaction V/06, M/06) you can define in the master data section how condition records are deleted (field KDELE). When you select the 'SPACE (do not delete, only set the deletion flag)' setting, the condition record is retained in the A table for the time being and can be archived at a later stage using an archiving session (archiving object SD_COND, see SAP Note 838768).
If you select one of the two settings 'A (with dialog boxes)' or 'B (without dialog boxes)' here, the record is physically deleted at once from the A table when you select the deletion flag and save your change. As a result, this record can no longer be determined in the condition access, so the effect from example 3.b cannot occur.
A disadvantage of this procedure is that you can no longer access this condition record from the pricing result of existing documents.
b) Similarly, you can work with two or more condition types, each of which uses an access sequence with just one access:
- Condition 1 > > access sequence 1 > > 1 access to table A305
- Condition 2 > > access sequence 2 > > 1 access to table A304
If condition 1 is determined and it does not have a deletion flag, it is set in the pricing result.
The definition of suitable exclusion groups (see Note 836243, section 4, exclusion rule 'D') allows you to exclude condition 2 using condition 1. If condition 1 is supposed to have a deletion indicator, it is not set in the pricing result and the exclusion of condition 2 is halted.
Exclusion groups also allow you to avoid the effect from example 3.a.2:
If condition 1 is supposed to display a condition rate of zero and therefore a condition value of zero, the exclusion is not carried out here either, and so condition 2 remains active (for details, see Note 836243, section 4, 'Note the following', point b).
c) You can also avoid the effect from example 3.a.2 by pre assigning the customer/material price a scale level "as of 1 pc" that uses the same condition rate as the material price.
d) The system behavior from example 3.c can be changed by implementing the modification described in consulting Note 2468210.
In this case, the subsequent accesses are performed for the remaining attributes.
Note, however, that even if the proposed modification is used, attributes for which a condition record with deletion indicator have been determined are not used for the subsequent accesses. Therefore, if you use multiple-value accesses, recommendation a) still applies.
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.1. Determination of pricing unit and unit of measure:
- 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.
2. Determination of currency:
The currency of the net price is always the document currency (KOMK-WAERK).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 the correct determination of the pricing unit and unit of measure, the conversion factors (XKOMV-KUMZA and XKOMV-KUMNE) are extremely important for the quantity conversion between the condition unit and the base unit of measure (for more information see SAP Note 854978).
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.
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.
What must be taken into consideration in modifications?
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).
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.
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).
Create a new condition value formula in the customer namespace (for example, 602) (transaction VOFM), and assign this condition value formula to the relevant condition type in the pricing procedure (transaction V/08).
To use the table T006 in the formula, you must change LV61ATOP for the specified releases.
To use the table T006 in the formula, you must change LV61ATOP for the specified releases.
form frm_kondi_wert_602.
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.
...
*&--------------------------------------------------------------------*
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.
Comment 1:
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
Include LV61AA52
FORM XKOMV_FUELLEN
Include LV61AA55
FORM XKOMV_BEWERTEN
Include LV61AA52
FORM XKOMV_FUELLEN
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
If the error is reproducible,
1.Check if the access could be fulfilled in the pricing pre-step.
Set a breakpoint in routine LV61AA30 at:
call function 'SD_COND_ACCESS'
2. Check if the access cannot find the condition record in real condition access.
Set a breakpoint in routine LV61AA29 at:
call function 'SD_COND_ACCESS'
Run the transaction until KOMT1-RKSCHL gets the desired condition type.
Execute the function module and check SY-SUBRC.
If SY-SUBRC is not 0, no condition record could be found. Check the fields in KOMK and KOMP which are relevant for the condition access. Also make a check with the pricing date field KOMK-PRSDT.
If SY-SUBRC = 0 after executing function module SD_COND_ACCESS, it means a condition record has been found. Then you’ll need to go ahead and debug to check why no entry gets inserted into XKOMV afterwards, especially you may have some further check in FORM XKOMV_FUELLEN (LV61AA52).
New fields in selection screen (Texts) 31.08.2021
Copy fixed conditions without recalculation ( 10.09.2021 )
LV61AU15/PRICING_COPY
Here we can add enhancement to avoid it.
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.
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