tolerance key (第1页) | ERP软件技术分享

Tolerance

Skip to end of metadata

Created by Unknown User (u56a98j) on Mar 28, 2017

Go to start of metadata

Purpose

The purpose of this page is to give an overview of Tolerance functionality, main configurations, SAP Notes and SAP Documents related.

Overview

The following sections will explain about the Tolerance check functionality, showing configurations and some tips that may help during invoices creation and issue resolution.

Vendor-specific tolerance checks

With this tolerance you need to define tolerance groups for each company code. You can assign these tolerance groups to each vendor in the vendor master record. You can define the following tolerances:

Total-based acceptance If the difference is within the tolerance range, the system automatically generates a difference line on a neutral income/expense account for small differences for invoices with debit/credit differences when posting the invoice.

Total-based invoice reduction If the difference is within the tolerance range, the system posts the difference to a clearing account and generates a credit memo in a second document to clear this.

The system uses the following logic: 1. The system determines the difference between the net invoice amount (= gross invoice amount less taxes and unplanned delivery costs) and the net total of the items. If the net invoice amount is the greater, the difference is positive; if the net invoice amount is the smaller, the difference is negative.

2. Negative differences: a) If the negative difference is smaller than the absolute negative small difference limit defined, the system generates a posting to a small differences account for this difference. b) If the negative difference is greater than the absolute small difference limit defined, the system checks if the absolute difference is smaller than the lower of the absolute and percentage lower limits. If this is the case, the system creates a posting to a small differences account. If this is not the case, the system cannot post the invoice.

3. Positive differences: a) If the positive difference is smaller than the positive small difference limit defined, the system generates a posting to a small differences account for this difference.

b) If the positive difference is greater than the positive small difference limit defined and the "Check limit" field is not selected for total-based invoice reduction, the system checks whether the positive difference is smaller than the lower of the absolute and percentage upper limits. If this is the case, the system creates a posting to a small differences account. If this is not the case, the system cannot post the invoice.

c) If the positive difference is greater than the positive small difference limit defined and the Check limit field is selected for total-based invoice reduction, the system checks if the difference is smaller than the lower of the absolute and percentage upper limits for total-based invoice reduction. If this is the case, the system generates a posting to a clearing account for invoice reduction and creates a credit memo document. If this is not the case, the system cannot post the invoice.

The system does not try to reduce the invoice based on the total in the following cases: - If you manually reduced an invoice item. - If you manually accepted a difference in the document header. - If you entered a credit memo.

In these cases, the system checks directly whether it can accept the positive difference.

Note: If the system can create a small difference, it posts this difference to the account specified in account determination for transaction DIF. If no tolerance group is assigned to a vendor or if no tolerances have been specified for the assigned tolerance group, the system creates a difference line if the difference is smaller than the tolerance defined for tolerance key BD.

General tolerance limits

With this tolerance you can specify the tolerance limits for each tolerance key for each company code. When processing an invoice, 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.

PC: Price variance for contract

You can use the tolerance key PC to define price variances when entering an invoice with reference to a contract. For tolerance key PC, tolerance limits are defined per company code.

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

Item amount check

In this step, you determine whether the system blocks invoice items when their value exceeds a certain amount. You set the limit above which items are blocked as the "absolute upper limit" for the following tolerance limits: AN for invoice items without order reference AP for invoices with order reference

This depends on two criteria: Item category Goods receipt indicator

The system checks the amount for all possible combinations of item category and goods receipt indicator in all the company codes in which the check is active.

Stochastic block

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. Invoices with stochastic blocks can only be released manually.

You can determine for each company code the degree of probability that an invoice will be stochastically blocked. The degree of probability depends on the invoice value; if it is the same or larger than the threshold value, the degree of probability is the same as the percentage. If the invoice value is smaller, the degree of probability is calculated in proportion to the threshold value.

Example: Threshold value: 3000 percentage: 60

Technical details

Function modules: MRM_AMOUNT_CHECK

MRM_QUANTITY_CHECK

MRM_TOLERANCE_CHECK

Important tables: RBKP RBKP_BLOCKED -> this is read by MRBR transaction RSEG BSEG

Important fields: RBKP-ZLSPR: Payment Block Key - only filled in case of manual or stochastic block. RBKP_BLOCKED-MRM_ZLSPR: Logistics payment block filled with A, S, M, W. RSEG-SPGRP: Blocking Reason: Price RSEG-SPGRM: Blocking Reason: Quantity RSEG-SPGRT: Blocking Reason: Date RSEG-SPGRG: Blocking Reason: Order Price Quantity RSEG-SPGRV: Blocking Reason: Project Budget RSEG-SPGRQ: Manual Blocking Reason RSEG-SPGRS: Blocking Reason: Item Amount RSEG-SPGRC: Blocking Reason: Quality BSEG-ZLSPR: Payment Block Key from the vendor line item

Invoice Tolerance Keys – An insight – Part 1

2155134,604

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 client’s 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.

3 way match:

Invoice line item is checked against corresponding purchase order and good receipt documents item for price & quantity matching

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.

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:

Item level:

Table: RSEG Value = X

Fields:

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

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

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 vendor’s 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.

Invoice will be posted without block

Small difference G/L account (DIF) get posted

RBKP – MAKZN (net amount accepted manually) field will get updated with small diff. amount : 3.00

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:

No GR based IV

Variable order unit is activated at material level

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.

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.

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

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

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

FollowLikeRSS Feed

Alert Moderator

Assigned Tags

MM (Materials Management)

3way match

invoice block

invoice verification;

rbkp blocked

spgrp

three way match

Find us on

Privacy

Legal Disclosure

Trademark

Cookie Preferences

Newsletter

Former Member

December 4, 2015 6 minute read

Invoice Tolerance Keys – An insight – Part 2

81444,158

Finally here is the part 2 of Invoice Tolerance keys which is the continuation of part 1 .

KW: Variance from condition value

Definition:

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.

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.

LD: Blanket purchase order time limit exceeded

Definition:

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 .

PP: Price Variance

Definition:

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

PS: Price variance: estimated price

Definition:

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.

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 won’t be any warning message for date discrepancies before posting the invoice

VP: Moving average price variance

Definition:

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.

FollowLikeRSS Feed

Alert Moderator

Assigned Tags

MM (Materials Management)

Find us on

Privacy

Legal Disclosure

Trademark

Cookie Preferences

Newsletter

Support

Invoice value	Degree of probability of a block
3000	60%
5000	60%
1500	30% (= 60 * 1500/3000)
100	2% (= 60 * 100/3000)

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

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

Tolerance Key	RBKP	RBKP_BLOCKED	RSEG	Auto release
AN	No blocking indicator update(ZLSPR)	A- Auto block	No update (item amount block)	Not possible

Tolerance Key	RBKP	RBKP_BLOCKED	RSEG	Auto release
AP	No blocking indicator update(ZLSPR)	A-Auto block	RSEG- SPGRS = X (item amount block)	Not possible

Tolerance Key	Tolerance	RBKP	RBKP_BLOCKED	RSEG	Auto release
BD	Within range	No blocking indicator update(ZLSPR)	No update	No blocking reason update	NA
BD	Above	No blocking indicator update(ZLSPR) MAKZN field updated with diff. amount	No update	No blocking reason update	NA