Promotions: Catalog price rules

[kooliahmd]

Currently, it's not possible to create a promotion which can be communicated before checkout and show the discount price in this pages :

• product sheet
• search
• product listing
• HP

See Magento doc: http://docs.magento.com/m2/ce/user_guide/marketing/price-rules-catalog.html

I'm not sure if this feature is already scheduled in the road map, however, I'm ready to give it a try and contribute.

[gabiudrescu]

I strongly support this feature.

I am offering to conduct the discussion about behavior. My vision about this concept coincides a bit with this feature from OroCommerce: https://www.orocommerce.com/blog/price-list-management-in-orocommerce; ignore the part where the price changes based on qty - I don't think this is mandatory for the basic version.

there should be a collection of SKUs, with a start and end date. between that interval, the pricing of the product should be taken from this list. otherwise, it should be the default pricing of the product.

wdyt?

[kooliahmd]

There is already a rule engine implemented by the sylius promotion component. but it should be reviewed in order to be useful for this feature. For example : delete rules who are triggered by order or customer related data. and concerve only rules who are triggered by product data (ex: product's taxon is books)
The challenge is to be able to go through this rules and to calculate the promotion price without affecting the performance.
Magento 1.X have a scheduled cron who do this job periodically, and save the promotion price in the DB, then the web application just consume prices from DB and don't do any further calculation.
I think Sylius don't support cron jobs so the calculation should be done each time on the fly during the http request. Doing that without reducing performance is hard.

[gabiudrescu]

I wouldn't go first time in the logic of doing promotions based on rules for product listing.

on the other hand, I now realize that pricing is on channel + product; this means that some of the logic of having multiple product prices in the product listing is already in place.

lets start from the business value: what do we want to do?

imho, we need this:

• have /listing/books with 2 products - each cost 100€
• between now and tomorrow at 2pm the products will cost 50€ (just because I say so)

the price assignment could be done manually (at first) in a key value pair:

• key: SKU
• value: new price

I call this concept pricing list;

when we become fancier, we can set rules, like: add 10% discount on this specific subset of products; or add a flat 10€ discount.

[gabiudrescu]

and Sylius supports crons. crons are just CLI commands that are run by the system at a specific time.

[psihius]

@gabiudrescu but Sylius promotion rules support so much more. You can set up a whole taxon to have discounts for example - meaning everything under that taxon now is going to be discounted. That can be a few hundred products - you really do not want to do all that by hand. Right now I'm thinking that probably having a command that goes through and updated the pricing according to the promotion rules on per channel basis is the correct one.

[pjedrzejewski]

We have implemented a plugin, which provides exactly that, catalog promotions with rules engine similar to what we have in the core. Hopefully we will be able to release it, right @klederson? :)

[psihius]

@klederson @pjedrzejewski may I humbly request doing it sooner than later? :) I'm deploying a shop in 2 weeks, I would very much would like to use the plugin then and contribute into it than doing my own thing here 👍

[gabiudrescu]

@psihius we update prices on our website based on CSV upload with 2 columns:

• variant code (SKU)
• selling price

we can automate that, but it's in our backlog. quite low priority, as you can imagine.

anyway, if there's a plugin that can use rules and it was simple to be implemented, well that's great 😁 looking forward to seeing it

[psihius]

@gabiudrescu you have a completely different approach - you have people who do the pricelist and discounts on per product basis. The plugin and the way I talked about is targeting a use case when the shop itself defines via promotions what has discounts and what does not. It can be SKU based, or can be Taxon based. Or being targeted at a specific zone only. And so on.

[kooliahmd]

@pjedrzejewski
I'm ready to create this plug-in during this week if there is no body else currently working on it.
My idea is to reuse the core promotion engine, and to keep from it only the rules/actions applicable on a product context (no order, or customer) , then admins will have the ability to define flexible rules (sku, taxons,dates or what ever ) applicable on catalog.

Since the interpretation of this rules is heavy, the calculation of new prices shouldn't be done during the http request, discounted prices should be calculated by a cron process (or fired by administrator action from BO) in order to update them in DB.
The update of prices action can be added to sylius command utility also.

[wadjeroudi]

@Snake-Tn Did you start your plugin ? Thx.

[kooliahmd]

@wadjeroudi Yes I'm currently working on it, it should be done soon:
https://github.com/Snake-Tn/SyliusCatalogPromotionPlugin

[kooliahmd]

@pjedrzejewski , I finished a plugin for catalog promotions : https://github.com/Snake-Tn/SyliusCatalogPromotionPlugin

[gabiudrescu]

congrats @Snake-Tn for making this. I'm sure it's going to be a very popular plugin for Sylius, as it solves a very important business need in a way that ensure lots of flexibility for innovation.

where may I add some improvements suggestions? here or as a issue on the plugin?

e.g: going on the admin view product page there is a price, while viewing it on the website product listing - there's another price; I would solve this by adding an extra field on the admin product page view / edit form.

[kooliahmd]

@gabiudrescu , thank you, please feel free to create any issue in plugin repo. I will gladly treat them.
also any MR is welcome.

[stale]

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in a week if no further activity occurs. Thank you for your contributions.