Closed natalyaholyk closed 4 years ago
Hello,
As I said to you in the Sonata mailing list, we are indeed planning on developing a discount or voucher feature on the e-commerce solution.
Feel free to comment on this to add your insights.
Regarding the features this would cover:
[ ] "Coupons" or "Voucher" management
The user can add a code when checking out the basket that will apply a discount based on customizable/administrable business rules.
[ ] Discounts on a specific product
A percentage or value discount is applied to a product.
[ ] "Package" or "set" discounts
A discount is applied for a set of products (only if the customer has all the products of the set in its basket).
All discounts should be dependent of customizable/administrable business rules (for instance a limited duration).
Regarding the implementation, discounts should be represented as basket elements (hence then transformed into order elements and invoice elements).
We could have Discount
extend the Product
model, but I fear this would cause too much complexity.
I think Discounts should be placed in their own bundle (DiscountBundle
?) inside the ecommerce package.
@rande whenever you got time to give us your opinion on this.
Any news about this feature?
+1
Any updates on this?
+1, any updates ?
Sylius approach : https://github.com/Sylius/Promotion Demo : http://demo.sylius.org/administration/promotions
Hi guys, I was thinking about doing something along these lines, like, right now... Anyone tackled this already?
Not on my side. We have finally started our project with Sylius.
OK... so here's the plan: A Discount would have the following properties:
Implementation: Main stuff would be inside a DiscountBundle/Entity/Discount. Will probably need a DiscountElement also, because we want to enable a multiple-use discount.
This functionality will also require an update to:
Comments, anyone?...
...actually, IMHO, the strategy of using data transformers to produce an order out of a basket is fundamentally flawed. And it clearly shows it is flawed when you try to do something like this (promotions). Conceptually, a basket is NOT the same thing as an order, because there are calculations you can only make final at the exact moment the order is placed: taxes might change, coupons/promotions might have expired, prices might have changed, items may not be available any more, items might have to be shipped separately, etc. What you do in the order process is not the same thing as a "data transform" (which is what the data transformers were designed for).
Hello, a property that we often need :
But you should not implement all kind of discount in first place, a rule engine is a better option imo. It's probably what you think about.
Something where each rule is a separate class wich implement a simple interface so anyone can extend it. With at least a trigger function and a modifier function per rule.
Thanks for the input @pierrerigal. That's a very interesting option, but what do you mean by modifier?
"Modifier" is some french with an approximate to_en() implementation :) This is more the "run" part of the rule.
Eg Rule : free delivery if you buy gold pack
Trigger : 2 items A and 1 item B in cart (gold pack) Run : set delivery to 0
The rule engine will loop over triggers and if one is true it will apply the run() method.
You'll need per rule :
Ah bon! C'est ça! Well, I think you're right on the money (pun intended), though I don't think we need the active/inactive there: you either have the rule or not. I'm thinking about implementing this with 4 entities:
The "Promotion" will hold the specifics of the promotion, including a collection of rules. The "Coupon" will basically hold the coupon codes for promotions based on coupons. And the "OrderDiscount" will account for the effective discount that will be applied on the order and invoiced.
After giving it further thought, I think it is OK to keep the Basket->Order->Invoice transforms, and have the Basket hold what can be considered "Eligible discounts" before the order is placed, which will become "OrderDiscounts" the moment the order is placed. These "freeze" the discount, with all necessary data for invoicing and future reference. That means "OrderDiscounts" should be completely self-sufficient, so that erasing the related promotions doesn't have any side effect on this data.
So, the story so far...
Features we want to enable:
Implementation: Details are still sketchy, but we'll use a strategy pattern for implementing promotion rules. I've taken a peek at how sylius implements this, but I find it a bit over the top. Same functionality can be achieved with less complexity and still be kept clean.
Entities: Promotion [PromotionInterface]:
PromotionRule [PromotionRuleInterface]:
Coupon [CouponInterface]:
Discounts [DiscountElementInterface]:
Comments anyone?
1 comment : good luck :)
thanks
@travisbickle , I know that this is an old issue... did you made something about coupons and discount?
Sorry @Filoz , but no news. I should add that I found the documentation for contributors extremely confusing/outdated. I did not proceed with this for other reasons, but that was a real hindrance, otherwise I would have made at least 1 PR.
I should add that I found the documentation for contributors extremely confusing/outdated. I did not proceed with this for other reasons, but that was a real hindrance, otherwise I would have made at least 1 PR.
Are you referring to https://github.com/sonata-project/ecommerce/blob/2.x/CONTRIBUTING.md ? If yes, ouch, and how can we improve it? What is outdated specifically in it? and what did you find confusing?
I am probably outdated myself... This happened a year ago. I would have to do a recap. I remember there was a serious mismatch between documentation and the sample project. I will look again when I have the time and report back to you on a more proper thread.
Thank you 👌🏻
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
Hi I want to know more about the possibility of developing Discount cart for e-commerce project. If it possible :) Maybe I can be useful. Do you already have any idea how this cart can be implemented? Thanks :)