Add Coupon Codes Functionality

[eahefnawy]

I'll be working on coupon codes manager and tracker for Reaction. Here are the basic features:

• Create new coupons. Manage and edit existing ones.
• Coupons that provide fixed discounts, percentage discounts and free shipping.
• Start and end dates for your coupons.
• Track number of coupons used.

These are just off the top of my head. Anything to add...?

[aaronjudd]

@eahefnawy See #150 and #151 these are items I think should come before we start work on coupon codes, or any further pricing management etc.

Need methods for generating coupon codes and exporting them for embedding coupon codes in campaigns (email, promo banners, new user signups)

This would be both a generate on demand (api call) , or pre-generate a designated # of codes.

There are many additional coupon code / discount / pricing rule requirements:

• Allowed # of use per coupon
• Allowed # of use per user
• Active / Not Active status
• Start and End Date (not just date, but time with timezones as well)
• Valid regions (maybe valid in the US but not international)
• Per product, per tag (aka category) rules - ie: Only valid for "New" products
• No coupon code discounts (no coupon code needed / aka pricing rules)
• Can this coupon by combined with other coupons
• Rules / Conditions - both cart and product specific
• If x condition is true then apply discount/coupon (for example:
  - if cart is greater than $100
  - if product tag is "mens" and price is greater than "50"

We probably need need more of the shipping management and order workflow done as well.

[eahefnawy]

phew, good thing you told me early on. I was planning on working on the coupon codes and promotions packages, then go back to all of the packages I've written for refactoring and enhancements. But now I'll work on #150 and #151 instead before refactoring all my code.

But why exactly should they come before working on pricing? is it just a priority issue, or a dependency issue?

[aaronjudd]

It's more of a dependency issue for these to get done first. You could build this, but I'd expect major refactoring if you did. The things that are in the roadmap marked "beta" really should be the things that we are focusing on getting done first, to accomplish a MVP. Many of those items have dependencies that I've not scoped out fully in issues here on Github yet (there might be hints of these things in Trello though), but expect that we'll scope out prior to really digging into coding each item. So, basically the issues here with "Beta" marked on them are our next priorities - and I'm sure each will spawn several dependent tasks as we drill into them. You, or anyone, is welcome to develop stuff further out on the timeline, but just be prepared for lots of refactoring ;-)

[bstocks]

Still thinking about the most useful way to break this down into smaller tasks, but here are a few more requirements:

• Discount applies to an individual customer only
• Generate code or type your own
• For free shipping promotions, ability to limit by carrier/method
• Search promotions - allow admins to easily search/filter promotions
• Promotion description text field
• Promotion Notes - admins can add notes (not visible to customers) to a promotion for later review (such as why it exists).

It also seems to me that the full "rules engine" for promotions (ex: for users in Germany purchasing products in X tag with price < $100) might be overkill for the purposes of Beta, although it is a powerful/useful feature.

[okpatil4u]

We need this feature for our organization. Do you have any timeline setup for this issue ?

[aaronjudd]

@okpatil4u it's on the roadmap for our beta release, so this feature should appear in the next 1-2 release, however we've not begun work on it yet.

[okpatil4u]

How much time do you think it will take ?

[wuservices]

In addition to some of the use cases @aaronjudd mentioned, it should be considered how coupons will stack or override each other (eventually, maybe not in the MVP). For example, if you are able to stack discounts, if you have x $ off and then y % off, many stores take the $ off first, then take the % off. A simple way to be flexible here is to allow defining what discounts are combinable and then assign them a priority.

Automatically applied coupons are also important. Simple would be to have 20% sitewide sale that's automatically applied. More complex is to have automatic 20% off everything matching some criteria or free shipping for orders over $100. Using a priority system, the user could define how automatic promotions would interact with coupon codes the user has to enter.

Related to the above, a common use case is sending out one time use codes when you sell vouchers on deal sites like Groupon. Stacking (or the ability to restrict stacking) and priorities are especially important here.

Gift cards / vouchers may be somewhat related to coupons. They're basically a coupon but they have a stored value that can be used on multiple orders.

[mikewen]

Why not just implement simple flat dollar amount and flat percentage coupons first?

Coupon is almost a must-have for many stores.

[aaronjudd]

@mikewen agreed, and we're doing exactly that for now, eta release 0.13-14

[brent-hoover]

There's a lot of features listed in this ticket. For a first cut this is what I would suggest:

1. Simple dollar or percentage off
2. Allow for all or subset of products
3. Allow admin to set limit one per customer
4. Start and end dates
5. Attach description and disclaimer

Editorial Note My hard-won experience with coupons is that once you have a coupon promotion every customer (ok not every customer, just a few jerks) becomes a lawyer and jr. hacker and tries to exploit any weakness in your policy or the way your coupon is implemented, so we really need to make sure this is pretty bulletproof because customer don't tend to see these as just bugs but as you trying to rip them off.

[brent-hoover]

Version 1 of this started in #1512. Moved out of release in-lieu of that ticket.