Amount check tolerances

Hello
Why SAP has provided two settings for price variances
1. One at OMR6
2. In the same tree path, ITEM AMOUNT CHECK
When we use item amount check and when we use OMR6 ???
Please give exmaple if possible.
Thanks & Regards

Hi
Item amount check - U can define a particular amount in the customising. if ant invoice coming over and above the amount, the invoice will get blocked automatically.
Tolerance - Can be of AN, AP,BD, BR, BW,DQ, DW, KW,PP,PS, ST,VP
These are mainatianed at the company cod elevel, based on the limitis it will allow or block the invoice.
Regards,
Raman

Similar Messages

Diff between Item Amount Check and Stochastic Block

Hi,
what's the diff between Item Amount Check and Stochastic Block in LIV??

Item Amount Check
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.
Stochastic Block
You can block all invoices to check them again through Stochastic block automatically. If the stochastic block is active and you post an invoice that is not subject to any other blocking reason, it can be selected for blocking.
Please make a note that- A stochastic block is not set at item level, but for the whole invoice. If a stochastic block is set when you post the invoice, the system automatically sets an R in the field Payment block in the document header data; there is no blocking indicator in the individual items.
In Customizing for Invoice Verification, you can define:
-If stochastic blocking is active
-The degree of probability of a block. You set a threshold value and a percentage for this.
If you enter a threshold value of zero and a percentage of 99.9%, all invoices would then be blocked automatically.

Vendor Amount Checking and posting

Hi Friends,
    Here ,I am using this function module for checking the vendor amount. BAPI_ACC_DOCUMENT_CHECK
I am passing below data
Header Data
OBJ_SYS     C     10
BUS_ACT     C     4      RFBU
USERNAME     C     12      ABAP16
HEADER_TXT     C     25
COMP_CODE     C     4      H
DOC_DATE     D     8      20060217
PSTNG_DATE     D     8      20060217
TRANS_DATE     D     8      00000000
FISC_YEAR     N     4      2006
FIS_PERIOD     N     2      00
DOC_TYPE     C     2      SA
REF_DOC_NO     C     16      TEST
ACCOUNT GL
0000000001|0002110113|
ACCOUNT PAYBLE
ITEMNO_ACC     N     10      0000000002
VENDOR_NO     C     10      EPAY1
SECTIONCODE     C     4      B004
ACCOUNT TAX
ITEMNO_ACC     N     10      0000000001
GL_ACCOUNT     C     10      0001430524
COND_KEY     C     4      JIN2
ACCT_KEY     C     3      MW3
TAX_CODE     C     2      AR
TAX_RATE     P     4         0.000
TAX_DATE     D     8      00000000
TAXJURCODE     C     15
TAXJURCODE_DEEP     C     15
TAXJURCODE_LEVEL     C     1
ITEMNO_TAX     N     6      000000
ITEMNO_ACC     N     10      0000000002
GL_ACCOUNT     C     10      0001430524
COND_KEY     C     4      JIN6
ACCT_KEY     C     3      JN6
TAX_CODE     C     2      AR
TAX_RATE     P     4         4.000
TAX_DATE     D     8      00000000
TAXJURCODE     C     15
TAXJURCODE_DEEP     C     15
TAXJURCODE_LEVEL     C     1
ITEMNO_TAX     N     6      000000
CURRENCY AMOUNT
ITEMNO_ACC     N     10      0000000002
CURR_TYPE     C     2
CURRENCY     C     5      INR
CURRENCY_ISO     C     3
AMT_DOCCUR     P     12                        753.85-
EXCH_RATE     P     5         0.00000
EXCH_RATE_V     P     5         0.00000
AMT_BASE     P     12                        756.00
DISC_BASE     P     12                        0.0000
DISC_AMT     P     12                        0.0000
ITEMNO_ACC     N     10      0000000001
CURR_TYPE     C     2
CURRENCY     C     5      INR
CURRENCY_ISO     C     3
AMT_DOCCUR     P     12                        753.8500
EXCH_RATE     P     5         0.00000
EXCH_RATE_V     P     5         0.00000
AMT_BASE     P     12                        0.0000
DISC_BASE     P     12                        756.0000
DISC_AMT     P     12                        0.0000
cretir
0000000001|BUKRS                         |H                               |
0000000001|KNDNR                         |ICIEL                           |
0000000001|ARTNR                         |DDTEST-OWN                      |
0000000001|VKORG                         |HLL                             |
0000000001|VTWEG                         |ST                              |
account tax
0000000001|0001430524|JIN2    |MW3     |AR      |   0.000 |00000000       |
0000000002|0001430524|JIN6    |JN6     |AR      |   4.000 |00000000       |
I am getting error Balance in transation currency.
Thanks & Regards,
Narayana Rao.

Hi Rob,
I'm having a similar problem to this issue, in my currencyamount table the balance amounts to Zero, which mean the document is ready to post. but i get this error 'balance in transaction curcy'.
Any idea what could be my mistake?
Thanks in advance.
Vinod

Invoice amount-tds amount=check amount discoverer report

Hi,
In ap_invoice_payments_all table AMOUNT column -Ve ,+Ve amounts are coming in one column how to get the saperate columns in discoverer.
EX:-Invoice amount(1000)-tds amount(200)=check amount(800)

Hi phani,
AMOUNT column -Ve ,+Ve amounts are coming Here tds amount is nothing but the tax deducted source,which will be applicable at the inovice level.For example the TDS amount will be applicable to that supplier where he has raised credit memo and there will be say 2% of tax deductable from the invoice amount of 100 then
100(invoice amount)-20(tds)=80(payment amount).
You can find this,i mean it will be described as a descriptive flex field in ap_invoice_distributions_all .
Spliting can be done through DECODE or CASE
Hope this helps you.
Best Wishes,
Kranthi.
Edited by: Kranthi.K on Jun 19, 2009 4:27 AM

Trouble trying to get correct AP Check Amount total on a report

Okay, the challenge is to try and explain my situation well. I am in Discoverer Plus. I am working to develop a Discoverer report that will show, for accounts payable application, a summary report by bank name and job number, a check count, invoice count, and check amount total. For simplicity sake, since I have the problem once I go past one table, I am dealilng with tables ap_checks_all and ap_invoice_payments_all from EBS, the tables joined on check id. Now, if I work just with the ap_checks_all table, I can easily get the correct sum of check amounts (column name in the table is AMOUNT). However when I bring in the invoice payments table, then I run into trouble. I first did the SUM data point for AMOUNT, and got a number that was way too high. Figured out that is because anytime I have multiple invoices on a check (which is most of the time), the check amount gets added in for each invoice. So if check amount is $100.00 and the check pays 5 invoices, $500.00 is added to the total amount, instead of the just the $100.00.
So I tried the SUM_DISTINCT function next - SUM_DISTINCT(AMOUNT). Got me a lot closer, but now my total was too low. Figured out that was because if I had separate checks with the same check amount, that check amount only gets added in one time. Say Check 18 is for $100.00 and Check 39 is for $100.00, I only get $100.00 into the total instead of $200.00. Which when you think about it, is exactly what the SUM_DISTINCT function means. Since the chances of check amounts being duplicated are low, that is why I get close to the right number, but when dealing with tens of thousands of checks, check amount duplication does happen.
So on my totals for the SUM_DISTINCT column, I finally figured out that a CELL SUM got me closer to the right number. I only had a problem now when, on the same bank name and job number, would still have duplicate check amounts at that key (group by) status level. Percentage wise, my error is low - off maybe $200,000 out of $180,000,000. So close to the right number, yet so far.
The same thing happens in raw SQL. If you think about the raw join result, you can see what is happening -
check 1, check 1 amount, invoice 1
check 1, check 1 amount, invoice 2
check 2, check 2 amount, invoice 3
check 3, check 3 amount, invoice 4
So if you do SUM(CHECK AMOUNT), well yeah, it will add in the check 1 amount twice.
If you do SUM_DISTINCT(CHECK AMOUNT), then check 1 amount only gets counted once. Great. Ahh, but what if check 3 amount = check 1 amount? Oops, the check 3 amount is excluded.
Does anyone know of a way to get around this problem? I have been playing around with the functions, but the SQL reference does not give many examples to help understand all the various optional parameters. I know, in vague concept, what I want. Something like -
SUM(AMOUNT) DISTINCT ON CHECK_ID, or
SUM_DISTINCT(AMOUNT) DISTINCT ON CHECK_ID.
CHECK_ID is the internal Oracle id number for each check, from the ap_checks_all table. Check number is not unique enough, since different bank accounts may be using the same check number in the same time period. So I want a way to be able to add my check amount to the total one time when there are multiple invoices on the check, and then get each invidual check amount (one time) added up to get my check total amount.
Like I said, no problems with Discoverer or raw SQL if doing just one table. But once I join checks to invoice payments, poof, I run into trouble.
I did not think I was trying to do anything unusual. So quite surprising that having so much trouble trying to find a way around this problem.
Hope this detail explanation makes some sense. Thanks for any help/insight anyone can give me.
John Dickey

Michael,
Nope, that does not work. It truly just gives me an average. My desired (table) report row format is this -
Bank name , Job Number, Check Count , Invoice Count , Check Amount Total
So this is a SUMMARY report. Not a detail report. If I do detail, I do not have any problems - I get my correct check amount total. If I do just the ap_checks_all table, I get the correct amount (but then cannot get my invoice count). I get the correct check count (count distinct on check id). I get the correct invoice count. When I added a calculation column using the Average function as you suggested, I see on each row what is likely the average check amount. Which is exactly what you would expect to see.
Now I did get a brainstorm and tried this. I calculated both the average and average distinct on check amount, then multiplied each by my check count. Darn. Still does not work. The Average Distinct * Check Count = SUM_DISTINCT(CHECK AMOUNT), which I already have. Average Distinct apparently only includes a duplicate check amount one time in calculating the average (which when you think about it, makes sense, darn it). The AVERAGE function still has the problem, it looks like, of including the check amount each time on checks with multiple invoices (and thus multiple rows in the join result) in determining the average. Which when you think about the raw join result from joining checks to invoice payments tables, makes sense. The result of AVERAGE * CHECK COUNT is better than the SUM(AMOUNT) column, but not as good as the SUM_DISTINCT(AMOUNT) column.
Any other ideas? Interesting that something that seems like a pretty basic thing to do, if it does have a solution, is not a very obvious/simple solution.
John Dickey

Regarding tolerance checks in MIRO

Hi Experts,
We have a requirement to check tolerance checks for Unplanned delivery costs. We need to raise a error message for not allowing the tolerance cheks which are more than 5% for Unplanned delivery cost. Please suggest me the user exit or badi to achieve the same. We have used the user exit MM08R002 but it does not work for Unplanned delivery costs.
Waiting for the reply.
Best Regards,
Amar.

Check badi's "MRM_TOLERANCE_GROUP" & "MRM_RELEASE_CHECK"
Regards
Vinod

PO Tolerance Limit

Hi ,
We have a problem with processing our PO ' s.
For a PO , we have the GR posted , howevre the IR is not getting posted. And this process is automated ( through IDOCS ).
When we analysed the issue, found out that the reason it is not posting is because of this :
" Because there is a diffrenece between the Debits and Credits ( that is the GR and IR Amount ) Say the GR is 500 $ and IR is 600 $ , the system is not posting as the difference is beyond the tolerance limit " ..
So how do i change the Tolerance limits for the POs so the IR posting takes place...
And why does the IR value be greater thatn GR ? If i want to see at what value the IR will post..where can i see that ?
Thanks for any help...
srikanth.

Dear,
There are various tolerance keys are coded in the standard SAP program, few of the example...
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.
Likewise other tolerance keys used by program are BD,BR,BW,DQ,DW,KW,LA,LD,PPPS,ST,VP
These keys are determined by stadard functionality.
Regards,
Chintan Joshi

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 the invoice creation

Hi,
I am not able to create invoice using BAPI function module.
I am getting the error 'Maintain tolerance limits for tolerance key BD (Company Code 1007)'.
What are the tolerance limits and How can I maintain these.
Can anyone please help me to solve this problem.
Thanks in advance.
Regards,
Eswar

Dear Eswar,
For invoices without reference to a PO or those with reference to PO,in customizing for Material Management under
Logistic Invoice verification: Invoicing Block: Set tolerance limit, You can set diffrence tolerance limit for each company code.
If you enter an item with a large amount it make sense to often block this invoice in order to check.For this for each co. code
Path: SPRO : LIV : Invoice Block: Item amount check :Activate item amount check.
In addition to above
Path: SPRO : LIV : Invoice Block: Item amount check :Set item amount check.
I hope this will help you.If so reward points
Vivek Maitra

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) 我看看有没有机会通过什么渠道反映这个问题..

Tolerance Upper & Lower limit in MIRO

Dear All,
my scenario is when i am doing MIRO that Vendor bill amount is 1000/- & SAP Amount 990 so i want set tolerance for upper limit 10/- rupees & lower limit for 100/- rupees.
is it possible & please suggest me what can i do.?
Thanks
Sachin Deshmukh

Hi,
As per your suggestion i hvae set Activate item Amount check tick For Company Code. After that i set tol key PP for upper 10val & lower 100Val.
after i create new MIRO & check my scenario but it is not working. its working only lower limit & it shows Warning message.
its my company csenario.
please help me.
Thanks

F.13 Include tolerances

Please advise where we define tolerance amount considered by system when clearing in F.13 with include tolerance selected. That from where system is getting include tolerance amount value
Thanks for the help

Hi,
Activate check box include tolerances if you want system to check tolerances while clearing accounts.
The tolerances will be maintained in T.Codes as below.
GL                  -   OBA0
Vendor/Cust -   OBA3
Employee       -   OBA4
Regards,
Raj

Invoice Tolerance

I am trying to set invoice tolerance limits for price variance in both value and percentage terms. I did config for it in OMR6 but it doesnt block the invoice.
Is there some place else also where we can set the tolerance limits.
Thanks

Hi,
OMR6 maintainace define whether to allow posting or not it will block the invoice. To do so go to path SPRO>Materials Management>Logistics Invoice Verification>Invoice BlockI>tem Amount Check>Activate Item Amount Check and
select Check item amount.
now it block invoice.
Regards,
Chintan Joshi.

Line item Tolerance

Gurus,
Is it possible to set tolerance line item wise in MIRO

These are the possibe tolerancs can be maintained for a invoice
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.

Tolerance for LIV

I have a question with reference to following tolerances:
1- Tolerance key "PE" set at upper limit of 10%
2- Vendor specific tolerance set @ Auto accept + diff $ 5
                                                   Absolute upper limit $ 50
                                                   % upper limit 2%
Invoice block-
3- Small diff key "BD" $25
4- Price variance Absolute upper limit $ 5
                           % upper limit 5%
How will these tolerances work- the order? what comes first? which key supersedes the other and in what order?
In short I am trying to figure out is that the system looks at all of these 4 keys at the same time or does it look at any other way?
need help- is there any specific documentation I should look at?
Thanks
Raj

Hello
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 BW 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.
Regards

Amount check tolerances

Similar Messages

Maybe you are looking for