Pricing procedure

[Former Member]

Hi All,

Is there any guidelines on the number of Pricing procedures and Condition types for each Procedure to be used in SD module. My Client's concern is that more the no. of Procedures and Condition types might result in slowing down the system. So I would like to know if there are some standards / thumb-rule that can be followed.

Thanks

Madhavan

[Former Member]

Hello Madhavan,

I cannot say that I have worked extensively on pricing, but I'm somewhat surprised at your client's concern. I have not yet heard someone remark that creating more conditions will slow down the system. Yes, creating more conditions will increase the number of condition records in the corresponding tables, but that should hardly be considered as slowing down of the system.

Pricing is done to meet the customers functional requirement. For example, let us say that a particular product should have a different price in different regions of a country. that is a very very common requirement. If the customer wants this implemented, then is there anything at all that can deter him? Do you think this would impact the performance and so cannot be / should not be implemented? Please think about it.

Coming to thumb-rules on pricing, I think pricing is highly subjective. And I haven't come across any to date. If somebody has, then please do share it.

Regards,

Anand Mandalika.

[christian_wohlfahrt]

Hi Madhaven,

I can understand this concerns - I had several customers with such problems.

Total number of database accesses will determine performance.

Number of pricing procedures won't effect performance, because per article and document only one is relevant (and procedure determination is only a small table). (But more procedures will lead to confusion and inconsistencies in case of changes - just a question to be able to have an overview.)

Number of conditions per procedure * number of (relevant) steps in access sequence + something for calculation (sub-) totals is runtime. (Later referred with factor X)

If you have hell a lot of manual conditions, performance won't increase much.

If you have a lot of conditions, which will be found in first step of access sequence, it's as good as a small number of conditions with a very long access sequence and conditions are very likely found on general level.

Own selects in requirements are of course totally forbidden, selects in condition formulas should be avoided (like hell...).

Then total system performance is important (big machines can handle more parallel sessions / hold more tables in buffer...).

SAP Release is important. 4.6C is 5 times faster than 4.0B, 4.7 again twice...

The more procedures are used, less steps should be included. Other way around: very seldom cases can include complicate long procedures.

Fast procedures should have a factor X of 10 - 15, normal may be around 20 - 25, but also 50 is not completely out of range - as long as you don't need a million accesses / hour.

More detailed information depends on your actually used processes.

Has your client already visited some reference customer?

Regards,

Christian

[Former Member]

Hi Christian and Anand,

Thanks for your replies. Anand, I agree with you but certain Clients are very demanding and at the same time would like to prevent Performance issues rather than dealing with them later after the damage is done. And for this they would investigate even the minutest of details beforehand even if we think it's senseless.

Christian, that is an interesting formula that you gave me. But let me understand it properly with an example.

No. of condition types per procedure = 5

No. of steps in access sequence (I assume you are referring to the total no. of condition tables in a procedure) = 3 for each condition type. So a total of 5*3 = 15.

I didn't understand the last part of the formula i.e. 'something for calculation (sub-) totals'. Can you please clarify that.

So according to the 1st 2 parts of the formula, X factor = 5*15 = 75

Our Client has not visited any reference customers but in our domestic scenario, typically there are quite a few Procedures with each having a sizable no. of Condition types as the business is dynamic and complex.

Can you please confirm whether my understanding of the formula is correct. And I will definitely thank you in the 'SDN way'

regards,

Madhavan

[christian_wohlfahrt]

Hi Madhavan,

it's not so complicate (as my description looks like):

count total number of database accesses -> 15 is correct.

When you have big procedures, running through this, looking for condition exclusions, requirements,... all this stuff will take little time, too. That was 'plus something', let's say 1 or 2.

This total formula I wanted to call X...

So with 15 I never had any problems - but my customers had always really big machines (one was in Top 500 of Supercomputer-list in '98, '99; so could 'compete' against number crunchers with his database system).

But to get more into details: not each condition access costs same time: small A-tables are faster to access than big ones... Population with data can change this picture. Also number of changes can be important: tax conditions are (nearly) never changed, tables can be fully buffered -> cheap access. Vendor conditions / general level surcharges are changed once a year -> buffering is possible. Article -> probably changed to often for buffering.

It's a nice topic. Being aware of potential problems is a good start, but in the end only mass tests will give you an answer.

Regards,

Christian

[MauricioMiao]

Hello Madhavan,

Another thing I would warn you to take into account is the common number of items your customer have in one Order Document.

In the customer I am now, they have a big pricing.

They have 126 conditions in one pricing, and the access sequences something around 40.

In SAP environment when you have orders with 30, 40 items the performance is ok.

Only when you create an Order with more than 100 items then the performance problem takes place.

The problem is even worse when you have CRM scenarios.

Like here they have CRM Mobile Sales and Internet Sales.

In Mobile Sales is impossible to create an order with more than 50 items because the syncronization takes more than 30 minutes (syncronization is the operation to send to R/3 the orders created in the laptop).

So you also have to take into account if your customer intends to implement SAP CRM Solutions.

If it is not the case, then you can base on my numbers to have an idea, with the numbers I told you, in the customer I am know, they are not facing performance problems, except in SAP CRM environment.

Regards,

Mauricio

[MauricioMiao]

Hello Madhavan,

Let me correct a number, the total conditions in the pricing is 92 and not 126 as I said.

126 are the total lines in pricing in my customer including subtotals.

Then suppose you have an Order with 100 items and all the 92 conditions are relevant, then in table KONV you will have 9200 records.

Also I add that my customer does not have a "very" powerfull server, they have a normal infrastructure, not poor and not rich.

Regards,

Mauricio

Message was edited by: Mauricio Mião

[christian_wohlfahrt]

Hi,

some more comments:

I'm always thinking in millions:

I expected several millions conditions in system -> most table access are expensive.

I expected about a million price determinations / day -> we are talking about milliseconds.

I expected about a million price changes a week -> no buffering in main tables.

If you have smaller numbers, higher 'X-factor' can be tolerated.

But here we are already on a very detailed discussion -> in the end only masstests will give correct answer for runtimes.

Regards,

Christian

[Former Member]

Hi Christian and Mauricio,

Thanks for your replies and insights. The type of business scenarios that we have here will require us to have around 30 relevant Condition types for a Sales document. The Condition tables per Condition type can be around 7. Also the Servers may not be in the league of Super computers. So I guess I will have to use Christian's formula along with considerations from Mauricio to re-scale the X factor.

regards,

Madhavan