next »

[Glen Chancy]

In the stable version of 1.1, the system does not recognize discounts assigned to specific shopper classes.

However, the system does process credit payments using Atandra's QBMS integration.

To fix this, I installed the ps_shopper_group.php from the nightly build for June 8th.

This corrected the shopper class discount problem. However, it then caused the QBMS integration to fail. The system returned an error that the transaction key is blank.

That leaves me with two versions of this script, both broken in different ways. I believe the problem is in this code:

function get_shoppergroup_by_id($id, $default_group = false) {
       
       $ps_vendor_id = vmGet($_SESSION, 'ps_vendor_id', 1 );
       $db = new ps_DB;

       $q =  "SELECT #__{vm}_shopper_group.shopper_group_id, show_price_including_tax, `default`, shopper_group_discount
          FROM `#__{vm}_shopper_group`";
       if( !empty( $id ) && !$default_group) {
            $q .= ",`#__{vm}_shopper_vendor_xref`";
            $q .= " WHERE #__{vm}_shopper_vendor_xref.user_id='" . $id . "' AND ";
            $q .= "#__{vm}_shopper_group.shopper_group_id=#__{vm}_shopper_vendor_xref.shopper_group_id";
       }
       else {
          $q .= " WHERE #__{vm}_shopper_group.vendor_id='$ps_vendor_id' AND `default`='1'";
       }
       $db->query($q);
       if ($db->next_record()){ //not sure that is is filled in database (Steve)
            $group["shopper_group_id"] = $db->f("shopper_group_id");
            $group["shopper_group_discount"] = $db->f("shopper_group_discount");
            $group["show_price_including_tax"] = $db->f("show_price_including_tax");
            $group["default_shopper_group"] = $db->f("default");
        }
        else {
         $q = "SELECT #__{vm}_shopper_group.shopper_group_id, show_price_including_tax, `default`, shopper_group_discount
                FROM `#__{vm}_shopper_group`
                WHERE #__{vm}_shopper_group.vendor_id='$ps_vendor_id' AND `default`='1'";
         $db->query($q);
         $db->next_record();
         $group["shopper_group_id"] = $db->f("shopper_group_id");
            $group["shopper_group_discount"] = $db->f("shopper_group_discount");
            $group["show_price_including_tax"] = $db->f("show_price_including_tax");
            $group["default_shopper_group"] = $db->f("default");
         
        }
       return $group;
     }

Upon further testing, I think the problem is this code line below.

Here is the stable code:

if( !empty( $auth['user_id'] ) && !$default_group) {

Here is the nightly build line of code:

if( !empty( $id ) && !$default_group) {

The one way skips the discount, the other doesn't apply the payment method correctly.

Any suggestions on a correction?

[Glen Chancy]

Hello -

I am willing to pay a developer to fix this problem, or donate to the VM project to get a fix. Is there anyone willing to look at this?

Thanks,

Glen

[Soeren]

The Problem will be solved with the next maitenance release. If you want to fix it earlier...here's the Solution:
https://dev.virtuemart.net/cb/issue/2014

ciao, Sören

[Glen Chancy]

Hello Soren -

I checked the link you posted. The line of code referenced there is the one I already have in the site. I got that line from the nightly build.

This line, however, causes the payment method to fail. When I process a payment, the system tells me that that transaction key is blank. If I process a payment using the old line of code, the payment processes. So, the new code fixes the one problem of the discounts not appearing, but then causes a different problem of the QBMS payment not processing.

Is this a VM problem, or does Atandra need to address this for their Quickbooks integration?

[Glen Chancy]

Hello everyone -

We've been working on this, but still no luck. The line of code which fixes the discount causes both Quickbooks and Authorize.net to fail with an error for blank transaction key.

The payment methods will work as long as the customer is logged in to a shopper class that is the same as the setting for the payment method. Hence, if the shopper is part of the default class, and the payment method is set to Default, then the transaction processes.

However, if the shopper is logged in as 'Church Bookstore' class, and the payment method is set to Default, then the result is an error for blank transaction key.

I initially tried to work around this by setting up three instances of the payment module, one per class in use on my site. That works fine for Default, but the other shopper classes then saw two payment options, one for default and one for their own. This won't work, obviously.

Somehow, there must be a way to render the discounts and to also process payments. At this point, I would be happy if I could just have one payment option per shopper class and only show that one, instead of showing two of them.

Any ideas on a fix?