You are on page 1of 35

Get Started

Solutions

Support
Training
Community

Developer

Partner

About

Community / Blogs
Invoice Tolerance Keys An insight Part 1
April 18, 2014 | 681 Views |

Raja Ramasamy
more by this author
MM (Materials Management)
3way matchinvoice blockinvoice verification;rbkp blockedspgrpthree way matchtolerance
limittolerancekey
Follow

In this blog I am going to share the invoice tolerance limits learning and understanding
which would help to understand invoice blocking techniques and provide a base to
apply in real time situations depending on the clients need.
This document will help consultant who is going to implement Open Text Vendor Invoice
Management (VIM)

Please refer Part-2 for remaining tolerance keys

Introduction:
In the Procure to Pay(P2P) life cycle procurement part ends when Account Payable(AP)
processor/Invoice clerk posts the vendor invoice in SAP using MIRO transaction which
is also called Logistics Invoice Verification(LIV). It is tedious job for invoice clerk
manually to verify each and every invoice line item is conforming to agreed price or
quantity in PO. SAP provides systemic way of verifying this kind of discrepancies and
block the invoice for payment using the 2 digit key called Tolerance key.
Lower & upper tolerance limits for all possible discrepancies can be maintained in
tolerance key. I would try to explain all the invoice tolerance keys in this blog with
possible examples.
There are 2 kinds of invoice matching in SAP which are controlled by tolerance keys.

o 3 way match:

Invoice line item is checked against corresponding purchase order and good
receipt documents item for price & quantity matching
o 2 way match:

Invoice is checked against only to PO price/qty if there is no goods receipt


planned

Let us understand the how the automatic block is working via tolerance keys. In SAP we
have many tolerance keys, I am going to discuss only below keys in this part
AN,AP,BD,BR,BW,DQ,DW.
Tolerance Limits:

SAP tolerance limits work only for MIRO transaction


Invoice posted in FB60 is not subject to tolerance keys limit check
Tax amount is not included during tolerance check
It is stored in table T169G

Invoice blocking ways:


In SAP vendor invoice can be blocked for payment by anyone of the following way.

1. Automatic block:

Only if there is a discrepancy due to price or quantity or date variance in an invoice.


If the item amount is exceeded from the limit maintained in the tolerance key.
2.Manual block:
Invoice processor could manually block an invoice either at item level or header level
3.Blocking through payment term:
Invoice can be blocked always with a particular payment term even if there is no
variance
4.Stochastic blocking:
Random blocking of invoices without any variance
5.Blocking at vendor master level:
Invoice can be blocked always for a particular vendor if specific blocking key is
maintained at vendor master level
Blocking indicators:
Blocking indicators are available both at header and item level of invoice document.
System set this indicator in the document wherever and whenever it is appropriate.
Header level:
Table: RBKP_BLOCKED Field: MRM_ZLSPR
Possible values:

A Automatically blocked due to existence of blocking reasons

S Stochastically blocked

M Manual payment block set in header no blocking reasons

W Automatically blocked due to entry via Web Invoice

Item level:
Table: RSEG Value = X
Fields:

SPGRP Blocking reason price

SPGRM Blocking reason quantity

SPGRT Blocking reason date

SPGRG Blocking reason OPQ

SPGRV Blocking reason Project

SPGRQ Manual blocking reason

SPGRS Blocking reason amount

SPGRC Blocking reason: Quality

1.AN Amount for an item without order reference


Definition:
System checks every line item in an invoice with no order reference against the
absolute upper limit defined.
Without order reference means direct posting to G/L or Material.
System behavior:
If only the invoice line item is greater than absolute upper limit the invoice would be
blocked.
Let us understand with below example.

It updates RBKP table without a header Block R. But updates table RBKP_BLOCKED
with payment block A.
No entries in RSEG table as it is directly posted to G/L or Material
Tolerance Key RBKP RBKP_BLOCKED RSEG Auto release

AN No blocking indicator A- Auto block No update Not possible

update(ZLSPR) (item amount block)

2.AP Amount for an item with order reference


Definition:
System checks every line item in an invoice with order reference against the absolute
upper limit defined.
Pre-requisite:

Item amount check must be activated at company code level OMRH


Item amount check must allowed for item category and GR indicator OMRI

System behavior:
Let us understand with below example
No blocking indicator at header table RBKP but RBKP_BLOCKED table has blocking
indicator A.
Blocking indicator RSEG- SPGRS (Blocking reason item amount) is set at item level.
Item amount block must be released manually. There is no automatic release possible
even if we perform any one of the following activities

Post subsequent credit


Adjust AP tolerance limit

Tolerance Key RBKP RBKP_BLOCKED RSEG Auto release

AP No blocking A-Auto block RSEG- Not possible

indicator SPGRS = X

update(ZLSPR) (item amount

block)

3.BD Form small differences automatically


Definition:
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
System behavior:
Let us understand with below example
Small difference within tolerance limit:
As per the PO reference the invoice amount is 1000 USD.
But vendor actual invoice copy has amount of 1002 USD.
AP invoice processor enters the invoice amount as per the vendors invoice copy which
is 2 USD higher than PO price.

Since small difference is within the tolerance limit, invoice would be posted without
block. Small difference amount would be debited to small difference G/L account
maintained for the transaction event key DIF in OBYC.
Same rule is applied in the lower side as well
Small difference above the tolerance limit:
PO price: 1000 USD
Vendor invoice amount: 1003 USD
If the small difference above the tolerance limit then system would not allow to post the
invoice with hard error Balance is not zero. Still AP invoice processor could able to
post invoice via menu bar option Edit -> Accept and Post provided if he/she has
authorization object M_RECH_AKZ allowed.

If we post with above option then system would behave as below.

o Invoice will be posted without block


o Small difference G/L account (DIF) get posted
o RBKP MAKZN (net amount accepted manually) field will get updated with small
diff. amount : 3.00
Tolerance Tolerance RBKP RBKP_BLOCKED RSEG Auto

Key release

BD Within No blocking No update No NA

range indicator blocking

update(ZLSPR) reason

update

BD Above No blocking No update No NA

indicator blocking

update(ZLSPR) reason

MAKZN field update

updated with

diff. amount

4.BR: Percentage OPUn variance (IR before GR)


Definition:
The system calculates the percentage variance using below formula and compares the
variance with the upper and lower percentage tolerance limits.

Pre-requisite to simulate this scenario:

1. No GR based IV
2. Variable order unit is activated at material level
3. Maintain tolerance key DW with Do not check active

Tolerance:

Material master:

CRT is maintained as order unit


EA is maintained as order price unit in info record 1 EA = 100 USD
PO Details:
PO has been created with CRT as Order unit and EA as Order price unit
Po quantity: 2 CRT = 24 EA

Invoice details:
Invoice is simulated before GR as below
Scenario 1:
Order unit quantity 2 CRT
Order price unit quantity 22 EA and amount 2200 USD
Observation: There is no warning message on the variance.
Let us use the above formula to find the variance percentage.

Difference is 100 91.6 = 8.9 % which is within the BR tolerance limit 10% maintained
Scenario 2:
Order unit quantity 2 CRT
Order price unit quantity 21 EA and amount 2100 USD

Observation: There is a warning message as below.

Let us use the above formula to find the variance percentage.

Difference is 100 87.5 = 12.5 % which is more than the BR tolerance lower limit 10%.
Hence we are seeing the above warning message which will block the invoice for
payment.

Tolerance Key RBKP RBKP_BLOCKED RSEG Auto release

BR No blocking A- Auto block RSEG- Not possible

indicator SPGRS = X

update(ZLSPR) (item amount

block)

5.BW: Percentage OPUn variance (GR before IR)


Definition:
The system calculates the percentage variance using below formula and compares the
variance with the upper and lower percentage tolerance limits.
Let us understand with same master data
PO Details:
PO quantity in order unit 2 CRT
Po quantity in order price unit 24 EA
GR Details:
GR quantity in order unit 2 CRT
GR quantity in order price unit 22 EA

IR Details:
Scenario 1:
IR quantity in order unit 2 CRT
IR quantity in order price unit 20 EA
Observation: There is no warning message on the variance.
Variance % = (20/2) / (22/2) *100
= 90.9%
Difference is 100 90.9 = 9.1 % which is within the BR tolerance limit 10% maintained
Scenario 2:
IR quantity in order unit 2 CRT
IR quantity in order price unit 19 EA
Observation: There is a warning message as below

Variance % = (19/2) / (22/2) *100


= 86.4%
Difference is 100 86.4 = 13.6 % which is more than the BR tolerance limit 10% and
invoice posted with payment block.

Tolerance Key RBKP RBKP_BLOCKED RSEG Auto release

BR No blocking A- Auto block RSEG- Not possible


indicator SPGRS = X

update(ZLSPR) (item amount

block)

6.DQ: Exceed amount: quantity variance


This tolerance key has both absolute and percentage limits.
Definition:
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)).
System behavior:
Absolute limits:
Let us see the system behavior if only absolute values are maintained and percentage
limits are marked as Do not check.
Upper limit: 100.00 Lower limit: 100.00
Test data :- (GR has been defined)
PO quantity = 100 EA
PO price = 100 USD
GR quantity = 50 EA
a) System behavior when invoice quantity is 51
Variance = PO price x (quantity invoiced (total quantity delivered total quantity
invoiced))
= 100 * (51 (50-0))
= 100 * (1)
= 100
Variance 100 is equal to upper limit 100 and there will not be any warning message.

b) System behavior when invoice quantity is 52


Variance = PO price x (quantity invoiced (total quantity delivered total quantity
invoiced))
= 100 * (52 (50-0))
= 100 * (2)
= 200
Variance 200 is more than upper limit 100 and there will be a warning message as
below.

When we post invoice with above variance it will get blocked for payment.
It updates tables as below

Tolerance Key RBKP RBKP_BLOCKED RSEG Auto release

DQ No blocking A- Auto block RSEG- SPGRM Yes

indicator update =X

(ZLSPR) (Quantity block

Automatic release possible if the blocking reason RSEG- SPGRM is deleted when we
post GRN for the balance quantity or credit memo for the excess invoiced quantity.
Same rules apply on the lower side as well
Test data :- (GR has not been defined)
PO quantity = 100 EA
PO price = 100 USD
GR not possible
a)System behavior when invoice quantity is 51
Variance = PO price x (quantity invoiced (total quantity ordered total quantity
invoiced))
= 100 * (51 (50-0))
= 100 * (1)
= 100
Variance 100 is equal to upper limit 100 and there will not be any warning message.

b)System behavior when invoice quantity is 52


Variance = PO price x (quantity invoiced (total quantity ordered total quantity
invoiced))
= 100 * (52 (50-0))
= 100 * (2)
= 200
Variance 200 is more than upper limit 100 and there will be a warning message as
below. Invoice will be blocked for payment and same tables will be updated as above.

Percentage limits:
We 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.
Let us see the system behavior with same example if only percentage limits are
maintained and absolute values are marked as Do not check.
Upper % limit: 10.00 Lower % limit: 10.00
Test data :- (GR has been defined)
PO quantity = 100 EA
PO price = 100 USD
GR quantity = 50 EA
a)System behavior when invoice quantity is 55
Variance = (quantity invoiced total quantity delivered)/ (quantity expected)*100 %
= (55-50)/50 * 100 %
= (5/50)*100 %
= 10 %
Variance 10% is equal to upper limit 10 % and there will not be any warning
message.
b)System behavior when invoice quantity is 56
Variance = (quantity invoiced total quantity delivered)/ (quantity expected)*100 %
= (56-50)/50 * 100 %
= (6/50)*100 %
= 12 %
Variance 12% is more than upper limit 10% and there will be a warning message as
below. Invoice will be blocked for payment and same tables will be updated as above.

Both Variances active:


If both absolute & percentage variance are active the system would block which ever
tolerance is first breached.
Quantity check for Delivery cost:
The system also carries out a quantity variance check for planned delivery costs when
we post only planned delivery cost.
Tolerance key not maintained:
If the tolerance key DQ is not maintained for a company code when we perform the
same transactions discussed earlier, system considers this as zero tolerance and block
the invoice for the payment for any deviation.
7.DW: Quantity variance when GR quantity = zero
Definition:
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.
System behavior:
This tolerance key works only for PO based invoice verification because GR based
invoice verification will not allow IR without GR.
DW absolute upper limit as 100:
PO quantity = 100 EA
PO price = 10 USD
No GRN posted
a)If the IR quantity is 10 then system calculates variance as below
Variance = Net order price * (quantity invoiced + total quantity invoiced so far)
= 10 *(10+0) = 100
This value is equal to DW limit hence there is no warning message and system will
not block the invoice.

b)If the IR quantity is 11 then system calculates variance as below and block the
invoice.
Variance = 10 *(11+0) = 110

This value is more than DW tolerance absolute upper limit hence invoice got blocked.
It updates tables as below
Tolerance Key RBKP RBKP_BLOCKED RSEG Auto release

DW No blocking indicator A- Auto block RSEG- SPGRM = X Yes

update (ZLSPR) (Quantity block )

Automatic release possible if the blocking reason RSEG- SPGRM is deleted when we
post GRN for the balance quantity or credit memo for the excess invoiced quantity
DW absolute upper limit as Do not check:
PO quantity = 100 EA
PO price = 10 USD
No GRN posted
If the IR quantity is 112 then also system would not block even though this is
beyond the DQ tolerance since it has been maintained as Do not check and there is
no GR has been done.
One should be very careful to use this option as this would by-pass quantity
variance DQ block if there is no GR posted where GR has been planned
DW tolerance key is not maintained:
If this key is not maintained for a company code it would always blocks the invoice for
PO based invoice verification when there is no GR has been posted.
Please refer Part-2 for remaining tolerance keys
Reference:
* SAP IMG documentation

Alert Moderator
20 Comments
You must be Logged on to comment or reply to a post.

1. Raja Ramasamy Post authorApril 18, 2014 at 5:32 pm


Hi All
Appreciate your comments and valuable feedback.
Like (0)

1. Mehmet Ozgur UnalApril 19, 2014 at 10:36 pm


Hi ,

Good effort , i wrote a similiar subject in document M8 messages for incoming invoices with
tolerances

Regards.

M.Ozgur Unal
Like (0)

1. Raja Ramasamy Post authorApril 21, 2014 at 7:13 am


Thanks..
Like (0)

2. Dalapathy SankarJanuary 2, 2015 at 7:28 pm


Nice Blog. Could you please guide me for the below scenario. PO Qty = 100 with unlimited over
delivery check box, GR = 140 Qty. GR checked but No GR based IV, MIRO should post for 140 Qty
by blocking invoice with Tolerance key DQ as 1% (warning message). Currently system is not
checking DQ tolerance as its two way match (PO based invoice) and ignores the tolerance % as its
unlimited delivery check box in PO
Like (0)

2. Sanil BhandariJune 20, 2014 at 10:16 am


Very useful document

Regards
Sanil Bhandari
Like (0)

3. Pravin BakraniaAugust 8, 2014 at 2:17 pm


Hello Raja Ramasamy This is very useful document and would appreciate if you can also post
Part -2 of this Tolerance Keys An Insight I am more interested in examples of KW ST
PP.

Thanks once again !


Like (0)

1. Raja Ramasamy Post authorSeptember 15, 2014 at 10:07 am


Hi Pravin,
Thanks for the feedback , i will publish shortly
Like (0)

2. Raja Ramasamy Post authorDecember 10, 2015 at 6:55 am


Part-2 is published now
Like (0)

4. Danny RousselSeptember 12, 2014 at 8:39 am


very usefull blog, thanks!

I was wandering if we can block an invoice if the received quantity > ordererd quantity.

So we want to do the goods receipt, but the related invoice should get blocked.

Any idea please?

Danny
Like (0)

5. B V YadavSeptember 12, 2014 at 11:10 am


Hi Raja Ramasamy,

Good effort i think you spent more time to prepare this document. Good document and thank for
share value information.
Regards,

BV
Like (0)

6. Alaeddine BDHDecember 31, 2014 at 5:03 pm


hello @Raja Ramasamy,

what about tolerance customizing? how can I set low MAX and MIN level case of company code?

thanks.
Like (0)

7. Dalapathy SankarJanuary 2, 2015 at 7:25 pm


Nice Blog. Could you please guide me for the below scenario.

PO Qty = 100 with unlimited over delivery check box, GR = 140 Qty. GR checked but No GR based
IV, MIRO should post for 140 Qty by blocking invoice with Tolerance key DQ as 1% (warning
message). Currently system is not checking DQ tolerance as its two way match (PO based invoice)
and ignores the tolerance % as its unlimited delivery check box in PO
Like (0)

8. Kishan HJanuary 5, 2015 at 8:53 am


Good one. Whre is part 2?
Like (0)

9. Pratik JadhavMarch 28, 2015 at 2:04 am


Nice Explanation helpful and easy to understand
thanks for this article
Like (0)

10. Gerald BroschMay 4, 2015 at 11:32 am


Hi Raja, this is a very helpful explanation of tolerance keys. I would apreciate very much if you would
deliver the missing 2nd part of your explanations.

Thanks,
Gerald
Like (0)

1. Raja Ramasamy Post authorDecember 10, 2015 at 6:56 am


Part 2 is published now
Like (0)
11. Nagendra mJune 29, 2015 at 10:34 am
Hi Raja,Nice and Very Informative Blog.

Thanks,
Nagendra.
Like (0)

12. Malka SamarasingheOctober 8, 2015 at 9:52 am


very useful document
Like (0)

13. Martin NeethlingNovember 12, 2015 at 6:25 am


One question; I read somewhere once that should you not have defined any tolerances the system
will not allow any price or quantity variance. The purpose of defining invoice tolerances is actually to
make the system less restrictive by turning off this functionality entirely or setting a tolerance to
ensure that not ALL invoices with the slightest variance is blocked. Is this correct?
Like (0)

1. Raja Ramasamy Post authorDecember 2, 2015 at 4:43 am


Yes, You are right. If you dont maintain any tolerance system would not allow to post invoices.
Like (0)
Share & Follow

Privacy
Terms of Use

Legal Disclosure

Copyright

Trademark

Sitemap

Newsletter
Get Started

Solutions

Support
Training
Community

Developer

Partner

About


Community / Blogs

Invoice Tolerance Keys An insight Part 2


December 4, 2015 | 205 Views |

Raja Ramasamy
more by this author

MM (Materials Management)

Follow

Finally here is the part 2 of Invoice Tolerance keys which is the continuation of part 1 .
KW: Variance from condition value
Definition:
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).

System Behavior:
PO Qty = 100 EA
FRB1 = 100 SGD
GRN Qty = 100 EA
IR Qty = 100 EA
Planned delivery cost = 110 SGD
Variance (KW) = 100 * (110/100) = 110 which is 10 SGD more than PO but within the tolerance
hence No warning message.
If planned delivery cost is 111 SGD
Variance (KW) = 100 * (111/100) = 111 which is 11 SGD more than PO value above the tolerance
hence below warning message will be issued and invoice will be blocked for payment.

Tolerance Key RBKP RBKP_BLOCKED RSEG Auto release

KW No blocking indicator A- Auto block RSEG- SPGRP = X NO

update (ZLSPR) (Price block for

Delivery cost line)

LA: Amount of blanket purchase order


Definition:
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.

System Behavior:
PO Limit = 1000 SGD
GR not applicable
IR1 Value = 500 SGD
IR2 Value = 510 SGD system allows without any warning message as the variance = (500
+510)=1010 is compared with PO limit 1000 SGD which is within the tolerance.
If we try to post the invoice for 511 then system would throw below pop-up message. Still we can
post the invoice which will be blocked for payment.

Tolerance Key RBKP RBKP_BLOCKED RSEG Auto release


LA No blocking indicator A- Auto block RSEG- SPGRP = X A. Yes. If we
adjust the
update (ZLSPR) PO overall
limit

LD: Blanket purchase order time limit exceeded


Definition:
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 absolute upper limit defined.

System behavior:
Scenario 1:
PO Validity end date: 03/12/2015
Posting date : 13/12/2015
No warning message because (13-03)= 10 days is within tolerance
Scenario 2:
PO Validity end date: 03/12/2015
Posting date : 14/12/2015
Warning message as below since variance is above tolerance (14-3) = 11 days. It will
be blocked for payment .
Tolerance Key RBKP RBKP_BLOCKED RSEG Auto release

LD No blocking indicator A- Auto block RSEG- SPGRT = X A. Yes. If we


adjust the
update (ZLSPR) PO Validity
end date

PP: Price Variance


Definition:
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).

System behavior:
Scenario 1:
PO Price :100 SGD / Item
PO Qty -:100 EA
PO Total value : 10000 SGD
IR Total amount: 10010 SGD
IR Qty 100 EA
System would allow without any message. Since the variance is (10010 10000) = 10
SGD which is within the tolerance.
Scenario 2:
PO Price :100 SGD / Item
PO Qty -:100 EA
PO Total value : 10000 SGD
IR Total amount: 10011 SGD
IR Qty 100 EA
System would pop-up below message. Since the variance is (10010 10000) = 11 SGD
which is above the tolerance and it will be blocked for payment.

Scenario 3:
Invoice & Subsequent debit:
For the same PO Qty & amount if we do invoice as
IR Qty = 100 EA
IR Value = 10000 SGD
Then
Subsequent debit as
Qty = 100 EA
Value = 10 SGD
No warning message since the variance (already invoiced value+ current subquent
debit value PO amount ) = ( 10000+ 10 10000) = 10 is within tolerance.
If the value is 11 SGD then system would pop-up below message

Tolerance Key RBKP RBKP_BLOCKED RSEG Auto release

PP No blocking indicator A- Auto block RSEG- SPGRP = X A. Yes. If we


adjust the
update (ZLSPR) PO Price

PS: Price variance: estimated price


Definition:
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).

This works same as PP tolerance key when the PO price is


flagged as Estimate price.
Tolerance Key RBKP RBKP_BLOCKED RSEG Auto release

PS No blocking indicator A- Auto block RSEG- SPGRP = X A. Yes. If we


adjust the
update (ZLSPR) PO Price

ST: Date variance (value x days)


Definition:
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

javascript:;
System behavior:
Scenario 1:
PO item value: 100 SGD Per item
PO Qty = 10 EA
PO Value = 1000 SGD
PO Delivery date: 03/12/2015
IR Value = 1000 SGD
IR Qty = 10 EA
Invoice entering date = 02/12/2015
Variance = PO item amount * ( PO delivery date Invoice entry date)
= 100 (3- 2) = 100 *1 = 100 SGD
This is within tolerance hence no warning message.
If we post the invoice on 01/12/2015 then variance would be
= 100(3-1) = 100(2) = 200 SGD
This is above the tolerance limit hence invoice would get blocked for payment.

There wont be any warning message for date discrepancies before


posting the invoice
Tolerance Key RBKP RBKP_BLOCKED RSEG Auto release

ST No blocking indicator A- Auto block RSEG- SPGRT = X A. Yes.

update (ZLSPR)

VP: Moving average price variance


Definition:
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.

System behavior:
Material master MAP price: 100 SGD
PO Price = 100 SGD , Quantity = 10 EA and Value = 1000 SGD
Invoice value = 1060 SGD
New MAP after invoice posting = 1060/10= 106 SGD
Variance = (106 100 )/100 = 6%
Within PP tolerance limit but above the VP tolerance limit.
Below information message will pop-up and Invoice will not be blocked for payment.
Based on this tolerance key we can make the below info message as Warning or error
before posting.

With this I have completed all the tolerance keys relevant for Invoice Posting.

P.S: There is one more tolerance key PC which is used for invoice with reference to Contract which is not covered in this article
due to technical reasons.

Alert Moderator

7 Comments
You must be Logged on to comment or reply to a post.

1. Mehmet Ozgur UnalDecember 10, 2015 at 7:04 am


Nice explained document , i want to add that there is a user-exit to try your defined rules.
EXIT_SAPLMRMC_001
Regards.
M.Ozgur Unal
Like (0)

1. Raja Ramasamy Post authorDecember 11, 2015 at 8:14 am


Thanks for the info
Like (0)

1. Amit RahateDecember 28, 2015 at 6:43 am


Hello Raja,
many thanks for such precise and great content.
I was trying to analyse these for my client but not able locate the table which contains items in
blocked invoices by Tolerance Code. Which table might contain this information?
Many Thanks.
Kind Regards;
Amit Rahate
Like (0)

2. Kavisha DaruFebruary 10, 2016 at 5:21 pm


There is one point you mentioned for DQ Tolerance Key that if it is not mentioned for a company
code, it means a zero tolerance and system would block the invoice for payment if there is any
variance. Does this apply to PP Tolerance Key as well?
Like (0)

3. Tran TuanFebruary 25, 2016 at 10:30 am


It good for new comer. thanks
Like (0)

4. ntin sharmaMarch 5, 2016 at 5:27 pm


tnx a lot for providing all tolerance limits in IR with best examples
Like (0)

5. ntin sharmaMarch 5, 2016 at 5:29 pm


can i it be possible to post tolerance limits for INVENTORY Management (b1,b2,pv).
Like (0)

Share & Follow


Privacy

Terms of Use

Legal Disclosure

Copyright

Trademark

Sitemap

Newsletter

You might also like