Skip to Content
author's profile photo Former Member
Former Member

Pricing procedure

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

Add a comment
10|10000 characters needed characters exceeded

Assigned Tags

Related questions

3 Answers

  • author's profile photo Former Member
    Former Member
    Posted on Feb 15, 2005 at 07:20 AM

    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.

    Add a comment
    10|10000 characters needed characters exceeded

  • Posted on Feb 15, 2005 at 08:15 AM

    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

    Add a comment
    10|10000 characters needed characters exceeded

    • Former Member Former Member

      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

  • Posted on Feb 21, 2005 at 04:46 PM

    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

    Add a comment
    10|10000 characters needed characters exceeded

    • 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

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.