[RFC] Discount Cart for e-commerce

[natalyaholyk]

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 :)

[Bladrak]

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.

Functional description (WIP)

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).

Technical implementation (WIP)

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.

[maxpowel]

Any news about this feature?

[afurculita]

+1

[ghost]

Any updates on this?

[prigal]

+1, any updates ?

Sylius approach : https://github.com/Sylius/Promotion Demo : http://demo.sylius.org/administration/promotions

[travisbickle]

Hi guys, I was thinking about doing something along these lines, like, right now... Anyone tackled this already?

[prigal]

Not on my side. We have finally started our project with Sylius.

[travisbickle]

OK... so here's the plan: A Discount would have the following properties:

• Subject of the discount (item, group of items, whole order)
• Discount operation (multiply or subtract, i.e., percentage or absolute value)
• Discount operator (e.g., "0.5" for a 50% discount, or "20" for a $20 discount)
• Discount limit (to set an absolute limit on percentages)
• Start date-time
• End date-time
• Available uses (number of times the discount can still be used, to enable stuff like "first 10 orders get xxx")
• Discount type ("coupon" or "promotion", for site-wide discounts)
• Coupon code
• Status
• Short description
• Long description

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:

• BasketTransformer
• InvoiceTransformer
• OrderTransformer ...because the business logic for calculating the order/invoice total will have to take the discounts into account.

Comments, anyone?...

[travisbickle]

...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).

[prigal]

Hello, a property that we often need :

• available uses per customers

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.

[travisbickle]

Thanks for the input @pierrerigal. That's a very interesting option, but what do you mean by modifier?

[prigal]

"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 :

• an active/inactive switch,
• an order (rule G can be ran before rule C),
• a stop_now switch which force the rule engine to stop looping over rules because some rules must be exclusive.

[travisbickle]

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:

1. Promotion
2. PromotionRule
3. Coupon
4. OrderDiscount

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.

[travisbickle]

So, the story so far...

Features we want to enable:

• Coupon-based promotions
• Site-wide promotions (no coupon)
• Credit-based discounts ("$20 off")
• Percent-based discounts ("10% discount")
• Time-limited promotions ("black friday sale: 20% discount")
• Use-count-limited promotions ("Big opening: first 100 customers get 50% discount")
• Discounts can be applied before or after tax
• Discounts can be applied to the total without shipping
• Discounts can be applied to the total plus shipping
• Promotions can give free shipping regardless of everything else ("Big opening offer: first 100 customers get 50% discount plus free shipping worldwide" )
• Promotions can have a limit on the net discount offered ("20% discount limited to a maximum of $1000 off")
• Promotions can use different rules (strategies) to determine the discount based on different objects and properties. Some examples:
  • 20% off your 1st purchase
  • Better together: buy A + B and get $10 off your order
  • St. Patrick's day promotion: 5% discount on all green products
  • Get 3 gizmos for the price of 2
• Promotions can stack up or be exclusive
• Promotions that stack up will have a priority setting
• Promotions should be lunacy-proof (never allow ending up with a negative order total!)

[travisbickle]

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]:

• startsAt (Datetime)
• endsAt (Datetime)
• status (enabled | disabled)
• maxUseCount (int)
• currentUseCount (int)
• countBy (customer | site)
• rules (PromotionRuleInterface collection)
• exclusive (bool)
• priority (int)
• maxNetDiscount (float)
• applyTo (totalExc | totalInc | deliveryCost | all)
• freeShipping (bool)
• createdAt (Datetime)
• updatedAt (Datetime)

PromotionRule [PromotionRuleInterface]:

• Promotion (PromotionInterface)
• ruleStrategy (string)
• args (array)
• designation (string)
• description (string)

Coupon [CouponInterface]:

• Promotion (PromotionInterface)
• Code (string)
• ExpiresAt (Datetime)
• Status (enabled | disabled | canceled)
• maxUseCount (int)
• currentUseCount (int)

Discounts [DiscountElementInterface]:

• Order (OrderInterface)
• Promotion (PromotionInterface)
• CouponCode (string)
• Designation (string)
• Description (string)
• ComputedValue (float)
• ApplyTo (totalExc | totalInc )
• freeShipping (bool)

Comments anyone?

[prigal]

1 comment : good luck :)

[travisbickle]

thanks

[Filoz]

@travisbickle , I know that this is an old issue... did you made something about coupons and discount?

[travisbickle]

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.

[greg0ire]

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?

[travisbickle]

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.

[OskarStark]

Thank you 👌🏻

[stale[bot]]

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.