Improve the way stock item "Count On Hand" values are updated in the backend

[benjaminwil]

In this issue, I want to argue that the functionality for changing the "Count On Hand" value for stock items (in the backend) could be more clear and simpler to use than it is now.

I'm going to set up a scenario that demonstrates why I think that the current implementation is error prone and forces administrators to do math that they don't actually need to do.

Steps to reproduce

Part 1

This part is just setting up a mock scenario for your store administrator in Part 2:

1. Create a Solidus sandbox and start it up.
2. In the backend, check the product stock for the "Ruby on Rails Mug" product. The "Count On Hand" value should be 10 by default.
3. Check that the Ruby on Rails Mug is backorderable. By default, it is.
4. In the frontend, add 15 Ruby on Rails Mug units to your cart and complete the checkout process.
5. Now, check the "Count On Hand" value for the Ruby on Rails Mug product. It should be -5.

Part 2

In this part, watch how one of your store administrators uses the backend UI and deals with physical products:

1. One of your store administrators received 100 new Ruby on Rails Mug units in the mail.
2. They log into the the backend, go to the Stock -> Product Stock page and change the Ruby on Rails Mug count on hand to 100.
3. They ship the 5 backordered mugs.
4. The Ruby on Rails Mug "Count On Hand" value still reads 100, even though you only have 95 mugs in available to sell.
5. Another store administrator logs into the backend and sees that there are 100 Ruby on Rails Mugs in stock. Misinformation continues to spread.

Expected behavior

The backend UI is technically working as expected. It is the store administrator who is acting unexpectedly.

Actual behavior

While you might say that the store administrator "should know better," than to enter 100 in this scenario, I don't know that Solidus is helping an administrator to not make this mistake.

We could create a more complicated scenario where it is even fuzzier. Say you have 1387 mugs on hand, then you receive 150 mugs in the mail but 23 of them are broken. 👎 The store administrator should update the "Count On Hand" to be 1514--but they make a mistake and enter 1511 instead.

The "Count On Hand" value counts the items that are available to sell. The administrator should be able to figure out that if the on hand value is -5, and they have just received 100 mugs, that they need to update the count on hand to 95, not 100. (100 + -5 = 95.)

So, when they change the value to 100, they are actually adding 105 mugs to inventory. You can see that this is true in your Rails console: the Spree::StockMovement.last object will have a quantity value of 105.

Suggested improvement

It would be less error prone for the administrator to be able to add the new inventory to the old "Count On Hand" instead of having them do the math themselves.

The Solidus backend does not have a separate concept for "adding" to the count on hand. It only has the concept of "changing" the count on hand.

In an ideal world, we could let administrators do math directly in the number picker field, so they don't have to do it somewhere else:

This is something in wireframe/illustrator apps like Affinity Designer and Sketch. But realistically, most administrators would not think to do their math in the number picker field.

When administrators change the count on hand right now, what they are really doing is "resetting" the count to their new value. Perhaps we could keep this functionality but make it more explicitly about resetting the count on hand to some other value. There is even a <input type="reset"> element we could utilize for this. Here is my example mockup of this:

Features:

• You can't actually manipulate the "Count On Hand" value. You need to add to it and submit the changes. (13 + 100.)
• If you want to discard the current "Count On Hand" value, you can use the reset button then add your new value starting from 0. (0 + 100.)

I'm not a trained UX person, so maybe there are even more practical ways to implement this that I am incapable of realizing.

[kennyadsl]

Thanks for reporting these UX thoughts, I agree we need to find a better solution for this problem.

I think it really depends on the information that the admins have when they need to fill this field. For example they could have some internal stock management software that tells the final number of current stocks for a specific product, already taking into account backordered items. In this case they would do the math.

[aitbw]

Fixed via #2682 and #2862, @kennyadsl

[kennyadsl]

Thanks @tvdeyen!