[ic] Discounts and coupons and CommonAdjust and...eh.
paul at gishnetwork.com
Wed Nov 17 05:35:45 UTC 2010
> From: dances_with_peons at live.com
> One of my clients’ site is running in IC v5.6.2, and currently has rather
> simple "coupons" using discounts. A coupons table contains info about each
> coupon, valid dates, amount or percentage off, etc. When the user inputs a
> coupon code, the checkout page (with the help of a usertag) looks up a
> coupon, sets the discount, and done. This setup has been in the store for a
> while now, and has worked to some degree, as the coupons tend to be a
> percentage, and either apply to ALL_ITEMS or are for all of a specific item.
> They're outgrowing this simplistic setup, though, and are now asking for
> real coupons.
> By "real" coupons, I mean (among other things):
> * A coupon can apply to a single item in the cart, or to some other
> per-coupon limit on item count. That is, if I have a coupon for $5 off item
> 203, it can just deduct $5 from the first 203 in the cart, and leave the
> rest alone. Even if they're on separate lines.
> * Multiple coupon codes can be added to the order for a sku. That is, if I
> have a coupon for a free item 123, and another coupon for 20% off item 123,
> * If a coupon is removed, or certain order data changes (like the ship date,
> or the zip code), the coupon would not apply. In those cases, the discount
> needs to be removed. The flypage, cart page, and checkout all need to
> forget whatever discounts are no longer valid, but keep track of the
> discount in case the order changes to make it valid again.
> * The coupon discounts the price, but leaves the pre-coupons price available
> (so one can see how much they saved).
> The existing, discount-based solution runs smack into the first two
> problems; the discount ends up applying to every item 203 in the cart, and
> it ends up overwriting other discounts for the same sku. I managed to get
> around the third problem by adding some code with Pragma init_page, that
> looks through the coupon codes and reapplies all the discounts that are
> still valid, but it feels like an ugly hack -- and still doesn't solve the
> real problems. I need to come up with a better way.
> I looked at CommonAdjust, but it has one major problem when it comes to
> coupons: the discounted price becomes the "price", meaning all the code I
> currently have in the cart and checkout that says "this item is discounted"
> no longer works. This is a particularly big problem because there's
> existing CommonAdjust stuff that prices the item by area and order date and
> delivery date, so simply looking at the "price" field won't work. (There
> are actually a couple of price fields, so it'd be a bit of a pain to look up
> My hopelessly optimistic question: Is there some decent built-in coupon
> stuff that I've been overlooking all this time? Preferably something that
> can be extended, cause the client has some freakishly complicated things
> they want to do with coupons. Ideally, it should also be able to separate
> "price" from "price with coupon", like the discount stuff and
> [item-discount*] manage to do.
> Failing that, we have my real question: What's the best way to do all this
> without having to replace/replicate/rewrite half the pricing stuff in IC?
I had to do a moderately complex system for a client. Mike Heins advised me to remove and reapply any coupons/discounts whenever the cart/totals are accessed, don't try to maintain and act upon some string of events. This kinda sounds like what you are already doing with Pragma_init. There was no alteration to core for mine, I actually insert the discounts into the cart as "items" with negative amounts.
My client needed to take up to two coupons. One would always be %/$ off order with minimum. The other coupon is a combo or either $/% off - OR - buy X get X free. It has logic to make the free item(s) anything lesser than the most single expensive item in the cart, and it accumulates... so buy 3 get 1 free also means buy 6 get 2 free, and so on.
All this is done in a perl block whenever the cart is accessed. Also, the promos always communicate to the customer - for example, the cart might say like "Awesome, you're getting 10% off right now but if you add 2 more items to your cart, you'll get one free!", and the message changes with each cart update.
You can at least consider adding in the discounts as separate items in the cart - this way all pricing is still visible. The discount line item could even be titled programmatically, "This is a $5 discount on item 123". Also, for the issue of a discount applying to one or more items, maybe play with setting "maximums", so if you have $5 off item 123 and the maximum total for that discount is $5, it will just take it off one item, if the max is $10, it wil take it off 2 of them. If there is no max, it will take it off all items 123, etc. Just saying, that comes to mind as a way I'd look into.
For mine - I did it myself and I know nothing about nothing so I am sure you can do it, you are probably just over thinking it right now. Whenever I do something I am unsure of, I buy an hour of Mike's, Peter's, or Kevin's (Kevin!) time to get "their take". I'd recommend that.
That said, I would be all for making a better coupon system in IC. You wouldn't want my help, I am more a swiss army knife, not a scalpel :-) However I would pitch in $400 if people wanted to get a Core member to do it (e.g., Perusion, Endpoint, Racke, Peter, etc). If we all pitch in though, we should PRE PAY. That would keep the fire on and not make it easy for us to forget about it.
I could help with the starting point though - defining their behavior.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the interchange-users