Tolerance in condition

Hi guys,
i need to calculate tolerance of equal to or greater than the user
input of a certain KF how do i do that using a formula variable in a condition
of type customer exit, i mean i know how to code for a characteristic
variable but to change the KF value by the tolerance amount.
Thanks guys,
your help is very well appreciated.

Hello,
         For this you need not code, just create a formula variable with user entry or default value, then create a condition select the option evaluate the condition based on single characteristic or all characterisitc,
then in the operator option choose greaterthan or equal to and then in the last values option choose from variable entry,
hope it is clear,
assign points if useful

Similar Messages

  • Tolerance for condition

    Dear Expert
    we want that system should not allow to post miro when there is variation of freight i.e. one of the condition in the PO of 10 % upper and lower i have maintained in OMR6 i.e in toleance limit of the invoice block but the system is allowing to post the invoice and block for payment , but this is occuring in every case i.e. when there is variation and also when there is no variation of the amount pleasae help me in this regard

    Hi,
    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. Only in the case for BD, If the tolerance limit 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.
    And, the blocking of all invoices could be because of the stochastic block is active. If you enter a threshold value of zero and a percentage of 99.9%, all invoices would then be blocked. Please check the settings of the stochastic block also.
    Regards,
    Narayana G.

  • Powerbook Problems on Airplanes?

    My wife travels frequently cross-country, and she tells me that she has a lot of trouble powering on her laptop on the plane. Apparently, this is a consistent problem, and she has to shake it, and press in on the battery, etc. to get it to start. As soon as she is back on the ground it works fine.
    Apple has a Tech Note on this, but they claim that cabin pressure in most airlines is below the 3000 equivalent meter max operating altitude. I am checking with the airline to find out if the pressurize to the standard 60 kPa above ambient.
    Assuming they do, and it is a problem with the Powerbook, has anyone else ever seen this? Any suggestions on how I can remedy this problem? Thanks!

    Just FYI, I've never had a problem like that, using my PowerBook in flight on several airlines and aircraft across the US and on very long flights to Europe and Asia.
    It is possible that there is a subtle hardware manufacturing variation that is causing the machine to be a little bit less tolerant of conditions that are close to the edge of the spec. That's my best guess. Like the way my previous PowerBook would lose power if I picked it up, because the logic board was a little loose somewhere (after Apple serviced it, it was fine).

  • Exists condition in APEX 4.0

    Hi
    I've created an application in APEX 3.2 and I've now installed it in an APEX 4.0 environment. I've had a few issues where things have changed, but I've just hit a rather bigger problem to do with the Exisits condition that I'm hoping someone can shed some light on.
    On numerous items, regions, lists items etc. I've used the "Exists (SQL query returns at least one row)" condition. In Expression 1 I've included a select statement which ends with a semi-colon. For example,
    SELECT 1
    FROM   my_table
    WHERE  id = :P0_ID
    AND    my_col = 'Y';Now in APEX 4.0 I sometimes get an error when running the application which is ORA-00911: invalid character. This happens when viewing a list which has this condition on one of it's items, but doesn't appear to happen on regions with this condition. However, if I update any item, region, list item etc. which has this type of condition when I hit Apply Changes I get the same error. If I remove the semi-colon then the error disappears. For the above example, Expression 1 needs to be changed to:
    SELECT 1
    FROM   my_table
    WHERE  id = :P0_ID
    AND    my_col = 'Y'I've checked the Release Notes for 4.0, the Patch Set Notes for 4.0.1 and searched this forum but I've found no reference to this. (Perhaps I'm searching for the wrong thing.)
    Is this a planned change? Has anyone else experienced this? Does it only happen in certain places? I don't particularly want to go through all 20 of the APEX repositiory tables that have the Condition Type column to try and identify all the places I've used this and then change all my applications. This will be extremely time consuming, so if I know that it's a change in say only 5 places then I'll just target those places.
    Many thanks for any help on this.
    Sara

    Hi Sara,
    in previous versions of APEX we where more tolerant in regards to adding a semi-colon at the end of a SQL statement where it actually doesn't belong to. A semi-colon only has to be entered for PL/SQL commands or SQL statements within a PL/SQL code block, but never for a single SQL statement as in the case of "Exists" or an Interactive Report query. In 4.0 we have now added design time validations of SQL statements and PL/SQL code in conditions as well. Before it was stored unverified. That's why you are now hitting the problem each time you modify such a component.
    I don't think that we actually changed the runtime engine to be as restrictive as the Builder validation yet, but going forward that might be the case as well in future versions of APEX. Regarding your specific problem for list entry conditions, I don't see that the code has really changed here. It's using the same function to evaluate the condition as we use for regions and a quick test also proves that list entry conditions still accept the semi-colon.
    But I will file a bug for the new "Advisor" feature that it should also flag those components which are using a SQL statement with a semi-colon. That should help to easily identify there components where a change should be made.
    Regards
    Patrick
    My Blog: http://www.inside-oracle-apex.com
    APEX 4.0 Plug-Ins: http://apex.oracle.com/plugins
    Twitter: http://www.twitter.com/patrickwolf

  • Tolerance limits for vendors

    Hi,
    Can any of you suggest me how to overcum the below issue
    Tolerance limits need to be maintained for the tolerance key PP for company code xxxx
    VSK

    Path OMR6
    maintain following for your company code
    0001     SAP A.G.     AN     Amount for item without order reference
    0001     SAP A.G.     AP     Amount for item with order reference
    0001     SAP A.G.     BD     Form small differences automatically
    0001     SAP A.G.     BR     Percentage OPUn variance (IR before GR)
    0001     SAP A.G.     BW     Percentage OPUn variance (GR before IR)
    0001     SAP A.G.     DQ     Exceed amount: quantity variance
    0001     SAP A.G.     KW     Var. from condition value
    0001     SAP A.G.     PP     Price variance
    0001     SAP A.G.     PS     Price variance: estimated price
    0001     SAP A.G.     ST     Date variance (value x days)
    0001     SAP A.G.     VP     Moving average price variance
    Best Regards
    Ashish Jain

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

    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

    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

  • Tolerance limits in Purchase Requisition and Purchase Order

    Hi there
    I see there is some new functionality in ERP6 to control the price difference between the requisition and the order.  According to the documentation one needs to set up a tolerance key and then set the tolerance limits for price price variance.  Thereafter one needs to set the tolerance key on the document type.  I have looked in the document type and I can't seem to find any place in the config to set up or assign the tolerance key to it.  Has anyone tried this and how would I assign the tolerance key to the document type?
    Thanks
    Vinesh

    Aroop thanks for your reply.
    My scenario is not the same as in 3rd party processing. In fact my scenario is make to order and even repairs of other companies machinery. Now what we are trying to achieve is lets say in the repair or in production of the customers machinery or service, MM needs to make a purchase for a part or tool etc. That in itself has a price. Meaning our purchase mm dept has to pay the vendor for the purchase made and in return we need to charge our customer for that purchase. So we would like for the price of the purchase order come in our sales order condition type as a surcharge.
    We were able to fetch the price of the production order automatically thru condition type EK02.
    We would like to do the same from purchase order.

  • Tolerance limits in Invoice Varification

    Hi All
    In Std SAP how to set the tolerance limits for Invoice Varification.
    On what are all different parameters can i set these tolerence limits ?
    That is in MIRO we do enter different values at Header level( Amout in basic data & Unplanned delivery cost) and at item level (Amount in PO reference, G/L a/c ,Material tabs)
    Is it possible to set the toleremce limits for each of the above said values?
    Pls advise..
    With Regds

    Hi BSA
    U can set tolerance limit in customization for following
    Amount for item without order reference
    Amount for item with order reference
    Form small differences automatically
    Percentage OPUn variance (IR before GR)
    Percentage OPUn variance (GR before IR)
    Exceed amount: quantity variance
    Quantity variance when GR qty = zero
    Var. from condition value
    Amount of blanket purchase order
    Blanket PO time limit exceeded
    Price variance
    Price variance: estimated price
    Date variance (value x days)
    Moving average price variance
    Path
    Spro>MM>LIV>Invoice Block>Set Tolerance Limits
    Vishal...

  • PO tax and tolerance limits

    Hello everyone,
                  I have 2 questions. I m configuring for the purchasing process of no capital goods for a japanese company.
    1) They have 4 tax codes. They will be using 1 for 80% invoices and they also want to be able to change and put tax codes. How can i configure for this. Since no inventory or material accounts are invloved in the process, the PO items will not take tax directly. I need to default one tax code but also give them the ability to change tax code. so in the process of invoice verification, the tax is correctly taken. They already do invoicing (F-43) so some tax configuration exists but now I have to take it in purchasing cycle. Please help me with the tax configuration for POs.
    2) I have to define additional tolerance key for Tcode  OMR6. I have used AP and given % tolerance limit but the currency there in is JPY. The client wants the similar tolerance for invoices in USD. Please tell me where I can configure additional tolerance key for defining tolerance in USD (for invoices from US)
    Any help will be appreciated.
    Thanks,
    Pooja.

    Hi Vinay ,
    Ecee + TDS for PO maintained @TAX code level ? get the Condition numer from EKKO/PO and get tax details from KONV /KONP.
    Please ref. my postings on the same issue.
    Regards
    Prabhu

  • Set Tolerance Limits

    In this step, you 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:
    u2022     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.
    u2022     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.
    u2022     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.
    u2022     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.
    u2022     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.
    u2022     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.
    u2022     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.
    u2022     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).
    u2022     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.
    u2022     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.
    u2022     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).
    u2022     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).
    u2022     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.
    u2022     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.
    Activities
    Configure the tolerance limits for the individual tolerance keys.
                 Lower limit             Upper limit
                 Absolute    Percentage  Absolute    Percentage
    AN          -           -           X           -
    AP          -           -           X           -
    BD          X           -           X           -
    BR          -           X           -           X
    BW          -           X           -           X
    DQ          -           -           X           -
    DW          -           -           X           -
    KW          X           X           X           X
    LA          -           -           X           X
    LD          X           -           X           -
    PP          X           X           X           X
    PS          X           X           X           X
    ST          -           -           X           -
    VP          -           X           -           X

    1) "Powered by Jive Software" ....
    2) 我看看有没有机会通过什么渠道反映这个问题..

  • Invoice block due to tolerance limit

    Hello,
    I have created a PO for 600 DKK.
    I have created an invoice for 610 DKK and want to do the invoice verification in MIRO.
    The invoice gets blocked.
    Which tolerance limit is causing this?
    I have specified tolerance limits in transaction OMR6:
    1) PP (price variance): + 5% - 5% +15 DKK - 15 DKK
    2) KW (Var. from condition): +2% -2/ - -
    My 10 DKK difference between the PO & invoice lies between these tolerances.
    Are there any other tolerances to be fixed?
    Thank you for sharing your experience.
    Kind regards,
    Linda

    Hi,
    Stochastically blocked meaning that the invoice was blocked due to a payment block set at random in the document header. For each company code, we can define the degree of probability that an invoice will be stochastically blocked. In IMG setting, We mention Threshold value and the Percentage probability for our Company code.
    The degree of probability depends on the invoice value. If our Invoice value is the same or larger than the threshold value, the degree of probability is the same as the percentage probability maitained. If the invoice value is smaller, the degree of probability is calculated in proportion to the threshold value.
    Example
    Threshold value: 3000 percentage: 60
    Invoice value Degree of probability of a block
    3000 60 %
    5000 60 %
    1500 30 % (= 60 * 1500/3000)
    100 2 % (= 60 *  100/3000)

  • Purchase Order - tolerance key SE for price variance

    Dear folks,
    In the purchase order config for tolerance limit, there is a setting for tolerance key SE.
    The SAP help defines that this limit is triggered with system message no. 231. This is a warning message, which appears when the specified cash discount percentage exceeds the predefined tolerances.
    Can anyone advice me where do I specify which cash discount or what discounts will trigger this warning messages?
    Also, is it comparing the discount % against the % in the config or against the discount value from the PO price?
    Best Regards
    Junwen

    Dear Folks,
    To clarify, I meant how do I trigger this tolerance limit SE?
    Which discounts will trigger this limit?
    If I add new discounts or delivery conditions like Freight, will it be subjected to this check?
    This setting is set in the SPRO in Purchase Orders setting together with the tolerance key PE. PE will be triggered in the purchase order when the price in the PO is lower or higher than the tolerance limit when compared to the material price.
    Thus, I think SE will be triggered in the PO also, but how?
    Best Regards
    Junwen
    Edited by: Junwen Huang on Jun 11, 2008 10:12 AM

  • If payment differcence exeeds tolerance limits

    Dear experts
    can u help me in one problem as
    i created vendor invoice Rs 1000/ there is no open items for this vendor except this invoice line
    NOW i am going to vendor payment F-53. Rs 1500. this customer having 1% discount ok . in this condition what is the remaing amount Rs 510 should shown as open item as over due ok it is correct or not ?
    but i could't able to simulate it . i got warning as payment difference is too long.
    when i created this vendor i given payment difference at customer tolerance level and user level as Rs 100 and 1%
    but what i need , when i doing vendor payment ,what is exeed of tolerance limites in payment difference ( Rs 510 ) that amount should shown as another open line item
    is it possible?
    i am waiting for ur reply
    Regards
    Rams

    Hi,
    This the first time i cameacross like this situation.
    You book a invoice for 1000 as you said. And you want to give some discount assume 10/-. see when u book a invoice you will get discount. that is profit to you. so the you have to pay vendor 990.
    Now u want to make a payment for the open item. and you want to clear the open item with 1500. that means extra 510. See in generally when the invoice amount is high whereas payment amount is low then we go for partial and if any discount and other charges is there we go for residual clearing.
    I think the scenario what you are said is really not be happen. if not please tell me the details i want to know what kind of situation it is
    Hope what ever the information specified above is cleared any doubt revert me
    Regards,
    Sankar

  • Condition based maintenance

    Hi Gurus,
    As per my business needs
    Measuring document needs to be updated automatically from proleit (Another system) by IDOC-Pls let me know from our PM end what we have to do?
    Condition based maintenance (As per proleit system measuring document would be updated and determine the condition for automatic notification creation)-Pls suggest how to map the both scenario. if possible pls send the relative documents

    Hi,
         You will have to activate User exit IMRC001  -This gets triggered when measuring document is posted via IK11
    You will have to create a measureing point for the eqpt ..
    In the above user exit you can find sample code which would be helpful
    In config spro ->pm - basic settings -->measuring points & counters  ->Define Measuring point categories, here for a category mention the Tolerance period , if there is any ..
    regards
    giri

  • Tolerance report by PO

    Hi,
    Is there a report which give PO wise material tolerance value  and PO amout with including taxes, etc...
    Thanks
    JENA J

    Hi
    to developed report check following table
    EKKO =header table
    EKPO =Po item table
    In EKKO , take the field EKKO-KNUMV (doc condition) , Pass this field to KONP table. in KONV table, in KONV you will get the itemwise details of Conditions maintained in PO
    Regards
    kailas Ugale

Maybe you are looking for

  • Unable to view .asp web images in firefox

    Hi I am unable Unable to view .asp web images in firefox.... When i am trying to open (intranet site) asp page in linux-firefox it gives an error "This site is best viewed in Microsoft Internet Explorer " Regards ~Atul

  • How make web site in dreamweaver

    hello dear, i am new in site making, so i wanna know how u make site in dreamweaver. tell me the site from where i can get all info regarding this... nancy

  • Itunes 10.4.1 is running my cpu at 100%

    I have an HP running windows XP and ever since I downloaded the new version of iTunes I have not been able to sync my iPhones or access the iTunes store. It runs my CPU up to 100% usage. AppleMobileMeDevices and ITunesexe are hogging up 50% each and

  • Multiple SDM for single WAS instance

    Can I have 2 SDM for a single WAS instance ?

  • Error in dutch translation

    On the Help-tips of all modules the navigation "Next" and "Back" is translated as "Volgende" (correct) and "Achterzijde" (wrong ! ....should be "Vorige"). "Achterzijde"  means for instance: the backside of a house.