Jump to content

Coupons still being honoured even though they are expired!


Guest sales@justdoitguides.co.uk
 Share

Recommended Posts

Hi,

Recently upgraded from 4, and to be honest really wish I hadn`t bothered. I am based in the UK, and had issues with calculating VAT, but am coping with that. Biggest issue being when the customer wants to pay by PO, the VAT is worked out incorrectly! It comes back with a different figure compared with paying by card!

Biggest problem though is that Coupons that have expired, are still active and allowed to be honoured. We had a sale the other night for a really old coupon which was displaying in Cubecart as expired in 2011, but it was allowed and the customer got a discount which I have to honour!!

The coupons which were imported from CC4 don't expire, neither do any ones I create now!!

Anyone else had issues with coupons ignoring whether they have expired or now?

Overall, even using the latest Cubecart, it feels really buggy and un-trustworthy!

Many thanks for any advice,

Dave

Link to comment
Share on other sites

In the cart class, addDiscount method, I see no test for discarding expired coupons from the list of 'status'=1 eligible coupons.

If and when I might come up with an edit to the code, may I advise you to set the status to OFF for expired coupons.

Subscribe to this thread to be notified of replies should an edit to the code be proposed, or until (maybe) CC5.0.7 arrives.

Link to comment
Share on other sites

I am not finding any code that will automatically update a coupon's database 'status' column to 0 based on the value found in the 'expires' column.

I assume you do not recall setting the value to zero (status->OFF) yourself?

(I'm working on a chronological history of all the database upgrades and so far I have not come across any manipulation of this column. But I am not finished. Having said that, there may be an upgrade script that does this status change. But I believe there is nothing that does this in the main operational code.)

Link to comment
Share on other sites

As far as I can remember now I did not manually set it to disable it. I created a test one for one day and we'll see what happens tomorrow. I did notice when I created it that it pulls up the calendar to get the expiration date, and the date on the calendar has to be clicked on. If this was an old coupon from previous versions of CC maybe the date didn't get pulled into the new table.

Link to comment
Share on other sites

Coupons were introduced in CC4.0.0 and the 'expires' column was a plaintext field (VARCHAR) 10 characters wide. I do not know if CC4 enforced any particular date-style format.

CubeCart 5 altered this column to the DATE type. MySQL requires the DATE format to be YYYY-MM-DD (http://dev.mysql.com...n/datetime.html). I do not find any code that will look for invalid dates and convert before altering the column data type.

I also find that one can manually enter a date, such as 3-21-2012, but do not know if any attempt is made to refigure this to the MySQL format. This malformed date should end up in the database table as 0000-00-00. I also do not know if CC5 enforces this format.

Continuing: Well, I just added a coupon manually and entering an invalid date format. MySQL rejected the value and it was stored in the database table as 0000-00-00. This, according to CC5, means it never expires.

So, be sure to format the date as YYYY-MM-DD if entering manually, or use the calendar pop-out.

Please scan through your Coupons listing and make sure the expires column shows a properly formatted date.

However, the potential problem still exists that CC5 ignores the expires date altogether.

(Bug reports submitted.)

Link to comment
Share on other sites

I would like for someone to try the following. In the file cart.class.php, line 409, find:

public function discountAdd($code) {

and on the same line just after the open brace, add this:


$sign = substr($GLOBALS['config']->get('config', 'time_offset'),0,1); $value = substr($GLOBALS['config']->get('config', 'time_offset'),1); if($sign=='+'){$timeNow = time() + $value;} elseif($sign=='-'){$timeNow = time() - $value;} elseif($value>0){$timeNow = time() + $value;} else {$timeNow = time();}



Then on line 432, just above $proceed = false; insert this:


if (!empty($coupon['expires']) && (strtotime($coupon['expires']) < $timeNow)) {$GLOBALS['gui']->setError($GLOBALS['language']->checkout['error_voucher_expired']);return false;}

The first edit calculates the time according to UTC +/- Offset, the second edit adds another behavior similar to the tests above it.

In the admin screen Settings, Advanced Settings tab, set the UTC Offset (I'm guessing minutes) to 60*hrs for the number of hours you are away from UTC. For example, California USA is -480 minutes from UTC. Or it could be seconds: -28800. Be sure to use a plus sign or a negative sign. (Disclaimer: I do not yet know the significance of supplying both a UTC offset and a timezone.)

I'm sure when Devellion gets this officially resolved, they will use the timezone of the customer's invoice address to calculate their local time so that coupons expire at midnight customer time instead of store time. If that's important to you.

EDIT: The code on line 409 was bad. Sorry. What you see now is correct.

Edited by bsmither
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...