hi to all,
noticed the following: when a wholesale customer logs in, he can see the wholesale prices,no problem. however, for products with children products, the price shown in the product details page is the normal, retail price, not the wholesale ones. furthermore, the strange thing is that the wholesale prices of these products are shown ok in the browse page, it's only the flypage that has the problem! you may check this here :
www.quality-tuning.co.uk
try wholesale user jegel / jegel
rgrds,
chris
Problem remains in VM 2.0.18a:
(first login with test wholesale user xondriki / xondriki)
Browse Page (Correct Wholesale Price)
http://www.quality-tuning.co.uk/list-all-products?keyword=152517-8&limitstart=0&option=com_virtuemart&view=category
If you click on the details or go here:
http://www.quality-tuning.co.uk/universal-stainless-steel-chrome-plated-exhaust-tips-mercedes-amg-e63-style-offcenter
then in the product details price the price changes to the retail one (the default product price).
Interesting Point: Upon loading of the page, you can see that there is a fraction of a second where the correct wholesale price appears, but then its overwritten by the retail one!
Would appreciate your assistance,
rgrds,
chris
A few things I would check to locate the problem:
Do you get the same effect when using a Joomla standard template? (Maybe your shop template doesn't understand multiple prices yet)
Does it make a difference when you use the VirtueMart jQuery instead of Google jQuery?
Do you have the same shoppergroups assigned to the parent and the child products? (At a first glance it looks to me like the parent product is displayed in the category view and product details view (SKU 152517-8), but only the child products (SKUs 152517 and 152518) can be added to the cart).
Thanks for your reply jjk, regarding your advice:
- We have checked with template developer and also tried with the template=0 at the URL; it seems that the issue is not template-related.
- We have tried all possible combinations of VirtueMart jQuery / google jQuery library (ON/OFF) from VM config, but the problem remains.
- The same shoppergroups are assigned to parent (152517-8) and child products (152517, 152518). Indeed the parent product is displayed in the category view and the child products in the product details view. However, if you make a search for 152517 or 152518 then the child products will appear also in the category view, and their prices will be the correct wholesale ones (don't forget to login first).
Also to mention that above was working normally with VM 2.0.16. Any other advice would be most welcome, this issue is quite puzzling for us, we really cannot understand why the price is correct at browse page and wrong at flypage :-\
Rgrds,
Chris
I'm not a dev and php illiterate, so this is a shot into the dark. My guess is that it is related to this recent fix:
"...prevent overwrite of child products if non price is set, if the parent is stored with more than one price
opening a product, with a zero price is now preventing that the price is automatically stored as 0.0"
If I understand that correctly, you might try to play with the child product price settings.
I may could understand it with Backend access. Strange thing. Maybe the problem is the variant Left/right, because it is showing first the correct price correct.
Just sent you the backend details Milbo, in case you find some time to take a look.
Thanks in advance,
Chris
I think I found the reason.
You are using the stockable variant with cart attribute. But you set the price there as 0. So it is not using the price of the product
When a custom is a cart variant, it takes the price with the variant. Strange is indeed that it takes for the variant the wrong price.
Hi Milbo,
Thanks for your reply; just to clarify: is smth that we are doing wrong, or is it an issue with Virtuemart?
Every stock variant has multiple prices also (retail, wholesale, etc..) so we have to set its price to 0 so that virtuemart fetches the variant's correct price directly, there is no other option i guess. But still, for some reason VM fetches its parent price :-\
Rgrds,
Chris
if child,.. 0 means take parent
0.0 means take 0.0
Hi again to all,
Unfortunately, the problem remains in VM2.0.18b. Initially we thought it was due to CSVI import and we checked with the developer (Roland). He confirms this problem in his installation and thinks it's indeed a VM2 issue:
[edited, link removed lead to a closed forum, useless for us]
We are stuck here, as we cannot identify the source of the problem and ofcourse how to solve it. If you cannot reproduce it, we can gladly give access to our backend for a check.
Would appreciate any ideas.
Rgrds,
Chris
Hi to all,
Problem still remains in VM2.0.20b!
We'd appreciate if anyone could take a look at our installation, this looks like a nasty bug! It is troubling us many months now.
The bug is as follows:
Log in as a wholesale user (xondriki/xondriki) here:
www.quality-tuning.co.uk
Go to this page:
http://www.quality-tuning.co.uk/list-all-products?keyword=bl206&limitstart=0&option=com_virtuemart&view=category (http://www.quality-tuning.co.uk/list-all-products?keyword=bl206&limitstart=0&option=com_virtuemart&view=category)
You will see the parent product (BL206) and its children (stockable variant) along with their wholesale prices.
Now, if you click on BL206, you will go to the flypage and you will notice that the children products shown are the retail ones!!
This is a critical bug with the stockable variants, i hope the dev team could take a look!
Rgrds,
Hmm I cant find it, but maybe the reason is the stockable plugin or some ajax. I see that the price is changed dynamically.
But seems to work for me,.. anonymous I get 48 euro and logged in I get 40 euro. so?
Hi Milbo,
The problem is that the wholesale price is 28.92 and not 40.82! 40. 82 is the retail price without the tax ( 40.82 + 18% tax = 48.16 which is the retail price which the unlogged users see)
If you go to the browse page as logged in user:
http://www.quality-tuning.co.uk/list-all-products?keyword=bl206&limitstart=0&option=com_virtuemart&view=category
The price here shown is 28.92 which is the correct wholesale
But if you go to the product flypage as logged in user:
http://www.quality-tuning.co.uk/audi-a4-a6-stainless-steel-exhaust-tip-dual-2x76-2x89-l190-200-in60
The price shown now is not 28.92 but 40.82!! (The untaxed retail price)
Maybe some bug with the stockable plugin? It fetches the wrong shopper group price for the child products.
I hope it is clear now.
Rgrds
It looks to me the variant price calculation has not taken into account of the shopper group. If the parent product price is the same as that of the child product, the transient price (the correct price) seen on the flypage is that of the parent product, not the child product.
Correct; i really hope the devs will take a look at this bug at some point, it's there for some time now.
Rgrds
In case the child product price is the same as parent product price, comment out lines 625-627 in the file /plugins/vmcustom/stockable/stockable.php will probably help.
Not sure this will work but you can give it a try and report back.
Hi Joseph,
Removed the following as per your suggestion:
{
$db = JFactory::getDBO();
$db->setQuery('SELECT `product_price` FROM `#__virtuemart_product_prices` WHERE `virtuemart_product_id`="' . (int)$selected . '" ');
if ($price = $db->loadResult()) $product->product_price = (float)$price;
}
and it seems to WORK!
So it this a VM bug?
We are now checking / testing all other functionalities to see if anything is broken,thanks again!
Good news. As I said, the stockable price calculation does not take into account the shopper group and other issue. This is a bug that needs to be fixed.
By commenting out the 3 lines, we are bypassing the stockable recalculation. That makes VM resort to the parent price. This works only if the parent and child price are the same. I don't foresee there are problems other than that.
QuoteThis works only if the parent and child price are the same.
Correct, this solution ofcourse doesn't work when the child product price is different than the parent product.
I'm trying to fix this by changing line 626 to smth like:
$db->setQuery('SELECT `product_price` FROM `#__virtuemart_product_prices` WHERE `virtuemart_product_id`="' . (int)$selected . '" AND `virtuemart_shoppergroup_id`="' . (int)$_shopperGroupId . '" ');But it's not working, i guess there is more than. Would appreciate a fix by the devs
Rgrds
Hi to all,
Any fix included in the latest svn?
Rgrds
The problem is that the stockable plugin is not using the standard vm method to load a product. So the normal stuff of deriving values from the parent do not work as expected.
We have two different methods to display stockable variants. One method is by openglobal, great js stuff and nice to handle. But it is old vm1 style, also the reason vm1 veterans prefer this method.
The other method "dynamical child variants" is using the vm methods to load a product. All parent/child stuff is there working as expected.
The future is a bit different. I want to add for vm2.1 a stock for every customfield, so we dont need anylonger this complex constructions, just for the stock.
The real fun with this stuff is atm anyway most time not used. For example to change the product image or dimensions.
Hello,
same problem for me. It looks like its' a bug of virtuemart.
DID YOU FIND THE SOLUTION?
I have many shopper groups, with different prices.
Let's say for group A the premier bag (all different color variant) costs 9 EUr
For group B 10 EUr
for group C 11
If I log with account A and I check all the variants it appears sometime 9, sometime 10, 11 with no reason.
Please check here: www.timeoutsport.com
login:
test test
and go to
http://www.timeoutsport.com/premier.html
thanks
Matteo
Hello Mateo,
Pls find a fix here:
http://forum.virtuemart.net/index.php?topic=117080.0
Just note that above fix works only if the user is assigned to 1 group, not multiple shopper groups.
Rgrds,
Chris
Hello,
it works!!!!
If you could reach you I will kiss your feet!!!!!
I had a sleepless night, and this morning You made me a wonderful gift!!!!!
THanks
Matteo