cancel
Showing results for 
Search instead for 
Did you mean: 

Problem with perpormance sales order

Former Member
0 Kudos

Hi all, Iu2019m working in an important Renaultu2019s Project and I have a critic issue related with the performance during the creation of a sales order. The program (a z development) that creates the sales order is a very simple development; it only has the call to the BAPI_SALESORDER_CREATEFROMDAT2.

Weu2019re going to generate approximately 130000 sales orders with one item each every month, and the program takes about 20 seconds per sale order. Actually, with our estimation, the process would take more than 722 hours.

We need to generate this orders during a day at least.

Does somebody have a solution for this issue?

Does anyone have experience processing large volumes of data?

Thank you in advance!

Joel

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hello

If you have sale order upload program, you can have several varients & run parrellely to increase your sale order creation rate.

thank you

regards

Anirudh

Answers (2)

Answers (2)

Former Member
0 Kudos

Hi Joel,

At a Customer site we are using the same BAPI for uploading Sales Order from an external system.

Volume of data is similar.

We experiment no performance problem for this specific BAPI; though we have performance problems for operational reporting.

20 seconds to create a one line sales order is a terrible number. You need to take back this value to less than 2 seconds (ideally less than 1 second).

Run your program for one order using transaction ST05 and also SQL Trace and check what is the reason.

Former Member
0 Kudos

Hi,

Why not run your order creation program matiple time in background. In this case system will create mutiple orders in same time.

You may diferenciate the job via sales doc type if you have any. Create multiple variant and assign to background job for fast processing.

regrads

Vivek.

Edited by: Vievk Vardhan on Dec 31, 2009 2:03 PM

Edited by: Vievk Vardhan on Dec 31, 2009 2:04 PM