conflict between flat-rate per-item shipping and uc_coupon

This is a uc_coupon issue.

I'm also having the same problem. I'm using Paypal Website Payments standard. I have a base shipping price of $4.95 with $1.00 added for each product. It is counting the coupon as a shipping item (+$1.00), but once I get to the order review, it changes back to the correct amount of shipping.

I'm using Acquia Prosper theme as my base theme. I'm investigating where it is including the coupon in the item count. Maybe when the shipping tries to fetch the flat rate prices, its checking the total amount of items calculated on the product list.

How can I check each line item to see if it is a product or a coupon and exclude it in the count if it is not an item?

I'm launching my store this weekend and have a promocode strategy set in place. I need to get this fix. I'm willing to collaborate or even pay someone to do this for me. I just don't have the time.

I think we just need to somehow disregard line items that are inserted as coupons.

Please help! Thanks,

-Dan

As @longwave indicated above, this is a problem with uc_coupon, not with Ubercart. I'm moving this issue to the queue for that module.

has there been any progress on this issue. ubercart counts the coupon as shippable item only if you add the coupon already in the cart screen or if by error you get back to the checkout screen.
any help would be appreciated! thanks in advance

Please test the attached patch (against DEV) to see if it fixes the problem. Thanks.

I am also experiencing this problem.

I'm using just a base rate (no per product amount), but have my shipping methods setup so that it counts the number of products and charges based on brackets.

<= 12 products = $10
>12 AND <= 24 =$20 and so on

The coupon is being included in this count if I choose to show the coupon in the cart, which I would like to do. Shouldn't flat rate be ignoring the coupon in determining the result of the condition "Check an order's number of products"?

Cheers,
Sam

Further to this, altering uc_coupon_uc_cart_alter() so that the qty field for the fake cart item is set to zero fixes the shipping calculation problems, still leaves the totals calculation correct, displays perfectly in both cart block and on the cart page (number of items remains unchanged in the block which I feel would be the more expected behavior from a user - there is no way a user would think of applying a coupon as adding another item to the cart).

However it introduces the new problem of not displaying the value of the coupon on the line items during checkout.
If the checkout routine can be manipulated to ignore the qty field then that would address this.

Have you tried the patch?
Thx

Patch did not rectify, but applied (by hand) against 6.x-1.5, not against DEV. I'll up to DEV and retry.

I also think a solution that not only removes the item from being counted for shipping but also removes item from the cart count would be the preferred solution. I think many shoppers would be confused if they added a single item to their cart, applied a coupon and saw the cart block saying they had 2 items in their cart.

Applied against DEV, patch does not resolve behaviour

Cheers,
Sam

First with regard to the patch - can you tell me exactly the behavior you're experiencing with the patch applied? I have created a flatrate shipping method of $0/base + $1/product. If I put a shippable product in my cart, apply a coupon, and request a shipping quote, the quote is correctly calculated as $1 (not $2 as it would have been without the patch).

With regard to your comments in #9 - I agree it's potentially confusing that the coupon should add to the number of items displayed in the cart block, though I think an argument could be made either way. Setting the fake qty to 0 is an interesting idea. It would even be possible to use a price alterer to fix the display problem in the checkout pane. However, the coupon line on the checkout pane would still display a quantity of 0, which I think is also confusing. Also, using this method would make it more difficult to implement the possibility of applying a coupon more than once. And the price-alterer solution to fixing the value display at checkout would not port to D7.

The problem is made complicated by the fact that uc_cart uses three different methods to display the cart contents (in the block, on the cart page and in the checkout pane), and these are not all configurable.

Assuming we stick with the present solution, you could override theme_uc_cart_block_content() or theme_uc_cart_block_summary() to modify the display of the number of items in the cart block when a coupon is present.

Committed #7.

With regard to #16 - put the following in your template.php or (MYTHEME.theme) --

function MYTHEME_uc_cart_block_content($help_text, $items, $item_count, $item_text, $total, $summary_links) {
  foreach ($items as &$item) {
    if ($item['nid'] == 0 && $item['price'] <= 0) { // This is probably a coupon.
      $item['qty'] = '';
      $item_count--;
    }
  }
  $item_text = format_plural($item_count, '<span class="num-items">1</span> Item', '<span class="num-items">@count</span> Items');
  return theme_uc_cart_block_content($help_text, $items, $item_count, $item_text, $total, $summary_links);
}

I solved this problem by changing in this function:
http://api.lullabot.com/uc_order_condition_count_products

$total = $totals['all'];

to

    $result = db_query("SELECT nid, model FROM {uc_products} ORDER BY model");
    while ($product = db_fetch_object($result)) {
      $total += $totals[$product->nid];
    }

The problem occurs because ubercart assumes that every element in $order->products is actually a product, but some modules may include items there in order to take advantange of the functionality given to this array, and that's what uc_coupons does.

However this would require one of two things. Either ubercart changes it's usage of $order->products to take into account that there may be elements that are not products there, or uc_coupons override the necessary functions in ubercart to avoid the conflict.

For this particular bug, a way to override uc_order_condition_count_products from uc_coupons will suffice.

This assumption is made throughout ubercart - and in fact there is an attempt made to enforce it (uc_cart_add_item() checks to be sure an item is a product before allowing it to be added to the cart). The problem is fundamental to the way uc_coupon displays coupons in the cart, and I don't think there's an easy solution.

For your particular use-case (which, I assume, is offering a particular shipping rate only if there are more than X products in the cart): unfortunately there's no "hook_ca_condition_alter()" which would allow uc_coupon to override the default behavior. You could try submitting your patch in the ubercart issue queue, but I'd suggest not querying the whole product set. For uc_coupon it would be enough to do the following:

   $totals = array('all' => 0);
   $total = 0;
   foreach ($order->products as $product) {
-    $totals['all'] += $product->qty;
+    if ($product->nid) {
+      $totals['all'] += $product->qty;
+    }
     $totals[$product->nid] += $product->qty;
   }
   if (in_array('all', $settings['products'])) {

a few lines earlier.

You could also work-around this case without patching anything by simply selecting all products manually (rather than selecting "all products") when configuring the condition.

This isn't really a uc_coupon issue. Could be reopened in the ubercart queue.

I'm not sure if this has anything to do with UberCart because I'm using Drupal Commerce with the Coupon module and the same is happening.

It is counting the fixed coupon as a line item in shipping and subsequently increasing the shipping amount. It appears to be a bug in the coupon module.