High cpu when submit stock entry

Frappe Framework
1

I want to submit Stock Entry(Material Receipt) with item that mandatory ‘has serial number’. this is just 2-3 item with quantity > 1500 to werehouse it is unable to submit.
When submitting is high cpu and then that show message ‘time out’ . Can you help me to fix this problem

I use ERPnext v11.x.x-develop (9ecd8cc) (develop) , Frappe Framework: v11.x.x-develop (00fc9c9) (develop), Ubuntu 18.04 run on production

2

can you provide your sample data? I would like to try on my local instance

3

Thank for reply me szufisher
this is my sample data

2
22046×1098 258 KB
1
12046×1098 278 KB
3
32048×1088 199 KB

4

please share your detailed data list which i can upload into my system.

5

Sorry for late reply @szufisher
this is my detail data list

Doctype : Item
Item Name : Macbook Pro
Item ID MBP-10001
Item Group : Products
Default Unit of Measure : Nos
Maintain Stock : true
Allow Transfer for Manufacture : true
Valuation Rate : 89,000.00
SERIAL NOS AND BATCHES SECTION
Has Batch No : true
Automatically Create New Batch : true
Batch Number Series : BATCH.######
Has Serial No : true
Serial Number Series : SER.######

and Doctype : StockEntry
Purpose : Material Receipt
Target Warehouse: Stores - F
Item Code : MBP-10001
Qty : 6000

you save and submit .
then it show message time out

6

33
332518×1240 194 KB
10
102526×1242 219 KB
19
192524×1252 279 KB

7

yesterday, I tested on my local instance, change quantity to 1000, submitted OK, while change qty to 2000, timeout error,
looking into the source code, system will call db for autoname and insert into serialno table one by one, so there are huge number of db calls involved!

my two ideas as following

  1. from real business case point of view, 1000 qty of auto serial numbered items to be received into stock is quite big number, it is rare.
  2. fixing the program logic to enable handling both autoname and insert into serialno table in batch mode involves completely refactor the serialno doctype, so it is not a simple task.

so if there is no any other valid business cases with so large quantity of auto serialized item to be put into stock per each inward stock entry, I do not see the urgency of such refactor at the moment.

thanks.

8

Hi, Szufisher

All I tested on my instance to prove that this module is work for our business and after talking with my team I realized that there is no need to put a serial number on each item in stock, in this case, the program work perfectly and fast even large number of qty like 100M.

Thank you.