2 Replies Latest reply: Jul 1, 2008 9:20 AM by Kishore Kumar Chiluka RSS

Tolerance limits for PO,MIGO..etc..?

mm sap mm sapmm
Currently Being Moderated

Dear all

 

Can anybody explain me about the tolerance limits in SAP-MM,

1.what is tolerance limits..?

2.Why tolerance limits need in SAP-MM..?

3.How to configure in SPRO

 

Which are all the area has to maintain Tolerance limits according to MM point of view

 

Advance thanks

 

goods answers will be highly rewardable.

 

Thanks

sap-mm

  • Re: Tolerance limits for PO,MIGO..etc..?
    Varaghamurthy Chakravarthy Kannan
    Currently Being Moderated

    Hi,

     

    Maintain the tolearnce key in

    SPRO-> IMG-> Materials Management-> Purchasing-> Purchase Order-> Set Tolerance Limits for Price Variance

     

    If you want the sytem to propmt for a warning or Error message you can configure the same in

    SPRO-> IMG-> Materials Management-> Purchasing-> Environment Data-> Define Attributes of System Messages

     

    Reward If useful

     

    Regards

  • Re: Tolerance limits for PO,MIGO..etc..?
    Kishore Kumar Chiluka
    Currently Being Moderated

    Hi

     

    tolerance limits for price variancesin Purchase order

    When processing a purchase order, the system checks whether the effective price of a PO item shows variances compared with the valuation price stored in the material master record. In addition, it checks whether the specified cash discount value is admissible.

     

    Variances are allowed within the framework of tolerance limits. If a variance exceeds a tolerance limit, the system issues a warning or error message.

     

    In the SAP System, the types of variance are represented by the tolerance keys. For each tolerance key, you can define percentage and value-dependent upper and lower limits per company code.

     

    Standard settings

     

    The standard SAP System supplied contains the following tolerance keys:

     

    PE Price variance, Purchasing

    Tolerance limit for system message no. 207. This message appears if the specified effective price exceeds the predefined tolerances when compared with the material price.

    SE Maximum cash discount deduction, Purchasing

    Tolerance limit for system message no. 231. This is a warning message, which appears when the specified cash discount percentage exceeds the predefined tolerances.

    Note

    You can specify whether the system message appears as a warning or error message using the menu options Environment -> Define Attributes of System Messages.

     

    For Invoices specify the tolerance limits for each tolerance key for each company code.

    When processing an invoice, the R/3 System checks each item for variances between the invoice and the purchase order or goods receipt. The different types of variances are defined in tolerance keys.

     

    The system uses the following tolerance keys to check for variances:

     

    AN: Amount for item without order reference

    If you activate the item amount check, the system checks every line item in an invoice with no order reference against the absolute upper limit defined.

    AP: Amount for item with order reference

    If you activate the item amount check, the system checks specific line items in an invoice with order reference against the absolute upper limit defined. Which invoice items are checked depends on how you configure the item amount check.

    BD: Form small differences automatically

    The system checks the balance of the invoice against the absolute upper limit defined. If the upper limit is not exceeded, the system automatically creates a posting line called Expense/Income from Small Differences, making the balance zero and allowing the system to post the document.

    BR: Percentage OPUn variance (IR before GR)

    The system calculates the percentage variance between the following ratios: quantity invoiced in order price quantity units : quantity invoiced in order units and quantity ordered in order price quantity units : quantity ordered in order units. The system compares the variance with the upper and lower percentage tolerance limits.

    BW: Percentage OPUn variance (GR before IR)

    The system calculates the percentage variance between the following ratios: quantity invoiced in order price quantity units: quantity invoiced in order units and goods receipt quantity in order price quantity units : goods receipt quantity in order units. The system compares the variance with the upper and lower percentage limits defined.

    DQ: Exceed amount: quantity variance

    If a goods receipt has been defined for an order item and a goods receipt has already been posted, the system multiplies the net order price by (quantity invoiced - (total quantity delivered - total quantity invoiced)).

    If no goods receipt has been defined, the system multiplies the net order price by (quantity invoiced - (quantity ordered - total quantity invoiced)).

    The system compares the outcome with the absolute upper and lower limits defined.

    This allows relatively high quantity variances for invoice items for small amounts, but only small quantity variances for invoice items for larger amounts.

    You can also configure percentage limits for the quantity variance check. In this case, the system calculates the percentage variance from the expected quantity, irrespective of the order price, and compares the outcome with the percentage limits configured.

    The system also carries out a quantity variance check for planned delivery costs.

    DW: Quantity variance when GR quantity = zero

    If a goods receipt is defined for an order item but none has as yet been posted, the system multiplies the net order price by (quantity invoiced + total quantity invoiced so far).

    The system then compares the outcome with the absolute upper tolerance limit defined.

    If you have not maintained tolerance key DW for your company code, the system blocks an invoice for which no goods receipt has been posted yet. If you want to prevent this block, then set the tolerance limits for your company code for tolerance key DW to Do not check.

    KW: Variance from condition value

    The system calculates the amount by which each delivery costs item varies from the product of quantity invoiced * planned delivery costs/ planned quantity. It compares the variance with the upper and lower limits defined (absolute limits and percentage limits).

    LA: Amount of blanket purchase order

    The system calculates the sum of the value invoiced so far for the order item and the value of the current invoice and compares it with the value limit of the purchase order. It then compares the difference with the upper percentage and absolute tolerances defined.

    LD: Blanket purchase order time limit exceeded

    The system determines the number of days by which the invoice is outside the planned time interval. If the posting date of the invoice is before the validity period, the system calculates the number of days between the posting date and the start of the validity period. If the posting date of the invoice is after the validity period, the system calculates the number of days between the posting date and the end of the validity period. The system compares the number of days with the with the absolute upper limit defined.

    PP: Price variance

    The system determines by how much each invoice item varies from the product of quantity invoiced * order price. It then compares the variance with the upper and lower limits defined (absolute limits and percentage limits).

    When posting a subsequent debit/credit, the system first checks if a price check has been defined for subsequent debits/credits. If so, the system calculates the difference between (value of subsequent debit/credit + value invoiced so far) / quantity invoiced so far * quantity to be debited/credited and the product of the quantity to be debited/credited * order price and compares this with the upper and lower tolerance limits (absolute limits and percentage limits).

    PS: Price variance: estimated price

    If the price in an order item is marked as an estimated price, for this item, the system calculates the difference between the invoice value and the product of quantity invoiced * order price and compares the variance with the upper and lower tolerance limits defined (absolute limits and percentage limits).

    When posting a subsequent debit/credit, the system first checks whether a price check has been defined for subsequent debits/credits, If so, the system calculates the difference between (value of subsequent debit/credit + value invoiced so far) / quantity invoiced so far * quantity to be debited/credited and the product quantity to be debited/credited * order price. It then compares the variance with the upper and lower tolerance limits defined (absolute limits and percentage limits).

    ST: Date variance (value x days)

    The system calculates for each item the product of amount * (scheduled delivery date - date invoice entered) and compares this product with the absolute upper limit defined. This allows relatively high schedule variances for invoice items for small amounts, but only small schedule variances for invoice items for large amounts.

    VP: Moving average price variance

    When a stock posting line is created as a result of an invoice item, the system calculates the new moving average price that results from the posting. It compares the percentage variance of the new moving average price to the old price using the percentage tolerance limits defined.

    Variances are allowed within predefined tolerance limits. If a variance exceeds a tolerance limit, however, the system issues a message informing the user. If an upper limit (except with BD and VP) is exceeded, the invoice is blocked for payment when you post it. You must then release the invoice in a separate step. If the tolerance limit for BD is breached, the system cannot post the invoice.

     

    Note that if you set all limits for a tolerance key to Do not check, the system does not check that tolerance limit. Therefore any variance would be accepted. This does not make sense particularly in the case of the tolerance key Form small differences automatically.

     

    Thanks & Regards

     

    Kishore

Actions