HOW is Stock Managed?

[willowtree]

Is it possible for someone to explain when stock is removed/added?

I had an issue where if we refunded and cancelled an order, I would set the order to refunded, noting the refund details in the ordr notes, and then set it to cancelled. This would however add the items back into stock twice, so a product that was sold out (which is why we had to cancel the order) would suddenly have 2 available again. (This was using vm 1.0) It took me months to work out why stock was appearing out of nowhere.

I've recently upgraded to VM 1.1 and I seem to be having stock issues again.

I really need to understand when stock is added or removed. I couldn't find this info in the manual, but it probably make a good addition.

Is there a process I SHOULD be using when processing orders? What hapens when I partially refund an order using Paypal, as paypalsends back a refund and changes the order back to pending, has stock been added back to stock? What should i change the order to after this?

I also have a custom order status called 'Complete' That I use to mark orders that are collected etc rather than use shipped, but I don't want to leave them as just Confirmed as it's confusing. Is this messing up my stock levels?

[akerman]

I agree with 'willowtree'.

I also think that the VM manual would be more valuable with description of processes, and stock is a good example.

I'm too looking to understand the different steps/stages of the stock change process.
When does it change/update, by what parameters and when not?


Since there are several users complaining in the forum about stock calculation, maybe some effort could be done to collect those question and answer them with a stock description.
(In my line of business we usually call this 'decision-trees'. 

It is also my conviction that some schematics of VM functionality and relationships between PHP files for example, would significantly reduce the number of question floating around in the forum, repeating themselves...


Regards
Akerman

[aravot]

Honestly I have not looked at how stock is managed, because I have not had a return.

To fix this issue or add description to user manual, we need to agree how stock should be managed, in my opinion item should be added back to stock only when order status is set to 'canceled'.

Please add your suggestions.

[willowtree]

It's not just managing returns, but knowing what effect actions have, such as setting order statuses. If you have the order status set as refunded or cancelled, and add a customer note, i believe it will keep adding those items back into stock, each time you save a status of refunded or cancelled.

[aravot]

Before we start debugging, as to on what actions item is put back in stock, lets agree on what.

I think item should be put back in stock only when order status is changed to cancel, do we agree on this.

[willowtree]

sounds OK, however it should only be put back in stock once, not each time the order history is saved with the cancel status.

I'd LOVE to have a popup when it is going to add back into stock, with check boxes for each item so I can select which ones to add and which not, for example if a product was damaged I don't want it added back into stock (and possibly running the notification script).

Perhaps there needs to be a 'flag' set somewhere to make sure the return to stock routine is only processed once for each order?

[akerman]

Sounds all like good ideas and it's nice to see some brainstorming around this. 

However, there are quite a few instances that has to be considered when and how articles are affecting the warehouse.

An example:
A. When a customer order is set to be paid via invoice, the normal routine is to send the
   merchandise and the invoice to the customer. Either separate or in the same package.
   Today it seems VM is not able to handle this correctly. The article is still in stock,
   since no payment has yet been made.
   The administrator of VM has alternatively to reduce the stock manually or to hide the
   article manually, if it was the last item. Otherwise another customer can place an order
   that can't be managed. Actually multiple orders can be placed, if they too are made with
   invoice as payment method.


Suggested solution:
   When a customer confirms the order and checks out correctly, the stock should be reduced.
   Or at least some kind of status should be introduced that reduce the number of available
   items in the front end. Making it impossible to buy already sold/delivered products.

   Upon returned merchandise, the stock should be able to become increased with the number
   of articles returned. Or the status flag removed/reset.     

Some studies of commercial stock/warehouse/accounting software behaviour maybe could be of interest? I know there are differences between countries in how this is handled, but some kind of best practise ought to be possible to implement.


Regards
Akerman 

[betasoft]

Just a little note to the developers :

I know about the stock problem and understand what you are talking about, but one problem that I as the owner do NOT control is, when the buyer goes in to my shop and picks out an item to buy, then goes to the creditcard (epay) payment, but then cancels the order, then i have a problem, because it adds +1 to my stock, without having taken one from stock, this is a big problem, i just saw epay testing my site and he (Thomas, Epay) cancelled the order i i ended up with one more item in stock.

Please fix this stock problem !

Regards Bjarne
JM v1.0.15 and VM v1.0.15

[willowtree]

another related post is here:
http://forum.virtuemart.net/index.php?topic=38028.0

[willowtree]

I've been trying out a different system, and it has quite a nice system.

Each order has a refund button, which changes the page to offera selection of Full/Partail refund, a value or Percentage, and an option of whether to restock the product or not, and whether to advise the customr of the refund.

I like this much better than the VM method (There isn't really one )

[attachment cleanup by admin]

[johk]

I have the same problem.  For example if I have an order of 3 items which get Refunded those 3 items are added back to the total stock. But if the same order is cancelled (after it has been set to Refunded) an additional 3 items are added back to the stock.
If you have a larger site with more than one administrator that handle the orders this is a big issue as one order could easily be changed by another admin user.
I know it is important to set (or decided) the work flow before coding but this is something that need to be looked at.
I don’t want to sound harsh because I do love the work that has been done on VM.

I use joomla 1.5.7 and VM 1.1.2

Thanks

jonas

[MikeUK]

Well, I will offer my 2 cents. I have a different opinion.

I've been working on a system where the client needs to be aware of stock, but not so many products. From a retail point of view, any automatic putting back of stock is a risky thing, and I think just shouldn't be done at all within a system such as Virtuemart (where so many people have so many different uses). I will explain....

1) what if an order is cancelled because the product is damaged?

2) What if it's cancelled because the store admin made a mistake with stock inventory?

I appears to me that re-stocking a product is better done as a manual task, because there could be various situations (like the above) where human input is needed.

I think the idea of completely automatic stock control is fine when dealing with a commericial e-commerce product that has a defined area, but I wouldn't say Virtuemart is like that. But, this is also affected by my overall view that the Virtuemart core system is about as complicated as I believe it should be.

[akerman]

I agree with Mike in regards that the complications that will arise when/if trying to automate the stock control are hard to overlook, to say the least.

I have been working with major retail companies over the years and even if a lot of the stock handling is automated, it is always surrounded by a plethora of manual functions and checking. Just for the very reasons that Mike mentions. (There are of course more reasons...)

The problem with VM (my problem), is that the stock control that do exist today is inadequate. (See my note above).

It need to be fixed so that a 'manual' put back into stock is possible and that the stock is actually reduced when check-out is finished and the order is placed. The purchase is then to be considered 'reserved' but not delivered. Still no other customer should actually see the item in the shop. (Think about the shelf in the supermarket and it's stock in back. What do you see as a customer and what do you actually have access to?)

Without going into detail I can just state that the stock process does not work as it should or is expected to work. Even at the level that VM currently is / want's to be.

Regards
Akerman

   

[johk]

I do agree that a manual stock control is safer than an automatic.
But as I noted above that every time a status of an order is changed it updates the stock. That is the concern I have at the moment.
Jonas

[willowtree]

Well, I will offer my 2 cents. I have a different opinion.

tbh I'm not sure it's different!

I would like to see a semi-automatic method. By that I mean I don't want to have to go into each products details to put an order back in stock, but I don't really want the system to blindly do it either.

I think perhaps we need to think about a slightly different order process.

Perhaps in the order list there should be a refund or cancel (or something) button, and clicking that triggers another page, or a popup, that allows you to manage the other processes involved in refunding or cancelling an order.

The pop up would allow you to select which products to put back into stock, for example you could just add 2 of 4 and possibly involves the payment process too. This would allow the stock to be manually controlled, but in a more efficient manner than just removing stock changes on cancel/refund altogether. I

I think there are also issues with Paypal. If we have an order that is paid via paypal, and we refund a part of it, the paypal repsonse to VM causes the order status to be reset to pending, which is not correct. For example, a customer order 4 items at £5.00 each, we only have 3 so we refund £5.00, vm now says that the order is pending, when in fact it is paid. I haven't checked but I fear that it is also returning all the items to stock.

At the start of this thread I was just looking for clarification to how it works so I could try to create a workflow instore to fit, but it seems like this is a much larger problem and impacts on a lot of users.