Tolerance in SRM and ECC (BE R/3)

[former_member293881]

Hi,

During posting of invoice in SRM, why only TOG tolerance will be used for checking tolerance?

As per my understanding, ECC tolerance will not be checked during SRM invoice posting.

Is it correct system functionality in SRM?

regards,

Rahul Mandale

[Ramki · Accepted solution]

Hi Rahul

Yes. ECC Tolerances will not be checked.

Maintain the same tolerances in both ECC and SRM as far as possible.

Best regards

Ramki

[former_member293881]

Atul,

Most of those OSS notes are for program correction. I am wondering that why I need to set up tolerance check aain in ECC?

SRM tolerance are used for what reasons?

In case of ECS, I don't want to use ECC tolerance check but only want to use SRM tolerance. We sre in SRM_SERVER550 ( SP07)

How can be done?

regards,

Rahul

[Ramki]

Hi Rahul

In a standalone scenario, you would not need ECC tolerances.

But, in ECS, the first level of tolerance check is done in SRM. When the invoice is posted in SRM, it creates an invoice in ECC. ECC always goes with tolerances defined in ECC.

Currently, we do not have synchronization of both ECC & SRM tolerances though that would have been great. So, you need to define in both ECC & SRM.

Best regards

Ramki

[former_member293881]

Hi,

SAP replied that these tolerances are dependednt on ECC too.

As per OSS note 481168 and 481698, we need to set ECC tolerance too.

Anyones experience for setting up tolerance in SRM for ECScenario.

regards,

Rahul Mandale

[Former Member]

Hi

<u>Please read the following OSS notes as well.</u>

<b>935538 Delivery tolerance not copied to back-end purchase order

Note 838905 - Determining the tolerance group

Note 835073 - Enhancement of the tolerance checks

847237 SRM Global Outline Agremt: Distribution of deleted condition

778489 Partial confirmations for back-end service purchase orders

701724 Overdelivery tolerance

649553 TAX: Tolerance check for tax amounts in the invoice

874195 Tolerance check 'LD' does not tolerate prior dates

895791 Fields in purchase order item arranged incorrectly

544545 EBP: Checks if backend data cannot be read

600361 EBP: Tolerance error messages for price unit > 1

608041 Tolerance checks with service-related invoice verification

</b>

Hope this will help.

Please reward suitable points, incase it suits your requirements.

Regards

- Atul

[Former Member]

I'm having similar problems btu with repsect to SRM PO's against Contracts raised in the backend (replicated into SRM)

Our infrastructure -s SRM 7 Extended Classis Scenario and ECC 6.

I have tolerances setup in ECC and SRM and the TOG has been assigned in SRM Vendor Groups and in the HR Org Structure (PPOMA).

Tolerance are 5% up to $100.00

If I raise a Contract in ECC, and a PO (MM) in ECC, then the PO will work if I stay within the allowed tolerances.

When I raise a PO in SRM, the Shopping Cart is processed OK, but when the SC is approved, the backend PO is not created.

In the Shopping cart in Related Documents for document Purchase Order, the Satus is set to Saved. A review of SLG1 indicates error due to exceeding the quantity and the Target value.

Why are tolerances not being taken into consideration? How do I get this to work?

Gerry

[Former Member]

Hi

Have you maintained the same configuartion data both in R/3 as well as SRM system for the Tolerance group ?

Which SRM scenario you have maintained ? Whci SRM System release you are using ?

<b>I guess, ECC will be checked only based on the EBP Scenario yo have maintained for the system. But the BAPI call checks the configuartion data in SRM as well as R/3 before posting the Invoice.</b>

<u>Here is the detailed reasons behind the same -></u>

Set Tolerance Checks

In this activity, you define the tolerances for value or quantity overruns for deliveries, invoices, or order confirmations. Quantities or values of deliveries, invoices, or purchase order confirmations may vary up to these tolerance values. This allows deliveries or invoices to still be posted or data to be transferred from the order confirmation to the purchase order. For the definition of these tolerances, use tolerance groups to which you assign tolerance keys with different values and quantities. In this way, you can assign the same tolerances to different users.

Example

You assign the tolerance key DQ to the tolerance group M (manager), define an upper limit of 1000 for the value-based limit and activate the value limit. You also assign the tolerance key DQ to the tolerance group E (employee), define an upper limit of 100 for the value-based limit, however, and activate the value limit.

Standard settings

You can assign the tolerance group to a user group via the attribute TOG (tolerance group). For example, you assign the value M to user Manager 1 in the user attribute TOG for the user group Manager. If a user is logged on, the system always uses his TOG. If the user is not logged on, (BAPI is being used), the system uses the TOG of the vendor (business partner master record).
You can create tolerance groups by checking the quantity against the purchase order and the price (value) against the confirmation.
If you do not define any tolerances, this means that it is not possible to enter a delivery/incoming invoice in EBP where quantity or value has been exceeded.
The tolerance can be specified as a value, percentage, days, depending on the tolerance key. Two differently structured tolerances exist for value variances (DA for cumulated values, PP or PR for single values).
Percentage and absolute limits
If you define both a percentage and an absolute limit in a tolerance key, then you cannot post an invoice or automatically transfer data from the first purchase order confirmation received into the purchase order, if either one of the tolerances is exceeded. An absolute limit always has priority.

Example (with respect to invoice verification): You have defined a percentage upper limit of 5% and an absolute upper limit of 10. You wish to enter an invoice with the amount 1000, that exceeds the order value by 30. Although the percentage  upper limit of 5% is observed, the absolute limit is not. The invoice exceeds the tolerance and can therefore not be posted.
Tolerances for deliveries/invoices
You can assign the following tolerance keys:

CF: Over/underdelivery in the confirmation
You use this tolerance to check how the confirmation deviates from percentage limits for overdelivery and underdelivery. First, the system checks in the confirmation against the tolerances created in the purchase order. If none exist, the system checks against the tolerances in the relevant tolerance group (for example, the tolerance group of the vendor). If you select the value Unlimited , no tolerances apply. The system displays a controllable message when a tolerance is not reached or is exceeded (see Influence Message Control).
DA: Exceed value (cumulated)
You use this tolerance both for confirmations and invoice entry. You can either define an actual value or a percentage for the upper limit. The system checks whether the cumulated invoice value (that is the value of all previous invoice documents + current invoice documents) exceeds the order value. The check is always made against the purchase order. If a confirmation is expected for an order item, a second tolerance check is made to determine whether the cumulated confirmation value (value of the previous confirmation documents + current confirmation) exceeds the order value.
DQ: Quantity variance (converted to currency amount)
You use this tolerance both for confirmations and invoice entry.
If a confirmation is expected for an order item and has already been posted, the system multiplies the net order price by (quantity invoiced - (total quantity delivered - total quantity invoiced)). If no confirmation is expected, 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.
LA: Amount of limit purchase order
You use this tolerance both for confirmations and invoice entry.
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: Limit purchase order; time limit exceeded
You use this tolerance both for confirmations and invoice entry.
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.
PP: Price variance (value variance from expected value)
You only use this tolerance for invoice entry.
The variance from the expected value is checked here, based on the preceding document (purchase order price or confirmation value).
The system determines by how much each invoice item varies from the product of quantity invoiced multiplied by the order price. It then compares the variance with the upper and lower limits defined (absolute limits and percentage limits).
TX: Tax variance
You use this tolerance exlusively for invoice entry. You define tolerances for tax amounts that are used with the tax calculation.
Tolerances for purchase order confirmations
SAP Enterprise Buyer uses the tolerances that you define here for the automatic data transfer from the purchase order confirmation to the purchase order and also for the manual data check in the vendor information. If the tolerances are exceeded, the system issues I messages.

You can assign the following tolerance keys:

PM: Quantity variance (converted to currency amount)
If a confirmation is expected for a purchase order item, the system calculates the purchase order confirmation net price multiplied by the purchase order confirmation quantity. The system compares this sum with the defined upper and lower limits. You can also define percentage limits for the quantity variance check. Then the percentage variance from the expected quantity calculated - independent of the purchase order price - and this is compared with the defined percentage limits.
PZ: Time overrun compared to purchase order
The system determines how many days the delivery date has exceeded the planned time interval by. If the delivery date of the purchase order confirmation is earlier than the delivery date of the purchase order, the system takes the purchase order date - the confirmation date; If the delivery date of the purchase order confirmation is later than the delivery date of the purchase order, the system takes the purchase order confirmation date - the purchase order date. The system compares the number of days with the defined absolute upper limit.
PR: Price variance (value variance from expected value)
Here the variance between the purchase order confirmation and the purchase order price is checked. The system determines for the items the price variance as the product of the quantity in the purchase order confirmation multiplied by the price in the purchase order confirmation, and it compares this variance with the defined percentage and absolute upper and lower limits.
Automatic transfer

Enterprise Buyer automatically takes the data from the first purchase order confirmation to be received, however, the following conditions apply:

Data transfer is only possible if no contract exists for the purchase order item.
All existing tolerances (quantity, price and delivery date) are adhered to and/or the purchase order confirmation data matches that of the purchase order exactly.
If the purchase order confirmation consists of multiple items, then the system transfers the data as follows:
The sum of all quantities
The highest available price
The latest available delivery date for materials or the maximum period for provision of services and limit items
( The system does not take any tolerances into account when data is transferred manually from the purchase order confirmation.)

The system does not automatically transfer any data from other purchase order confirmations. This prevents the original data of the purchase order being changed repeatedly by several purchase order confirmations one after the other when tolerances are exceeded.

Activities

1. Create a tolerance group and select it.
2. Assign one or more of the defined tolerance keys to the tolerance group.
3. Enter an upper and/or a lower limit. If you do not make an entry, the check is made against the value zero.
Further notes

The following table shows the existing assignment possibilities(X) for upper limits (UL) and lower limits (LL) :

   
Key Absolute Absolute Percentage Percentage Percentage Day  Day   
 LL UL LL UL unlimited  LL UL  
CF   X X X  
DA  X  X 
DQ; PM  X  X 
LA  X  X 
LD; PZ      X X 
PP; PR X X X X

Hope this will help.

Please reward suitable points.

Regards

- Atul

[Former Member]

Hi

Have you maintained the same configuartion data both in R/3 as well as SRM system for the Tolerance group ?

Which SRM scenario you have maintained ? Whci SRM System release you are using ?

<b>I guess, ECC will be checked only based on the EBP Scenario yo have maintained for the system. But the BAPI call checks the configuartion data in SRM as well as R/3 before posting the Invoice.</b>

<u>Here is the detailed reasons behind the same -></u>

Set Tolerance Checks

In this activity, you define the tolerances for value or quantity overruns for deliveries, invoices, or order confirmations. Quantities or values of deliveries, invoices, or purchase order confirmations may vary up to these tolerance values. This allows deliveries or invoices to still be posted or data to be transferred from the order confirmation to the purchase order. For the definition of these tolerances, use tolerance groups to which you assign tolerance keys with different values and quantities. In this way, you can assign the same tolerances to different users.

Example

You assign the tolerance key DQ to the tolerance group M (manager), define an upper limit of 1000 for the value-based limit and activate the value limit. You also assign the tolerance key DQ to the tolerance group E (employee), define an upper limit of 100 for the value-based limit, however, and activate the value limit.

Standard settings

You can assign the tolerance group to a user group via the attribute TOG (tolerance group). For example, you assign the value M to user Manager 1 in the user attribute TOG for the user group Manager. If a user is logged on, the system always uses his TOG. If the user is not logged on, (BAPI is being used), the system uses the TOG of the vendor (business partner master record).
You can create tolerance groups by checking the quantity against the purchase order and the price (value) against the confirmation.
If you do not define any tolerances, this means that it is not possible to enter a delivery/incoming invoice in EBP where quantity or value has been exceeded.
The tolerance can be specified as a value, percentage, days, depending on the tolerance key. Two differently structured tolerances exist for value variances (DA for cumulated values, PP or PR for single values).
Percentage and absolute limits
If you define both a percentage and an absolute limit in a tolerance key, then you cannot post an invoice or automatically transfer data from the first purchase order confirmation received into the purchase order, if either one of the tolerances is exceeded. An absolute limit always has priority.

Example (with respect to invoice verification): You have defined a percentage upper limit of 5% and an absolute upper limit of 10. You wish to enter an invoice with the amount 1000, that exceeds the order value by 30. Although the percentage  upper limit of 5% is observed, the absolute limit is not. The invoice exceeds the tolerance and can therefore not be posted.
Tolerances for deliveries/invoices
You can assign the following tolerance keys:

CF: Over/underdelivery in the confirmation
You use this tolerance to check how the confirmation deviates from percentage limits for overdelivery and underdelivery. First, the system checks in the confirmation against the tolerances created in the purchase order. If none exist, the system checks against the tolerances in the relevant tolerance group (for example, the tolerance group of the vendor). If you select the value Unlimited , no tolerances apply. The system displays a controllable message when a tolerance is not reached or is exceeded (see Influence Message Control).
DA: Exceed value (cumulated)
You use this tolerance both for confirmations and invoice entry. You can either define an actual value or a percentage for the upper limit. The system checks whether the cumulated invoice value (that is the value of all previous invoice documents + current invoice documents) exceeds the order value. The check is always made against the purchase order. If a confirmation is expected for an order item, a second tolerance check is made to determine whether the cumulated confirmation value (value of the previous confirmation documents + current confirmation) exceeds the order value.
DQ: Quantity variance (converted to currency amount)
You use this tolerance both for confirmations and invoice entry.
If a confirmation is expected for an order item and has already been posted, the system multiplies the net order price by (quantity invoiced - (total quantity delivered - total quantity invoiced)). If no confirmation is expected, 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.
LA: Amount of limit purchase order
You use this tolerance both for confirmations and invoice entry.
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: Limit purchase order; time limit exceeded
You use this tolerance both for confirmations and invoice entry.
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.
PP: Price variance (value variance from expected value)
You only use this tolerance for invoice entry.
The variance from the expected value is checked here, based on the preceding document (purchase order price or confirmation value).
The system determines by how much each invoice item varies from the product of quantity invoiced multiplied by the order price. It then compares the variance with the upper and lower limits defined (absolute limits and percentage limits).
TX: Tax variance
You use this tolerance exlusively for invoice entry. You define tolerances for tax amounts that are used with the tax calculation.
Tolerances for purchase order confirmations
SAP Enterprise Buyer uses the tolerances that you define here for the automatic data transfer from the purchase order confirmation to the purchase order and also for the manual data check in the vendor information. If the tolerances are exceeded, the system issues I messages.

You can assign the following tolerance keys:

PM: Quantity variance (converted to currency amount)
If a confirmation is expected for a purchase order item, the system calculates the purchase order confirmation net price multiplied by the purchase order confirmation quantity. The system compares this sum with the defined upper and lower limits. You can also define percentage limits for the quantity variance check. Then the percentage variance from the expected quantity calculated - independent of the purchase order price - and this is compared with the defined percentage limits.
PZ: Time overrun compared to purchase order
The system determines how many days the delivery date has exceeded the planned time interval by. If the delivery date of the purchase order confirmation is earlier than the delivery date of the purchase order, the system takes the purchase order date - the confirmation date; If the delivery date of the purchase order confirmation is later than the delivery date of the purchase order, the system takes the purchase order confirmation date - the purchase order date. The system compares the number of days with the defined absolute upper limit.
PR: Price variance (value variance from expected value)
Here the variance between the purchase order confirmation and the purchase order price is checked. The system determines for the items the price variance as the product of the quantity in the purchase order confirmation multiplied by the price in the purchase order confirmation, and it compares this variance with the defined percentage and absolute upper and lower limits.
Automatic transfer

Enterprise Buyer automatically takes the data from the first purchase order confirmation to be received, however, the following conditions apply:

Data transfer is only possible if no contract exists for the purchase order item.
All existing tolerances (quantity, price and delivery date) are adhered to and/or the purchase order confirmation data matches that of the purchase order exactly.
If the purchase order confirmation consists of multiple items, then the system transfers the data as follows:
The sum of all quantities
The highest available price
The latest available delivery date for materials or the maximum period for provision of services and limit items
( The system does not take any tolerances into account when data is transferred manually from the purchase order confirmation.)

The system does not automatically transfer any data from other purchase order confirmations. This prevents the original data of the purchase order being changed repeatedly by several purchase order confirmations one after the other when tolerances are exceeded.

Activities

1. Create a tolerance group and select it.
2. Assign one or more of the defined tolerance keys to the tolerance group.
3. Enter an upper and/or a lower limit. If you do not make an entry, the check is made against the value zero.
Further notes

The following table shows the existing assignment possibilities(X) for upper limits (UL) and lower limits (LL) :

   
Key Absolute Absolute Percentage Percentage Percentage Day  Day   
 LL UL LL UL unlimited  LL UL  
CF   X X X  
DA  X  X 
DQ; PM  X  X 
LA  X  X 
LD; PZ      X X 
PP; PR X X X X

Hope this will help.

Please reward suitable points.

Regards

- Atul