Basically, stock levels are not being managed in 1.1.1
I know that this morning i set the quantity of a product to 1, and i have just had 2 orders arrive for that 1 product, about 20 mins apart, and when I checked it still thought that there was still 1 in stock. (It should now be -1, in fact it should not have let the econd order go through at all.)
Both orders are showing as payment received as they were immediately paid via PayPal. I have check stock enabled in the config, but its obviously not reducing stock as purchases are made.
EDIT: Changed title to 1.1.2 as it also refers to that
I'm using Joomla 1.5.8 and VM 1.1.2 latest nightly build and the stock level is reduced after an order here.
Don't know what is the source of the problem with the versions you are using, but considering that the Joomla Team announced the end of support for the Joomla 1.0 series in July, it's perhaps time to think about migrating to the latest version.
(it's probably easier now than one or two years later ;))
it probably would be easier, unfortunately i have another componant that is vital to my site that is not compatible with jm 1.5. Having people constantly tell me how I need to upgrade is getting tiring.
I appreciate knowing that it is fixed in 1.1.2, i just hope other things are not broken if I upgrade. Like when I upgraded from 1.0 to 1.1 and now worldpay doesn' t work either, so I need to do another upgrade to get what should be basic functionalty back, and reapply all the other hacks again to get all the other functions/features that vm doesn't come with out of the box.
It's all getting too tiring, right now I'm looking at upgrading jm and swapping vm for an app that I can actually use and that will also do the functionality of the componant this is making me stick to 1.0
Quote from: willowtree on November 11, 2008, 21:29:02 PM
i just hope other things are not broken if I upgrade...
As a long term VM user I'm shure you test major upgrades locally first - I would never change a running system without testing it on a local copy of the live site first. There are just too many things that can go wrong. (I believe in Murphy's law - "Anything that can go wrong, will go wrong" and "There is always one more bug" ;D)
sometimes things aren't obvious though, and something like this I would expect to be tested before a release was declared stable.
OK, I've reinstalled VM FROM scratch. Completley deleted, and reinstalled, and reuploaded the database.
I STILL have this problem. stock levels are not reduced after an order has been placed.
I view this as a fundamental flaw.
I've just done a search o n all the files in the classes folder and can't see that the product is being reduced anywhere for a 'normal' order. I can see it in order_edit and order_change, but not anywhere else?
The only thing that currently comes into my mind is that you are using child products and might have set a stock level for your parent product (check your SKUs). If you make use of the child product feature, the buyer actually NEVER orders your parent product and any stock level you set for the parent product won't ever be reduced.
Also, remember that the default stock list hides those products (and SKUs) with a stock level of 0 or -1 unless you select 'List all products'. So you might look at the parent product in the inventory list after you received orders which reduced the stock to 0 or i.e. -1 (which would explain what you described in your original post).
Stock control still works fine for me :D
nope, not using child products. which version of joomla are you using?
Quote from: willowtree on December 11, 2008, 13:22:17 PM
...which version of joomla are you using?
Joomla 1.5.8 stable and VM 1.1.2 nightly build 1564 - running localhost on xampp 1.6.8
I'm on joomla 1.0 - it seems the problem is limited to this version.
OK, I'm still having this problem. I think the relevant code is in ps_checkout:
// Update Stock Level and Product Sales, decrease - no matter if in stock or not!
$q = "UPDATE #__{vm}_product ";
$q .= "SET product_in_stock = product_in_stock - ".(int)$cart[$i]["quantity"];
$q .= " WHERE product_id = '" . $cart[$i]["product_id"]. "'";
$db->query($q);
//echo $q;
I added the echo, and the query looks correct, I can run it on the database directly and it's fine, and its echoing the query out so its obviously running the code, but it is definatly NOT decreasing the product_in_stock?
Example. I had 25 of an item in stock. I placed an order for 20 of them, and it still said 25 in stock. I then cancelled the order in the back end, now I have 45 in stock!
just for your info - this is the code from VM 1.1.2 (notice: no 'echo'), which works correctly along with Joomla 1.5.8.
// Update Stock Level and Product Sales, decrease - no matter if in stock or not!
$q = "UPDATE #__{vm}_product ";
$q .= "SET product_in_stock = product_in_stock - ".(int)$cart[$i]["quantity"];
$q .= " WHERE product_id = '" . $cart[$i]["product_id"]. "'";
$db->query($q);
$q = "UPDATE #__{vm}_product ";
$q .= "SET product_sales= product_sales + ".(int)$cart[$i]["quantity"];
$q .= " WHERE product_id='".$cart[$i]["product_id"]."'";
$db->query($q);
I added the echo to check that the query was being correctly generated.
with it echo'd out I applied the query to my database directly and it worked. But It's not working as orders are placed.
If there is somewhere else that this is supposed to happen I'll check there.
the site is www.willowtreecrafts.co.uk if you wanted to test it. You should be able to see quantities in stock as you browse, place an order for something and see if the quantities have changed,
Entered on bugtracker, verified as bug by Aravot
http://dev.virtuemart.net/cb/issue/2448
I decided to give this a thorough test.
Installed Joomla 1.5.8 + VirtueMart 1.1.0 stocked level worked.
Installed Joomla 1.5.8 + VirtueMart 1.1.1 stocked level worked.
Installed Joomla 1.5.8 + VirtueMart 1.1.2 stocked level worked.
Installed Joomla 1.5.8 + VirtueMart 1.1.3 (SVN) stocked level worked.
Above installation was done on WAMP (localhost)
Installed Joomla 1.5.8 + VirtueMart 1.1.3 (SVN) on remote server stocked level not working, either Installation is not working or server issue, will start fresh Monday.
just fyi my remote server is the following:
Apache version 1.3.39 (Unix)
PHP version 5.2.5
MySQL version 4.1.22-standard
Architecture i686
Operating system Linux
Kernel version 2.6.23.14
I'm running joomla 1.0.15 virtuemart: Your VirtueMart version: VirtueMart 1.1.2 stable [Another Day]
31/07/2008 20:00 GMT
in case that helps
I tried on my remote site using Joomla 1.0.15 and VirtueMart 1.1.2 stock level is working, now this is getting strange as to why it didn't work on my first try, starting fresh again on J1.5
I think I found the issue, please check.
If download is enabled then stock is not reduced.
OK, I only have a handful of downloadable products in my store.
I had the Keep Product Stock Level on Purchase? ticked in Admin-Configuration-Downloads
I unticked this and now it all seems to be working. I placed a test order and it's correctly reduced the stock.
I have gone back into the config though and it's ticked again. I've tried to untick it in both simple and extended and it's always ticked when I go back into the config. My config file is writeable, and it says it has been updated but it's STILL ticked.
I thought this setting would only apply to downloadable products but it seems it was applying to all? IMHO that is either a bug, or it needs clarifying. Being in the downloads section and stating it applies to downloads when it's applying to all products is extremely confusing.
Quote from: willowtree on December 15, 2008, 07:59:22 AM
I unticked this and now it all seems to be working. I placed a test order and it's correctly reduced the stock.
I have gone back into the config though and it's ticked again. I've tried to untick it in both simple and extended and it's always ticked when I go back into the config. My config file is writeable, and it says it has been updated but it's STILL ticked.
Checked and unchecked box for 'Keep Product Stock Level on Purchase?' for download-able products has been fixed in SVN.
Now need to find a fix to work ONLY for download-able products and not effect all products.
Fixed in SVN r1591
This issue still exists in VM 1.1.3 when 1.1.2 is updated from the backend.