Store credit coupons (gift certificates)

Sorry I haven't had more time to look at this in detail. Just gave it a quick glance this morning.

Off the top of my head - I'd rather see this made into a submodule, so the core uc_coupon code doesn't have to be modified. We can add hooks as needed to accomplish this. In this case, not sure what I think about adding a column to the coupons table for uid. Maybe better to create a new table, which could hold store credit as well, rather than altering the $coupon->value field (which would lose track of the original coupon value).

In fact, what if a gift certificate is essentially a normal coupon which, when redeemed, adds a row to the new table with the amount of store credit, which is then managed separately? We could add a field to the $coupon->data array which marks a coupon as a store credit certificate. This could be redeemed either at the /redeem link or at checkout - if the latter, the surplus (if any) would be associated with the new user in the new table. This would also allow bulk coupons to be used as gift certificates.

If we wanted to get fancier, the new table could link to the original coupon (or to a new "inactive" coupon cloned from the original), and then all the restrictions could come into play (e.g. one could offer store credit that's only valid for one type of product, or to users with a particular role).

As for assigning purchased gift certificates directly - do you think the purchaser should be able to e-mail a code to the intended recipient, or have the credit assigned automatically (so the intended recipient doesn't have to enter a code at all). Would it be better if the recipient doesn't have to be a registered user (i.e., the credit is associated with the coupon#, not the user?).

These are just quick thoughts - afraid I won't have much time to look at this closely for at least the next few weeks.

Unfortunatey, I won't have much time to give to this for the next few weeks...

Question: does this module give the ability to define fixed-amount coupons which are applied AFTER tax and shipping is calculated, which (unless i am wrong) can't be done with the basic uc_coupon module?

i could apply the diff and test this out myself, to find out this answer, but just in case someone who knows is online today and can answer this for me, i'd sure like to know!

cheers
Peter "Fish" Fisera
Earth Angel Consulting

@wodenex or @SeanA,

I am working on a site and one of the requirements is gift certificate very much like the one outlined by wodenex in #4 above. I have a little development budget I can send your way if you are interested. Here are my thoughts:

In fact, what if a gift certificate is essentially a normal coupon which, when redeemed, adds a row to the new table with the amount of store credit, which is then managed separately?

Sure, as long as it is of the same type as the bulk coupons and the codes are restricted to one-time use.

do you think the purchaser should be able to e-mail a code to the intended recipient, or have the credit assigned automatically (so the intended recipient doesn't have to enter a code at all)

In my opinion, I think it would be better to mail the recipient a "certificate" – actually a slightly themed e-mail that includes the amount, the code , who it's from and their message. (I suspect this is more than what you initially had in mind. I may be able to pitch in on theming and generating the email.

Would it be better if the recipient doesn't have to be a registered user (i.e., the credit is associated with the coupon#, not the user?).

The first one please! One of the reasons you want to make gift certificates available is to get your current user-base to entice their friends to try (and then register on) the site.

By the way, I am aware of the UC Gift Certificate module, but it doesn't operate as outlined above AND there seems to be some unresolved issues with the redemption value not actually getting deducted which cause me some concern. See" http://drupal.org/node/927702.

So if you have an idea of how much time and money it might take to develop this feature, please let me know.

Thanks,
Jerry

just confirming... i applied the patch from #1 to the 6.x-1.x-dev release from Feb 28, 2011 and it worked, the only update that fails is in a documentation header, but all code seems to upgrade correctly.

and after quick testing, looks like it does everything that it is supposed to. THANKS for this, Sean A !!!

note: do NOT try the patch against 6.x-1.5, it will for sure fail (i already found that out)

cheers
Peter 'Fish' Fisera
Earth Angel Consulting

I plan on putting users' store credit balances on their own admin page.

This is a great idea. Would this be a section under the user's page so it would appear like their "Wishlist" or their pending orders?

On the other side, what mechanism do you have in mind for buying these gift certificates? Is it possible to make these available in the store like any other product?

Had a few ideas about this.

- Have you looked at uc_store_credit? I just glanced at it, but it seems one option might be to integrate with that module - i.e. simply to create a coupon which, when redeemed, assigns store credit as defined there, and then let that module handle the rest of the bookkeeping.

- If we don't do that, I think It's better that the credit be associated with the coupon code rather than the user. That way, admins would have a choice whether or not to require that an account be created in order to have store credit. We'd add a coupon option for non-% coupons which allows only a portion of the value to be applied to the order - I guess, when you enter the coupon code, it adds to the total in your store-credit pane.

- In that case, I'm not sure there's a need for an extra table after all. The total value remaining on the coupon could be calculated from the uc_coupons_orders table. but note that however we do it, the value needs to be per-code, not per coupon, in order for bulk coupons to be handled correctly.

@mcfilms - i presume they would be purchased the same way any other coupon is purchased - via the uc_coupon_purchase sub-module.

Also, in the second scenario above, it would perhaps make sense to use the standard uc_coupon_purchase method for linking coupons to users - could modify the uc_coupon_puchase user screen (at /user/%/coupons) to show the available credit for each coupon. Finally, if desired, could have the option to auto-apply such coupons for any user who owns them. Could also alter the uc_coupon_purchase process to allow the coupon to be assigned/e-mailed to another user (or another e-mail address) as SeanA describes above.

Is there any way to get this updated to either work with 1.5 or the latest dev release? I just tried installing this patch on the latest dev release and get a myriad of errors on top of the codes not redeeming.

Subbing!

This sounds a bit overly complicated for a gift certificate system to me. If I buy a friend a gift certificate for my local Myer Department Store the credit is attached to the certificate, not my friend. When they show the certificate at the store they can redeem part of the certificate value and will still be able to go back on another day to use the rest of the certificate value. They can also give the certificate to a friend to use, which doesn't need to worry the store owner because the credit has already been paid for.

Based on this model, I think uc_coupon could be updated to support a much simpler gift certificate system.

Firstly, obviously only a fixed priced (i.e. not percentage) discount coupon could be enabled as a gift certificate.

Then, when a coupon is used the redeemed value is subtracted from the coupon value. This continues for subsequent redemptions until the coupon value reaches 0.

This much should be fairly simple, improvements would be:
1. Track both the original certificate value and available credit
2. Add an extra email field to the checkout so the customer can specify their friend's email address to send the coupon to. Sure, the friend needs to be notified, but they don't need to have an account and the coupon credit doesn't need to be locked to that one user.

I think being able to offer store credit was a big part of the purpose of the OP's patch, but I like the simplicity of this. As you say it would be pretty easy to implement - the recipient's e-mail could just be a product attribute, and the remaining value of the coupon could be determined dynamically by querying the coupons-orders database. Not sure when I'll have time to get to this - if you want to submit a patch, I'll review.

I use this module http://drupal.org/project/userpoints_ubercart instead of store credit.

Agree with #16. I love this module and fixed value coupons that you could use multiple times would be great...

See also #1434422: Maximum Redeption Value for Coupon for a slightly different approach.

Attached patch is a rework of that at the other linked issue, and implements something like #16. Please test...
(Bumped to 7.x as that's where new features will be implemented first -- if it works, I'll mark for backporting).

Thanks!!

Looking forward to a D6 backport....

Revised version is a bit cleaner, I think. Please test this version not #22.

Fixed a few bugs and ported to D6.
Need testing and feedback before this can be committed.

1064406-store-credit-D7.patch

Tried this with -dev. Fubar. Has email headers in it, and even stripping them out, it hangs patch (and patch -p1), so email left other chars as well?

Please re-roll and indicate which patch flavor you're using?

(PS: Is -alpha6 functional at all? If not, can we drop it, delete it?, as drush downloads it by default, which I keep forgetting, and then I have to rebuild that test area to clear out -alpha6 cruft.)

###

My votes for functionality:

assigning gift cerificates to another user ... If the user doesn't exist, a new user is created

I would be against this, as most people have multiple email addresses, this creates problems of having to build functionality for re-assigning credits between user accounts. My vote is if a user doesn't exist, a coupon is emailed to the recipient.

Have you looked at uc_store_credit?

Ryan doesn't work on Ubercart anymore, so the module is effectively dead (and it's only D6).

modify the uc_coupon_puchase user screen (at /user/%/coupons) to show the available credit for each coupon.

I plan on putting users' store credit balances on their own admin page.

Finding your credit balance on your coupon tab will probably baffle the average user (especially if it's listed as a coupon too), and lead to extra support calls for the store owner.

A block could be placed on the top of the /user/[uid]/orders. But, a) again it might baffle the average user, and b) I'm never fond of rewriting others forms.

In the grand scheme of things Ubercart, there should be a single tab on the user account for all UC items (orders, coupons, addresses, account balance, etc.). But, since that's not going to happen, for the moment, what about any of these options?:

1) Add another tab to the User account: "Account Balance"
2) Re-name the "Coupons" tab to "Balance & Coupons." Just the tab name, leave the path alone.
3) Move towards the master tab concept by creating a tab "Store information" (*) and sticking coupons and account balance in it. [*Needs a better tab name.]

On 3) we could probably easily co-ordinate with uc_addresses and get Youri (MegaChriz) to move his tab there as well. Have to research it, but we should be able to do a "if (master) tab exists" put this modules tab under there? Or at least come to a defacto standard name for the UC master tab and use it like people use /users/[uid].

where to store the account balance?

Is it off limits to attach it to the user object? Hide it? Make it an admin field? Okay, I don't remember all the user field options, but I'm reasonably sure it can be stuck there safely and securely. Having it in an easily identifiable place will also allow easier migrations.

But, there will also need to be an account balance transaction table. Doesn't have to fancy, but does need to exist, so the store owner can track who/what caused balance changes.

#16 vs. #18

There is a use case for both, but these are (for the most part) on-line entities, which makes "having the credit attached to the account (once redeemed)" the more normal usage (as there isn't a physical card or physical store to walk into). Like Sean, this is a required feature in my client's implementation.

Best,
Sam

Not sure why you're having trouble with the patch - is standard format from git --format-patch and works for me; but here's a version made with git diff in case that works better for you (this one excludes the new tests subfolder, since that's really a separate thing). Like all git patches this should all be applied with -p1 from the us_coupon directory.

alpha-6 is very much operational - there have been only one or two additions to the dev branch. The main issue on my agenda is fixing the views support which is broken in several places, and I'd like to get that done and reviewed before cutting another release.

Regarding the functionality - I've taken the direction outlined in #16 -- the other approach is significantly more complicated, and I'm not sure it's really in the same realm -- i.e. store credit attached to a user account doesn't really have anything to do with coupons anymore, and should probably be a separate module.

If at first it doesn't work, reboot. (working on a CentOS box, guessing it's not that happy at being a workstation)

store credit attached to a user account doesn't really have anything to do with coupons anymore

If you want to limit the scope, then uc_coupon is probably not the place to be doing store credits or gift certificates, as a standard user would reasonably expect an account balance type function upon redemption.

Obviously your call if you do or don't want to expand uc_coupon to include that.

# # #
On this patch, the coupon created was GIFTCARD50, $50, Coupon is active [checked], Store Credit [checked], the rest were left at default. This produces results I don't understand (not to mean they aren't correct, I'm probably missed something in the usage). I can't seem to find a way to purchase it, it isn't listed on the /admin/store/products/classes, doesn't have an entry in /admin/store/products/view, doesn't seem to create a catalog entry.... How do I make it buyable?

Next, on the /cart page (2 items in cart, Subtotal: $207.39), I can enter GIFTCARD50 and it creates a line item Coupon GIFTCARD50, "-$41.01" Which is odd, I never bought it, so how can I redeem it? And why is it not for $50 (or even 50%)?

So doubly (triply?) stumped.

# # #

Is this patch a clean up / re-work / continuation of #1? If it is I've completely missed something.

Best,
Sam

a standard user would reasonably expect an account balance type function upon redemption.

That may be true, but again this is intended to implement the suggestion in #16 - the credit is tied to the coupon, not the user -- analogous to taking a gift certificate to a store, using part of it, and walking away with another gift certificate reflecting the reduced value.

I can't seem to find a way to purchase it,

You need to use uc_coupon_purchase for that.

I never bought it, so how can I redeem it?

Again, since you marked the coupon as active, it is active. With uc_coupon_purchase you create an inactive coupon which is used as a base or template for the purchased coupons. New active coupon codes with the same characteristics are created when purchased.

And why is it not for $50 (or even 50%)?

That I can't reproduce - when I do what you said the coupon line item shows as $50. Is it possible that you previously applied the coupon to a smaller order, so what you're seeing is the remaining value?

Is this patch a clean up / re-work / continuation of #1? If it is I've completely missed something.

Nope - completely different approach based on #16.

Here are some thoughts for extensions/enhancements of this approach:

1. Provide an option to automatically assign a store credit coupon to a user when it is redeemed. This might be an easy way to have something like store credit assigned to an individual user.
2. Provide a way to have the coupon sent to a third party when it's purchased. This is essential for the gift certificate model.
3. Provide a way for a user to apply only a portion of the coupon value to an order. As it is, the full coupon value is applied (up to the order value). This is a little trickier, because it involves adding a form wherever coupons can be applied.

Thanks for your input on this!

when I do what you said the coupon line item shows as $50. Is it possible that you previously applied the coupon to a smaller order, so what you're seeing is the remaining value?

No, never actually applied it, as I never went through full checkout. But I didn't have uc_coupon_purchase installed?

/admin/store/coupons/1

Name	GiftCard50
Status	Active
Code	GIFTCARD50 (Print)
Maximum uses	1
Discount value	$50.00
Applied to	Order subtotal
Allowed Combinations	None.

uc_coupons "Ubercart Coupons" (only record)

cid 	name 	code 	value 	type 	status 	valid_from 	valid_until 	max_uses 	minimum_order 	data 	bulk 	bulk_seed 	created
1 	GiftCard50 	GIFTCARD50 	50.00 	credit 	1 	0 	0 	1 	0.00 	a:3:{s:11:"bulk_length";s:1:"8";s:8:"apply_to";s:8...	0 	977792b3a9818469d6ab724115abb628 	1331841126

cut that field off:
a:3:{s:11:"bulk_length";s:1:"8";s:8:"apply_to";s:8:"subtotal";s:22:"purchase_suffix_length";s:2:"12";}

I can un-apply and re-apply and it still stays the same 41.01. But don't sweat it, if your install is saying it's okay, it probably is, this install I'm duping for testing has been hacked on too much. I'll re-do the test w/ a clean build and uc_coupon_purchase on ~Tuesday.

And in the mean time I'll think about what the requirements for a store balance are, as a separate module w/ api's to call that handle the transaction db, etc. sounds like the proper route.

Best, and have a good weekend,
Sam

New version of this feature for D7, includes:

-ability to have customer specify a recipient email address for a purchased coupon (enable this feature on the coupon module settings page, then add the uc_coupon_purchase_recipient attribute to a product which has coupon-creation as a feature).
-allows applying a store credit coupon even if no applicable products match
-display remaining credit next coupon name
-allow credit (and other types of coupons) to apply to line items (e.g. shipping) as well as products.

Please test and report any problems.

Hi guys,
first of all thanks for this patch :).
Second, I've had same issue as Sam-Inet. in D6 patch version.
Apparently, coupon that is of credit type hasn't been used on any previous orders, so it has its full value.
But somehow, when I apply it, and then change the quantity of same product ( even two different products) in cart,
there should be logically proportionally calculated and assigned discount which from all has sum equal to total coupon value, but
it happens not like that.
Let me describe it:
I have one product with qty=1, I apply coupon credit = $5, and it subtracts from product's price.
But then, when I change qty to 5, it should be proportionally calculated as 1x5 = 5 but it comes out as 0.4096x5= 2.048.
So I looked at patched module, and got to function uc_coupon_calculate_discounts() from line # 748 to line 757#

if ($coupon->data['apply_to'] == 'subtotal' || $coupon->data['apply_to'] == 'products_total') {
          // Apply single discount proportionally across all qualifying items.
          $item->discount = $total == 0 ? 0 : min($value * $item->price / $total, $item->price);
        }
        else {
          // Apply discount to each product's untaxed price.
          $item->discount = min($value * $item->price / $item->altered_price, $item->price);
        }
        if ($coupon->type === 'credit') {
          $value -= $item->discount;
        }

this

$value -= $item->discount;

seems odd to me.
because each new step in iteration, value for credit is reduced with discount for item,
that is previously calculated using $value.
so this is how it's changed

1 - item #1 discount 
4 - coupon credit value after subtraction of item #1 discount 

0.8 - item #2 discount
3.2 - coupon credit value after subtraction of item #2 discount 

0.64 - item #3 discount
2.56 - coupon credit value after subtraction of item #3 discount 

0.512 - item #4 discount
2.048 - coupon credit value after subtraction of item #4 discount 

0.4096 - item #5 discount
1.6384  - coupon credit value after subtraction of item #5 discount 

So finally this value 0.4096 is stored in $item->discount and we have $2.048 total instead of $5 total :)

Correct me if I wrongly interpreted purpose of coupon credit type, but this is odd to me :).
Also, when is new d6 version patch to be available?

Thanks!

Eyah - that's a bug - thanks for identifying it.

Revised patches for D6 and D7 attached.

I have also created new feature branches "store-credit-6" and "store-credit-7" to track development of this feature, so it should be possible to pull directly from the git repo rather than reapplying the patch every time there's a change. I will delete those branches once this is fully tested and merged into the main branches.

The new functionality for D7 in #32 was a sponsored feature. I will backport to D6 when/if I have time.

*** EDIT: DO NOT USE THESE PATCHES: The most current versions for both D6 and D7 are available directly from the store-credit-6 and store-credit-7 branches in Git.

Thanks very much wodenx :)

Thanks wodenx!!

Any features you backport to D6 would be much appreciated!!

D7 Update: Don't use the patches in this thread - instead pull the latest version from the store-credit-7 branch of the git repo. Too many changes to cut a new patch each time.
D6 Update; Some feature backports should be coming this week.

Great... thanks!

Application of discount to line items has been backported to D6. Again, pull latest code from the store-credit-6 branch.

That's very exciting! Thanks wodenx!

One question. Do you think I need to create another copy of my site to test this feature? Does it have upgrade SQL scripts that can't be turned back by putting back in the older version?

Cheers,

Should be ok. I'd backup your db just to be safe, and def. test in a dev environment before deploying to a live site). Also, if you create new store credit coupons and then revert, you may have issues because the old code doesn't recognize coupons of type 'credit'.

Gocha!

Thanks... I will give it a test.

This is all great stuff, but I was wondering if there has been any further progress on the backport to D6? If not, how can I help?

Thanks!

Some of the features have been backported, some not -- I honestly can't quite remember what's been done so far -- I know application to shipping is complete, but not display of remaining credit or auto-assignment to the first user. If you want to help, that would be swell... please pull the store-credit-6 branch from git and post patches against that. The more granular your patches are the better (i.e. better one patch for each feature than a giant patch containing all the features). Also, let me know which features you're working on so I don't duplicate (not that I have any time to work on it at the moment, but you never know when free time might crop up).

Great!
I plan to work on the following:
-ability to have customer specify a recipient email address for a purchased coupon (enable this feature on the coupon module settings page, then add the uc_coupon_purchase_recipient attribute to a product which has coupon-creation as a feature).
-display remaining credit next coupon name

Thanks

uh oh.
I am not going to be able to submit patches for the backport to Drupal 6 due to work issues.
Sincere apologies.

That's a shame... Hopefully someone can help with the backporting!

Created new 7.x-3.x branch and dev release to contain this effort for D7. Tagging this as to be ported for D6.

I see some of this functionality in 7.x-3.0-alpha0 in rules for sending emails. Is it implemented in that version? How do I set it up?
--- update
Found it. When editing a product, select attributes (node/{##}/edit/attributes, and add the attribute uc_coupon_purchase_recipient. You must also enable this attribute in coupon management admin/store/settings/coupon

Hey,

how can i access this project's git repo ? I'd really like to get the gift certificates running, but i have hit an dead end. i hope you can help me.

Thanks,

Martin

@wodenx, does the 7.x-3.x-dev version timestamped "2013-Oct-19" contain all of these features, with no need to patch?