Flexicharge not adding up charges for mixed product types

I suspect I'm having similar issues as you are.

http://drupal.org/node/228968

Sorry I don't have any help, but IMO its not working correctly.

Drew

Randy?,

I think it is these lines in Flexicharge.module 136 to 140…

foreach ($txn->items as $item) {
  if (empty($charge->ptypes[$item->ptype])) {
    unset($charges[$charge->chid]);
  break;
}

The if() seems to always return empty for me, even when the array isn't empty. Try commenting out the unset() line (backup the original first :-)) I'm trying to see if it would make more sense to compare the 2 ptype (product type) strings. something along these lines…

if (!$charge->ptypes[$item->ptype] = $item->ptype) {
   unset($charges[$charge->chid]);
   break;
}

I suspect it may be something specific to the PHP version? Since I cant believe only 3 people would witness this if it was normal behavior for flexicharge.

Here is info about my test setup.
Drupal 5.7
Ecommerce 5.x-3.4
MySQL database 5.0.27
PHP 5.2.1
PHP register globals Disabled
Unicode library PHP Mbstring Extension
Web server Apache/1.3.33 (Darwin) PHP/5.2.1
Mac OSX 10.4.11 I think I'm using the entropy.ch package for PHP, can't remember at the moment.

I need to do more on this, hopefully it makes sense to you.

Drew

Randy,

A simple scenario…
2 product types and 2 flexicharges that are assigned to only one product type exclusively.

Product A (type_a)
Product B (type_b)

flexicharge 1 (charge_id_1) assigned to product type_a
flexicharge 2 (charge_id_2) assigned to product type_b

Here is what I think is going on in the review section…

For every charge check that every item has a value set for the ptype, if not remove the array containing the details (delete the charge)

So if both of the above items are in the cart the following happens

charge_id_1 loop…
does charge_id_1 have type_a assigned to it? Yes - charge lives
does charge_id_1 have type_b assigned to it? no - charge_b removed
end charge_id_1 loop

charge_id_2 loop…
does charge_id_2 have type_b assigned to it? no - charge removed
does charge_id_2 have type_a assigned to it? Yes - charge lives accept it was already culled by the previous loop
end charge_id_2 loop

To me it suggests that it will always remove charge 2 on the first iteration because it doesn't exist in the charge array, followed by hosing the first item in the next loop. I think the logic needs a rework to be able to cope with multiple items of differing types.

I have to add the usual disclaimer about not really understanding why it is done how it is …

Drew

Randy,

Try replacing lines 126 to 144 in original flexicharge.module with the following…

 case 'review':
 // Get saved charges from database.
 $charges = _flexicharge_load_charges();
 // Remove charges that does not apply by PRODUCT.
 foreach ($charges as $key => $charge) {
   // If there is a product filter on the charge.
   if (!empty($charge->ptypes)) {
      foreach ($txn->items as $item) {
        if (empty($charge->ptypes[$item->ptype]))  {
             //unset($charges[$charge->chid]); // DOH DON'T UNSET YET, lets wait & see till we have looked @ all the items
              $delete[] = ($key);
         }else{
            $keeper[] = ($key);
         }
           //break; // er do I need to break here?
         }
     }
   }

 $thedead = array_diff($delete,$keeper);
 foreach ($thedead as $dead) {
   unset($charges[$dead]);
 }

It's rough but it seems to work, can you try it please? Hopefully it will work for you.

Drew

Thanks Randy,

I created a patch (attached) called flexicharge_multicharges.patch. I renamed some variables and cleaned up the code but it is the same code. It is for the flexicharge 5.x-3.4 (flexicharge.module,v 1.8.2.1.2.1.2.17 2007/07/12 02:46:04).

I'd suggest testing to make sure it is passing the info off to the gateway correctly. Hopefully someone will review it and commit it. I'm still uncertain wether the excluding charges is a bug or it's a feature.

BTW your www.artistshousemusic.org site looks good :)

Drew

Changing status to get patch reviewed (hopefully).

Drew

Subscribing...

At at glance I'd say it was worth looking over the role code to check if it has the same problem...

And I'd would rather like if it was rewritten to gather a list of wanted charges instead.

I think the roles code doesn't suffer from the bug since it doesn't get iterated inside the foreach ($txn->items as item) loop.

The problem was that the first item would result in the unsetting of the other charges.

To be honest I don't need that feature and haven't investigated it's effects, since the patch hasn't altered anything in that code.

Drew

(excuse me if this makes absolutely no sense, just got out of bed)

Assume we have a charge that applies to the roles A and B. The current user is member of B.

On the first loop of the foreach($user->roles) in the role the role is 'Authenticated user'. 'Authenticated user' isn't set for the charge, so it is removed. On the second loop it is 'A', but as it's already unset, it stays that way.

Actually, the behaviour could be considered right, if the requirement was for *all* the roles to apply, however that's not what people expect.

Anyway, I feel that that looping through all charges and adding them to a list feels more 'right'. Though the inner part of that loop is going to be a bit clonky. I'll do a patch if I get the time...

Here's another take on a fix. Also takes the roles into account.

I cannot get Flexicharge to apply a role-based discount reliably. I've applied the above patch, and had it working with a percentage discount on non-shippable products. When I changed the Flexicharge type to flat -$20, it no longer shows up on check-out, even if there is only one non-shippable item in the cart. I tried deleting that Flexicharge, and creating a new one, but it just doesn't show up unless the operator is set to the % subtype. What am I doing wrong?

#17
Could you try without the patch, with a single item in the cart? If it behaves the same, you should create another issue as it's then a seperate bug.

It's definitely not working right, even without the patch. I will submit a separate bug report.

Follow up: another search turned up this issue - http://drupal.org/node/148157. I applied the suggested code alterations listed at the end of that thread, AND applied the above patch, and my Flexicharge discount is working now.

Drew,

Woooopie!!

-Paul

modctek,

Take a look at the switch statement (around line 120 of a file you derive from custom.inc.example). I added a condition if($item->ptype == 'generic') and that seemed to help. With this change the flat (non-%) charge is applied to each of the non-shippable items ordered. Here's screen dump of a test (sorry, columns don't line up well), followed by the code change:

Hope this helps.

Order Summary
Qty Item Price Subtotal
3 Test Shippable $75.00 $225.00
4 Test Non-Ship $100.00 $400.00
Subtotal $625.00
Non-Shippable TEST. $40.00 <--- Flat +/- $10 charge to each Non-Ship
Subtotal $665.00
Member Discount 50% $-200.00 <-- Percent discount to each Non-Ship
Subtotal $465.00
Flat Rate Shipping $9.95 <-- Flat +/- $9.95 charage once for Shippable
Total $474.95

  switch ($misc->operator) {
    case FLEXICHARGE_CHARGE:
      $rate = $misc->rate;
    case FLEXICHARGE_CHARGE_PCT_SUBTOTAL:
      $rate = ($total * $pct * $factor);
    case FLEXICHARGE_CHARGE_PCT_ITEMTOTAL:
      $value = 0;
      foreach ((array)$txn->items as $item) {
        if($item->ptype == 'generic')  { 
          if (product_has_quantity($item)) {
            $value += $item->qty; 
          }
          else {
            $value += $item->price;
          }
        }
        $rate = ($value * $misc->rate);
      }
   }
  // hide this charge if required.
  if (empty($rate) and !empty($misc->hide_if_zero)) {
    foreach ($txn->misc as $m) {
      if ($m->chid == $misc->chid) {
        $txn->misc[$m->chid]->seen = true;
      }
    }
  }
  return $rate;

-Paul

@ 20

I guess that means it works for you :)
Glad to hear it.

Drew

@19
I confirm: my problem (showing 0.00 when i used a fixed value with simple +/-) was not solved using above patch. But after the patch AND the fix for /flexicharge/providers/sitewide.inc at http://drupal.org/node/148157 it worked fine.