Coupon System for Commerce

Hi amateescu

I create a new sandbox project. I like to collaborate with you. I would say that we create first the database structure and then we implement the features.

I have add the basic database schema. At the moment there are no restrictions on users, roles or products possible. Some question arises to me:

1. Should we use for the restrictions the rules module or should we create separate tables and implement this by ourselves?
2. Did we need coupon "types" similar to product types?
3. A nice feature would be the option to sell coupons on the website. A possible approach is using the rules module. When a new order is created with a certain product we create a new coupon and send the coupon code to the customer. Is this the right way or should we move in a different direction?

Are there any other use case, we should consider?

Im not sure how to approach such a functionality like UC Invite Discount. A possible approach can be to setup a rule, which checks if the buyer is invited by another user. (The linking between this user can be done by using the reference field.) If the buyer is invited a new coupon for the inviter is created.

My conclusion is that, we need a good integration with Rules, then we can accomplish many use cases.

Thank to all for all this response.

There are many use cases. I try to summaries them up here:

• Sell Coupons as products
• Marketing campaigns (need to be valid for certain products and time)
• Give Coupons away for inviting customer to buy something
• Order returns (filter for certain category)

I would say that a general approach is needed to accomplish the requirements derived from the use cases. Therefore I propose the following implementation:
We add a coupon type which is fieldable. In core we have only the field coupon id, the coupon amount and some admin information. All other data is stored in the fields. These date can be easily accessed by the rules. The rules can then control when a coupon is valid or not.

An example: Restrict the use of a coupon to a certain category
We insert a new coupon type called "Category restricted coupon". We add a field "category" to this type. The field can be referenced to the category.
We create a new coupon which is referenced to a certain category. The customer validates the coupon. Now we invoke a rule. The rule iterates over the products in the cart. Each product is check if the product is in the same category as the coupon requires. The result of this check is return to the validation method.

With this generic approach we can cover must of the use cases and we can easily extend it. It is also possible that we provide some default coupon types, which cover some of the use cases. The user can then see how the implementation works and can extend or modify the system as he needs.

Ryan thank you for your inputs.

I thought also some time about it. As you said, our target must be to build a basic module, that can handle some simple cases. But this module must be expendable to more complicated cases.

About your points:

1. As you said a coupon must have a status (active / inactive), an amount and a field that indicates if the amount is percentage or not. We need to divide it into two fields because in other case we cant use a float field for the amount.
2. I would link the order and the coupon by adding a new line item to the order. The line item is then linked with the coupon. Perhaps we should use for this a new line item type.
3. I will check the tax module for applying the coupon to the products.
4. Rules action is exactly what I would do. This action must be invoked when the coupon is validated. So you can easily control the validation process of a coupon. To give here more options I would provide a coupon type entity. This allows the filtering by other things like dates or users. A second action should be invoked after the validation for some post processing.

We have some more problems we did not consider yet:

1. When the coupon is bigger then or equals to the complete order amount, we need to enable a "free" payment.
2. When the coupon is bigger then the complete order amount, we need to store the rest of the coupon's value and reduce the next order of the customer by this value.

Are there any suggestions for implementing the above functionality?

So I think we have plan. We should implement in a first release the following functionalities:

1. Coupon Entity (fieldable)
2. Coupon Type Entity
3. Coupon Log Entity (for logging the use of a coupon)
4. Admin interface for all these Entities
5. A pane in the shopping cart / checkout page for redeem the coupon.
6. Validation process with rules integration.
7. Log the activities on coupons in to the Coupon Log Entity

In second release we can cover some additional functionalities, such as:

1. Batch coupon creation (this should not be so hard to implement)
2. Default Coupon types (Return Coupon, Marketing Coupon etc.)
3. Develop a "payment free order" module for Commerce (this should be moved into a separate project, because this can be useful in other situations)

We should discourse the "store credit" thing later. As Ryan said we should focus on the basic functionality in a first step. Is that all or should we add something?

Hi Idan

This would be nice, if you can create the free payment method.

I have check in a version that covers point #1 to #4 of post #15.

It would be nice if someone can review the code. Known issues:

• On uninstall: Fatal error: Class name must be a valid object or a string in ./includes/common.inc on line 7462
• Export / Clone does not work.

I have implemented the validation process with rules. Now I am at the implementing of the redeem process.

I studied the tax module as propose by Ryan. Now I have to following problem:

The hook_commerce_price_component_type_info() hook provides the possibility to add a price component. This price component is invoked for all order lines. For percentages coupons this makes sense. For fixed amount coupons it makes no sense, because you add it to the whole order or not at all.

So it would make sense to enable the price component only for percentage coupons. But this leads us to the next problem: When we have some special marketing event with 1000 coupons, we do not want to configure for each of them the price component. So we like to do it for the coupon type. When we do so, we cant set the amount type in the coupon, we need to set in the type.

My question is should we go this way and move the "is a percentage" coupon to the coupon type? Is it a good idea to derive the price component from the "is percentage" field?

Any suggestions are very welcome!

I have look more deep into the tax module and the way the tax calculation is handled. As my previous post shows we have a slightly different calculation for percentage and fixed amounts. The percentage could be implemented by the approach of the tax module, but for the fixed amounts we fail with tax approach.

So I look into the shipping module. There we have an approach which is for my opinion much better, because we can handle also fixed amounts. I do not want to implement two separated approaches for fixed and percentage amount calculation. This becomes to complicated for the user to handle.

Ryan, I know you know much about the Commerce Module. Can you state your opinion about this? Thank you.

There is already a project and some code:

Commerce Coupon

I promote the project to a full project. I don't put any release, because it is definitively not ready for production.

I would propose to discuss the next steps and implementation problems directly in the project issue queue. So we can discuss the different problems, bugs and task separately.

Currently the main issue for me is the implementation of the order total reduction: #1127588: Implementation of coupon redemption

The last commit of my module is ready for testing. Any feedback is welcome. Tomorrow a dev release is available. Know issues:

• Documentation is missing, will come soon.
• Code is not really good documented, will come soon.
• Add of coupon line item in the backend won't work. I need to think a bit about this.
• Double negative sign (see #1140908: Two negative signs in formatted negative currency amount)
• Default coupon types with appropriated Rules: Suggestions for default types (sub modules) are welcome.

I have add a new version. Here are the details: #1127588: Implementation of coupon redemption

If someone what to support the project, she / he is very welcome. Open issues:

• Write a documentation about how to use the module
• Testing
• Resolve some code problems (Marked as "TODO" in code)
• Code documentation

So if someone to pitch in, please let me know.