2011 Jan 06 1:40 PM
Hi,
I need to speed up a process where we call function module SD_SALESDOCUMENT_CREATE in testmode
only to get the pricing (conditions) determined.
This is far far to slow. I do not want to replace it with a BAPI - this will be far to slow as well, because it
will simulate the whole order and I only want the pricing.
I am looking at function module PRICING, but cannot work out which fields to fill in komk and komp to get it working.
Have any of you used this function module and could help with an example?
Thanks,
Vibeke
Hi,
I need to speed up a process where we call function module SD_SALESDOCUMENT_CREATE in testmode
only to get the pricing (conditions) determined.
This is far far to slow. I do not want to replace it with a BAPI - this will be far to slow as well, because it
will simulate the whole order and I only want the pricing.
I am looking at function module PRICING, but cannot work out which fields to fill in komk and komp to get it working.
Have any of you used this function module and could help with an example?
Thanks,
Vibeke
2011 Jan 06 2:24 PM
I hope you've got a really clean installation and very simple item config then. It's far better to run an order simulate than to call the PRICING function directly. Of the few times I've seen that done, there has always been an issue due to poor assumptions or poor coding. I would spend the time analyzing/tuning any issues with the sales order code. Unless you're creating orders with hundreds of items with reference to a contract, the process should not be slow at all.
2011 Jan 06 3:01 PM
Hi,
No, this isn't a clean installation at all - I suppose you refer to userexits, enhancement spots etc.
So you've got me a bit worried.
The program I need to speed up, should be able to process up to 100.000 lines (no reference to contract).
Right now it handles 20.000 in an hour, and as far as I can see the time consuming bit is calling the order simulation.
Back to the drawing board it seems.
Thanks,
Vibeke
2011 Jan 06 3:30 PM
That's a huge order. If you've got some simple constraints, then you can probably make it work, but there are so many variables that affect pricing, including user exit manipulation of pricing-relevant fields or fields that affect pricing-relevant fields, it's dangerous (or at least error prone). But, your best bet is to stop in debug and look at the call for value population in the pricing function. You should be able to nail it down that way. If you have custom fields in your KOMK/KOMP append structures that affect pricing, you will need to mimic the userexit logic and populate those values.
You may also want to raise an issue with SAP. They may not help but they might also give you a solution for simulating those huge orders in a better manner.
2011 Jan 06 6:45 PM
I can easily say, there are so much coding in userexits and vofm pricing routines - you wouldn't believe it. Plus a huge number of custom fields in KOMK/KOMP append structures. That I do not even want to start thinking of mimicking.
But your suggestion to contact SAP sounds like a good idea. As long as they don't transfer me to Consulting and ask for my creditcard 🐵
Thank you for your thoughts. Really appriciate it - Just what I needed!
Best Regards,
Vibeke
| User | Count |
|---|---|
| 6 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |