cancel
Showing results for 
Search instead for 
Did you mean: 

Tolerance key DQ in extended Classic scenario give Backen error message

Former Member
0 Kudos

Dear all,

I am using SRM 7.0, SP 9

Extended Classic Scenario.

I created a tolerance group and attached it to my user via TOG attribute in PPOMA_BBP. Tolerance key is DQ with $1000 and upper percentage 5%.

I also set up the ECC tolerances:

- Purchasing Value key with Tol. Overdelivery = 5.0 (in SPRO --> MM --> Purchasing --> Material Master --> Define Purchasing Value Keys)

And assigned that Purchasing Value Key to the material group I am using (via SPRO --> MM --> Purchasing --> Material Master --> Entry Aids for Items Without a Material Master)

- And I even set up tolerance key B1 (for error message) for my Company Code (in Spro -> MM --> IM and PI --> GR --> Set tolerance limits) with a upper limit of 5%

And even with this set up I still get the error message

u201CBackend Purchase Order quantity exceeded by 1 EAu201D

when I try to post a Confirmation with an overdelivery, even if the over delivery is only 0.1% of the total quantity 1000.

What Configuration am I missing?

Cheers

Ulrike

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

Aside from configuration, did you actually input the Under/Over delivery tolerance values in your PO document?

Former Member
0 Kudos

Hi Jay,

I have not put in any Under/Over delivery tolerance values in my PO document.

I know that I can do that. However the problem is that it is only possible to assign %-value on the PO (or tolerance key CF which also only holds %-values, no absolute values). And once there is tolerance assigned on the PO, it overwrites the other tolerance keys assigned in PPOMA_BBP and there fore only the 5% over delivery limit is considered and the $1000-limit is ignored.

EG. PO Quantity 100, price $1200 and I assign a limit of 5% over delivery tolerance on the PO.

I can confirm a quantity of 101 (which is over my $1000-limit), because the absolute tolereance of $1000 assigned in DQ PPOMA_BBP is ignored.

I need to have both limits, $1000 and 5%. This is why I need to use the tolerance key DQ. Unfortunately DQ cannot be assigned to the PO.

Would be great if i could get any additional advice.

Cheers

Ulrike

former_member293881
Participant
0 Kudos

HI Ulrike,

In your first posting, last para, you need to consider that qty variance is converted to currency amount.

As per your second post, I assume you are known that 1) For CF, Tolerance in PO take priority than TOG tolerance grp.( User or Vendor root) -If a user is logged on, the system always uses his TOG.

2) When both tolerances (abs or %) for same key used, one of the tolerances is exceeded, system implement tolerance but an absolute limit always has priority over percentage limit.

Check your example again with these understanding.

Let us know your learning after POC.

Thanks,

Rahul Mandale

Former Member
0 Kudos

Dear Rahul,

Thanks for you input

Let me give you an example of the behaviour:

in PPOMA_BBP TOG assigned to user has : DQ with $1000 and upper percentage 5%.

User orders a PO with quantity=1000, price $100;

No additional tolerances assigned in the PO itself

User tries to enter confirmation with quantity 1001 (so qty variance converted to currency amount results in $100 over delivery) So the confirmation is under both the 5% and the $1000 limit.

In that case I donu2019t receive an error message from the SRM, but the error message u201CBackend Purchase Order quantity exceeded by 1 EAu201D from ECC still prevents me from posting the Confirmation. And this is the problem I havenu2019t been able to solve so far.

So I want the TOG tolerance to be used. And I am also happy with the absolute limit always having priority over percentage limit...

But I am trying to find a way to get rid of the back end message (with assigning a tolerance to the PO itself as the will get rid of the absolute limit see my previous post.)

Cheers

Ulrike

former_member293881
Participant
0 Kudos

Thanks Ulrike for your information.

If you don't implement tolerances, means system (either) will not allow to exceed anything. Please try to make ECC PO with unlimited so that SRM will only implement tolerances (Abs or %) but not ECC>

Thanks, let us know if that is working.

Rahul Mandale

Former Member
0 Kudos

Thanks for your advice, Rahul.

Unfortunately, I cannot set ECC POs to unlimited because we are using MM POs as well. This is why I am trying to setup the 5% in MM. (See my first post.) So the 5% is the same in both systems and SRM is (possibly) stricter with the additional $1000 limit.

When I create a PO in MM directly it defaults the 5% into the PO.

Cheers

Ulrike

former_member293881
Participant
0 Kudos

HI Ulrike,

System checks the tolerances defined in SRM as well as the tolerances defined in Backend PO.

Looks like DQ tolerance limit is working good. But error is due to B1 limit of 5%. Try to increase B1 limit e.g to 50% ( just for test)

Can you use B2 key in ECC instead of B1? which will give only warning.

Thanks

Rahul Mandale

siowfong_chen
Contributor
0 Kudos

Hi Ulrike,

Have you sorted this out? I have similar issue. In fact, I have manually assigned a tolerance in the PO but when I test with a quantity that will exceed the tolerance set in the PO, I get 2 messages - one relating to the % set in the tolerance and the other is the backend error which is similar to what you get.

Regards

SF

Former Member
0 Kudos

According to an OSS message, only the key CF (only contains %-value) can be assigned to a PO.

If you do that that key on the PO will overwrite any absolute value. So In my case only the 5% limit works and the $1000 limit isnu2019t.

If you donu2019t assign anything to the PO, you get a Backend error for ANY overdelivery.

The only solution we found was a development:

In BAPI_PO_CREATE1 put we put the 5% overdelivery into the ECC copy of the SRM PO.

This way the tolerances for assigned in PPOMA_BBP is not overwritten and you only get a Backend error for an overdelivery of over 5%.

In order not the hard code the 5%, we created a new parameter in table TVARV form which the BAPI is reading the overdelivery percentage.

Regards

Ulrike