Q1:Problems occur during price determination in transaction ME21N or ME22N.
Implement 381391 and the related s that it contains, unless - depending on your Support Package level - they have already been implemented.
Q2: What is the difference between master conditions (time-dependent conditions) and document conditions?
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.
Q3: How does the price determination determine the conditions using a last purchase order?
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. 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 .
Q4. Why does the system not carry out price determination when a scheduling agreement is created?
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.
Q5. Rounding errors occur during a price determination process that takes into account the conditions in the info record.
Check the standard quantity and the price unit in the info record. When you do this, take into accounts 30658 and 39963). To avoid rounding errors, choose a standard quantity that is at least as high as the price unit.
Q6.Why does the system not use a condition type when a purchasing document is created?
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.
Q7. 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 160630.
Q8. 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)?
See 431460.
Q9. How can I maintain conditions for a material group item in the contract?
Conditions for material group items in the contract are not permitted. (see 62729 and 105899).
Q10.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?
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.
Q11. Why is the "Refresh" (Refresh prices) pushbutton inactive on the header conditions screen in a PO?
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 457511 "FAQ: Purchase order change and goods receipt in purchasing".
Q12.Why does the system not determine the conditions automatically when I maintain a quotation (transaction ME47)?
The price determination is not carried out when quotations are maintained. You must maintain the conditions manually.
Q13.Why does the system not transfer the price from the purchase requisition to the PO?
See 393367.
Q14.Transaction ME22N: Why does the system not convert the price of the PO into the new currency when the vendor is changed (different currency)?
See 445509.
Q14.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.
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.
Read Here for more SAP MM Transaction Codes.
Q15.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? See 304178.
Q16. How does a new price determination process affect the values that were posted during the GR when a GR is canceled?
See 508009.
Q17.In what circumstances does the system update the header conditions when a PO item is deleted?
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.
Q18.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?
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.
Q19.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?
These problems indicate that the calculation schema was changed after you had created the PO. You must avoid this.
Q20.Why does the price determination not determine a price even though the master conditions (info record, contract, scheduling agreement) contain valid prices (with scales)?
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 zero to avoid these problems.
Get More Questions and Answers with Explanation related to Price Determination in Purchasing atSAP MM Forum.
Q21. 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?
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).
Q22.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 them (the system issues message 06 218 "Net price must be greater than 0")?
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".
Q23.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)?
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.
Q24.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?
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.
Q25.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?
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).
Q26. 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".
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.
Q27. 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?
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.
Q28. When is the condition value for the condition of a returns item negative, and when is it not negative?
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.
You can also get information regarding SAP MM
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.)
Q29.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?
See 586856.
Q30.If I use the user exit EXIT_SAPLMEKO_002, price determination in transaction ME21N differs from price determination in transactions ME21 and ME59.
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.
Q31.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?
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.
Q31. 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?
See 683646.
Q32.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?
You can no longer change the delivery costs after the GR has been posted. If you have implemented 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.
Q33.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?
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.
Q34.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?
You cannot compare the price determination in the scheduling agreement to the price determination for 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 401941.
Q35.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)?
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.
Q36.Can I use net prices that have more than 11 digits (including decimal places)?
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.
Q37.How can I prohibit changing the amounts on the condition screen in the conditions PB00 or PBXX using transaction ME22N? Use the user exit USEREXIT_FIELD_MODIFICATION, and use transaction SE38 to insert the source code in the include LV69AFZZ to prevent the changes.