"Rebel products" when sorting by price

[dslove]

Hi all,
I have this issue bugging me and I really cannot figure out the root of the problem. In VM config I have set product order to be by price, ascending (lowest -> highest). The sorting seems to work fine, apart from 1-2 "rebel" products in each category that don't seem to agree with the order settings.

Setup is Joomla 3.7.2 with VM 3.2.2, and PHP 7 with MySQL 5.6

Any ideas?

[Ghost]

Do you have any discounts applied?

[dslove]

No, no discounts are applied.

Also, all products have two prices, retail and wholesale.

[Milbo]

Dslove, the ordering takes the values stored in the db. But the price you see is dynamically calculated on your shoppergroup settings and so on.

[dslove]

Milbo thanks for the reply, what is your suggestion on the issue?

[jjk]

If you enable 'Sort by price' in VM configuration, VM sorts the cost price, because that is the only price stored in the database. All other prices are calculated. So if you want to sort by 'Final sales price', VM would need an additional temporary price table in the database. But that would not solve all possible price sorting possibilities, because there might be different taxes, discounts, shopper groups, child products, etc.

[dslove]

Hi jjk, thanks for the info.

There is only one active tax (24%), there are only simple products (no parents/children), there are no discounts. All products are available to same shopper groups, there is only a wholesale price for the Wholesale shopper group (this is on every product).

Here is a typical product ordering (retail prices/available to all):

• Product #1: Final Sales price: 900,00€ / Cost price: 725,81€
• Product #2: Final Sales price: 750,00€ / Cost price: 604,84€
• Product #3: Final Sales price: 950,00€ / Cost price: 766,13€
• Product #4: Final Sales price: 850,00€ / Cost price: 685,49€
• Product #5: Final Sales price: 850,00€ / Cost price: 685,49€
• Product #6: Final Sales price: 850,00€ / Cost price: 685,49€

As you can see, there is no logic in the sorting above 

[dslove]

It is the same in the back end too. Ideas, anyone?

[jjk]

Note that products should be sorted by the price which is stored in the database table. Looking through my product lists in the backend, I can see 'sorting issues' similar to yours, but I couldn't figure out yet why this happens.

[dslove]

• Product #1: Final Sales price: 900,00€ / Cost price: 725,81€ / MySQL price: 725.810000
• Product #2: Final Sales price: 750,00€ / Cost price: 604,84€ / MySQL price: 604.840000
• Product #3: Final Sales price: 950,00€ / Cost price: 766,13€ / MySQL price: 766.130000
• Product #4: Final Sales price: 850,00€ / Cost price: 685,49€ / MySQL price: 685.490000
• Product #5: Final Sales price: 850,00€ / Cost price: 685,49€ / MySQL price: 685.490000
• Product #6: Final Sales price: 850,00€ / Cost price: 685,49€ / MySQL price: 685.490000

These are all "retail prices", available to all shoppers. As I mentioned in an earlier post, all my products have a retail price and a wholesale price, available only to shoppers from a specific group ("wholesale shoppers"). JJK, does this also apply to your installation?

[jjk]

JJK, does this also apply to your installation?

No. I enter the actual cost price and let VM calculate the final sales price. Everything else doesn't make sense when you buy products from suppliers in different countries.
However, it makes no difference for the sorting issue, because VM sorts whatever is entered into the cost price field, which is stored in the database.

[dslove]

I have a separate set of wholesale prices for wholesale buyers because there is no standard way of calculating this according to cost price. Products different profit margins (e.g. anywhere between 10% and 30%).

[dslove]

So, we conclude that this is an unexplained, unfixable VM bug?

[jjk]

I'm sure it can be fixed. But we need to wait until a developer has been able to reproduce it and has identified the source of the problem.

[dslove]

I'm sure it can be fixed. But we need to wait until a developer has been able to reproduce it and has identified the source of the problem.

I'm willing to contribute to the solution of this issue by providing DB backups or whatever information is required.
It's a little embarrassing to explain the issue to the client, I hope it can be fixed soon...