On the product list administration page, I see a filter that contains "Top Ten", "modified", "Discountinued" and a few others. Consider adding a filter to view products that have a discount.
Marvays, you can create a module for other cases.
I sold a products module with many other filters here https://shop.st42.fr/en/products/products-any-ways.htm
Nice work. But I have in mind the administration of products. Not a frontend.
(https://i.postimg.cc/BjXD8LJ6/discount.png) (https://postimg.cc/BjXD8LJ6)
Hi Martine,
nice idea for custom programming - You can order a freelancer for this job.
We make such modifications for the client on demand as custom work ourselves - (delete customfields for discontinued child products, toggle for discontinued products, togle for featured products, info about imported products from feed/ERP, info about numbers of reviews for products) - see on the attachments.
Rudolf
Or create a vmextended plugin so you can add all filters you want.
Of course this can be included in core, but each shop need some other filters.
For a customer, he needed a order export per manufacturer by mail. I never requested it. Each shop work differently
Hi, for our tasks, I added new option to this product filter in backend - User (modified by).
Now I can filter products by editors.
It is very useful for us:
(https://inform-resource.ru/docs/share/virtuemart/screen-2020-03-05-08-34-59.png)
I think your task can be done by analogy.
This is a hack of 3 files VM.
I can share my decision.
nice :)
Quote from: marvays on March 04, 2020, 13:23:58 PM
(https://i.postimg.cc/BjXD8LJ6/discount.png) (https://postimg.cc/BjXD8LJ6)
If by "Discount" You meant "Overwrite final" in "Price" block, then this solution will work for You:
1) administrator/components/com_virtuemart/views/product/view.html.php
For $options array add last element ('discount' => 'Discount'):
$options = array( '' => vmText::_('COM_VIRTUEMART_LIST_EMPTY_OPTION'),
'parent' => vmText::_('COM_VIRTUEMART_PRODUCT_LIST_SEARCH_BY_PARENT_PRODUCT'),
'product' => vmText::_('COM_VIRTUEMART_PRODUCT_LIST_SEARCH_BY_DATE_TYPE_PRODUCT'),
'price' => vmText::_('COM_VIRTUEMART_PRODUCT_LIST_SEARCH_BY_DATE_TYPE_PRICE'),
'withoutprice' => vmText::_('COM_VIRTUEMART_PRODUCT_LIST_SEARCH_BY_DATE_TYPE_WITHOUTPRICE'),
'featured' => vmText::_('COM_VIRTUEMART_SHOW_FEATURED'),
'topten' => vmText::_('COM_VIRTUEMART_SHOW_TOPTEN'),
'latest' => vmText::_('COM_VIRTUEMART_LATEST_PRODUCT'),
'discontinued' => vmText::_('COM_VIRTUEMART_PRODUCT_FORM_DISCONTINUED'),
'discount' => 'Discount'
);2) administrator/components/com_virtuemart/models/product.php
Find "switch ($group) {" and put, for example, second case:
case 'discount':
$joinPrice = true;
$where[] = 'pp.`override` = "1" AND pp.`product_override_price` < pp.`product_price` ';
break;This should work ;)
Quote"Overwrite final"
This is legacy code and should NOT be used as it crashes with display of prices and VAT calculations etc.
Jörgen @ Kreativ Fotografi
Quote from: Jörgen on March 05, 2020, 21:39:27 PM
This is legacy code and should NOT be used
Jörgen, what code would you suggest as recommended?
:)
Quoteit crashes with display of prices and VAT calculations etc.
For product list filter in backend? Are you sure?
Using calculation rules is the correct way to ensure that invoices, discounts, shipment and payment processors will work. Depending on the overrite final is not the way to go. You may come up with a solution using this, but it will not play well with other calculations. The discount option in prices is a legacy setting from VM 1.1 that You should not use. Creating discounts should be done with calculation rules.
Jörgen @ Kreativ Fotografi
Quote from: marvays on March 04, 2020, 05:59:09 AM
Consider adding a filter to view products that have a discount.
marvays, how exactly do you assign discount to products?
Jörgen, thanks, I understand you roughly.
Quote from: Jörgen on March 06, 2020, 08:52:44 AM
The discount option in prices is a legacy setting from VM 1.1 that You should not use.
Should not use?
We use it very actively. I would be very sad if it was removed from VirtueMart...
For example, our products are uploaded from the crm system. Approximately 300 products from different categories participate in the sale (closeout).
And for each product - its own sale price (purchase price).
I can easily automate this by setting Override price for this products. That's all right.
If I have to do this through the calculation rules, do I have to create a rule for each product? 300 rules?
I think Override price is a very necessary functionality that is relevant! Don't leave it, please.
Why should You use 300 discount rules ? I use 10 %, 20 % and so on, very flexible in my oppinion. I use on a very modest number of products, just around 2000, It has some drawbacks regarding children but otherwise ok.
The override is from the very VM start and is certainly going to be more and more obsolete and hard to combine with other options.
Jörgen @ Kreativ Fotografi
Hi,
Ok,
I have products with final price
240
239
238
237
236
235
234
23X
..
200
I want her to adjust the price so that everyone has a price of 199 (psychologically for the buyer).
Do I really have to make a rule for every discount?
We use override price and import from ERP automatically. Maybe we are wrong?
@pinochico
Why you find always extrem cases ?
I wrote a price rule plugin for a customer that have discount groups per customer using an external tables.
Of course in some case, core calc rules is not the best solution ! But this not mean that you should not use it, if it's possible
And of course if each product have own rule, then it's better to override the price manually
And perhaps your case can be solved using a plugin, if you apply similar rules(here price = 199) to products so you can remove it without manually update each price
I think this is not an extreme case.
I have a similar situation, only a little different.
The stock price is independent of the regular price. Therefore, percentages or + - are not suitable.
The stock price equals the purchase price. For each product, it is unique.
It must be specified for each product.
Rules are not suitable for this.
Quote from: Jörgen on March 06, 2020, 12:55:37 PM
Why should You use 300 discount rules ?
Because, as I wrote above, for each product - its own sale price (purchase price).
Common rules do not fit.
If there is no Override price in Virtemart,
then the only solution to the problem will be two prices for each product (prices depending on conditions).
This is also an acceptable solution, but these are redundant entries in the database that can now be avoided due to override prices.
This looks more like custom version of The Rappenrundung, a job for a custom calculation plugin. Or importing the prices through Excel. Afaik this is not possible with standard calculation rules. Max has some extensions touching this area. Check with him.
Jörgen @ Kreativ Fotografi
Jörgen, yes, I import data from Excel or CSV or XML. I have no problem with this. Everything is configured and everything works.
We also export data to some major services.
The only question is, now I calmly use the Override price for products on sale.
But you wrote that this is not a recommended solution.
And it bothers me that someday (with one of next updates) override prices will no longer be supported. I would not want that.
The solution I use is the "old" price ( in our case Recommended Retail price" ) we store in the Override price field but in config this is disabled
Then the "sale" or "reduced" price minus Vat is the base price
The price displays are adjusted to get the desired rendering
This way we can quickly adjust the "retail" / "sale" price (the base price) by import, this price we can make "pretty" and any tax/discount/coupon/quantity pricing etc adjustments work correctly
@patrick
I'm sorry Patrick, but I use examples from real ecommerce life.
We do not use VirtueMart as a play the game, but as a competition to large ecommerce solutions (Shopify, Shopsys, Magento) and if I am looking for a solution, I am looking for a system solution solution == I have to consider all the real eventualities required by e-shop owners.