Test Cases Encountered The Most Wanted Reserved Qty Bug

Oh! No. Not Again! This was my first reaction when I discovered an open support ticket is awaiting for me since 3 days.

March 9, 2013

Oh! No. Not Again!

This was my first reaction when I discovered an open Support Ticket was awaiting me since three days. It was raised by Aditya Duggal, one of our early customers and the most active member of the ERPNext community. Since I am the resident expert on this issue, and I was on leave, the ticket remained open.

Looking at the subject of the ticket, a guilty feeling came into my mind. I was frustrated with the issue, as it has bugged me several times even after fixing it at a regular intervals. But this time I was determined to fix the root cause, with the power of our new "Test Suite".

The Issue:

Reserved quantity for the item CSE07000060-411 showing as 5 Nos in BGH655 warehouse whereas we don't have any pending orders for this particular item.

Reserved Quantity is the quantity, which is reserved for delivery to the customer. It increases on submission of a Sales Order, and reduces when a Delivery against that Sales Order is made. The value is maintained in a table called "Bin", a unique combination of item and warehouse.

Unlike past, this time I did not dive into the code directly. I started with writing automated test cases.

Case 1: Create Sales Order (SO) with stock items. Submit and Cancel it, check reserved qty after each step.

Case 2: Make Delivery Note (DN) against an SO, with partial delivery and submit it. Stop and Unstop the SO, Cancel DN and Cancel the SO. Check reserved qty in each step.

Case 3: Follow same steps as case 2, for over-delivery against sales order

All the testcases passed without any error. I was not able to think of any other test case. But the error in Aditya's account confirms that there are some cases where it is going wrong. Then I realized that I totally forgot about packing items. Immediately I looked into it and tried to cover those test cases.

Case 4: Create packing item and Sales BOM for that item. Follow same steps as case 2 with packing items.

Case 5: Follow same steps as case 3 with packing items for over-delivery.

And here it goes!

The Case 4 failed while stopping SO after partial delivery. I was very excited but wanted to make sure that I wrote the right test cases. After digging into deep, I found that the quantity being updated while stopping was wrong. I completed test cases for over-delivery of packing items as well before moving to fix the issue.

While fixing the issue, I realized that the code should be refactored, as it was very difficult to read. Test cases gave me the license to go ahead with rewritiing the code.

After refactoring the code, I was very glad, all the test cases passed smoothly. I realized the power of writing automated test cases, which helped me to catch a bug that was eluding me for almost 2 years. Now I try to write every piece of code with atleast minimal test cases.

After fixing the issue, I was traced back my step to understand how this issue bugged me in the past. I am pasting here full email transcript between Aditya and me. If you are curious to know, please click here [Warning: It's a long conversation]

Nabin Hait
Nabin Hait
"Nabin is a Software Developer at ERPNext and specializes in Accounting and Inventory."
No comments yet

No comments yet. Start a new discussion.

Add Comment