Optimizing MATERIAL Price List

[Former Member]

Hello All,

We have Material Database of more than 2 000 000 records. Creating a price file is very time consuming task.

Up to now We use FM "PRICING" to determine the correct price according to relevant customer. I can optimize Material Data reading whit mass reading MARA. But "PRICING" itself is done is by single material.

So the question is do you have any clue how can I make pricing on more than one material effectively. I've created some parallelisation of the process but the real slow down is because the FM Pricing is created for single material only.

Regards Ognian Kalaydjiev

[yuri_ziryukin]

Hello Ognian,

AFAIK there is not solution of your problem except parallelization.

If you use flexible pricing with regulary changing conditions, then the complete pricing should be executed. This takes time. During this task all your access sequences and relevant condition types will be evaluated. You can't get rid of that.

The only way is to optimize your pricing procedure and check if you have some unused condition types or too complex access sequences, etc.

Yuri

[Former Member]

Thank you Yuri, Not exactly the answer than I was searching for. So if I understand you correctly I should rewrite the pricing by my self which is not a good solution.

Regards Ognian

[yuri_ziryukin]

Hello Ognian,

what do you mean with rewriting the pricing? I don't think it's possible. SAP pricing is quite complex and it considers many different things.

If you really want to have DYNAMIC prices in your price catalog, you'll have to live with the current solution.

Some questions from the business point of view: which customer really wants to see up-to-date prices for 2.000.000 materials?

Isn't it too much? And would it be possible to update prices on a less regular basis storing the results in some temporary tables?

Regards,

Yuri

[Former Member]

Hello Yuri,

By rewriting I mean to take a look over all access sequence tables and create pricing FM which Makes joins over them based on table with MATNR. But at moment the solution with parallel execution with temp tables takes about hour and a half for 1200 000 records which is quite OK. So for now no rewriting is needed. About business case we are in automotive business and the parts for all vehicle types are huge. And we have to provide the full list price to our dealers whit their own price in reasonable time.

Regards Ognian

[Former Member]

I think the best approach would be to first generate a complete price list with parallel processing and store the results in some table, including the access path. Then you should monitor for relevant changes of conditions, etc. and only recalculate the prices where necessary. This should be easier than rewriting the whole pricing routines.

[Former Member]

I've already done something like this. Fill temp table with unique ID whit parallel processes. But every time from scratch because the changes are too many to trace.

Regards Ognian

[Former Member]

So to conclude the right solution is temporary table generated whit parallel execution of PRICING FM.