Author Topic: Upgraded membership page results in double billing of users (Read 1375 times)

petednz · November 01, 2012, 08:47:34 pm

Seems this is a result of recent upgrade 4.2.4?

Hopefully this problem is unique to this scenario.

Membership page has
- single default Membership Type that is required ($230)
- single default contribution amount (for $230)

This was how we had to set these up in the 'old' system.

The upgrade resulted in both items being included as radio buttons in a quasi Price Set and the users were getting billed for $460 - not good

I will be checking on other sites to ensure their Membership pages have not gone feral on us since this upgrade. Meanwhile just putting this out there for others.

Dave Greenberg · November 08, 2012, 02:23:22 pm

Everything is a price set in 4.2 (thanks eileen

). The behavior of charging the contribution block as 'additional' vs charging it as covering the membership fee plus any overage is controlled by the 'Separate Membership Payment' checkbox, and hopefully that didn't change - but might be an edge case. (See help in attached screenshot.)

That said, I don't really understand why you would have set things up that way in any case??

petednz · November 08, 2012, 02:30:11 pm

The set up was meant to achieve the following
- single Membership type, required
- single amount of money to be paid
- no 'other' amounts allowed

Hence we had the membership required and an equivalent 'amount' set on the Contribution side

This resulted correctly in people just having to hit 'submit' to go to the payment side of things.

After the upgrade, the Membership was itself putting in the amount, and so the total doubled

Not sure if that is clear - it may be 'edge' where only one membership is available and required etc, but i know we have several others set up like that which i am putting off for now

Dave Greenberg · November 09, 2012, 04:02:47 pm

Do you have 'Separate membership payment' checked or not. Does switching that fix the problem?

Dave Greenberg · November 09, 2012, 04:11:58 pm

Just thinking more on this - your described requirement would seem to be handled by just unchecking the "Contribution Amounts section enabled" in the Amounts tab and setting Membership signup required in the Memberships tab. See screenshot.

petednz · November 10, 2012, 02:37:22 pm

Thanks Dave - this ticket wasn't originally so much about finding a solution (yes yours is what we did in one case, though in the other eileen went down the route of creating the price set, then removing the contrib amount - not sure why)

It was really to flag that upgrading can cause realtime problems with Members being billed twice the amount they were billed prior to the upgrade. Mostly a warning flag to others to check their member pages.

But also perhaps a question whether the upgrade could/should have coped with this scenario and if so whether it can be wired in to future releases so others don't trip over this

Dave Greenberg · November 12, 2012, 11:09:26 am

Pete - Using sample data I'm not seeing how double charging can be a result of an upgrade. The behavior of the two sets of radio buttons should be dependent on the "Separate Membership Payment" flag both before and after the upgrade as far as I can see (and I don't think the upgrade touched that flag).

If "Separate Membership Payment" is true, then the 'additional contribution amount' radio would always have been charged on top of the membership fee (both in 4.1 and 4.2). If "Separate Membership Payment" is false then the "contribution amount" radio is the only fee amount charged and must be sufficient to at least cover the membership fee. Can you please check your configurations and see if you're getting different behavior in these two conditions?

petednz · November 12, 2012, 05:08:23 pm

Hi Dave

It was not set to Separate Payments

After upgrade we ended up with a required single radio button for $230 'contribution amount' and a required single button for the Membership (which was also set to $230 in Membership Type settings)

After the upgrade people would hit 'submit' and get billed $460

(I haven't yet ruled out that someone at the client end did something post upgrade to 'fix' something on this page that made it worse - I can check the logs but don't know where Contribution Amount options are stored)

I doubt it is worth going any further on this since you aren't able to replicate it and no one else is squealing.

We do have another dev site for them to do some theming work on - which is still on 3.1.5 - and I thought that would shed light on the settings. But i get DB ERROR: no such field at civicrm/admin/contribute/settings?reset=1&action=update&id=7

Code: [Select]

/var/www/civicrm/civicrm-fuzion-d7-4.1/civicrm/CRM/Core/Error.php, backtrace, 146
, handle, 
/var/www/civicrm/civicrm-fuzion-d7-4.1/civicrm/packages/PEAR.php, call_user_func, 931
/var/www/civicrm/civicrm-fuzion-d7-4.1/civicrm/packages/DB.php, PEAR_Error, 968
/var/www/civicrm/civicrm-fuzion-d7-4.1/civicrm/packages/PEAR.php, DB_Error, 564
/var/www/civicrm/civicrm-fuzion-d7-4.1/civicrm/packages/DB/common.php, raiseError, 1903
/var/www/civicrm/civicrm-fuzion-d7-4.1/civicrm/packages/DB/mysql.php, raiseError, 898
/var/www/civicrm/civicrm-fuzion-d7-4.1/civicrm/packages/DB/mysql.php, mysqlRaiseError, 327
/var/www/civicrm/civicrm-fuzion-d7-4.1/civicrm/packages/DB/common.php, simpleQuery, 1216
/var/www/civicrm/civicrm-fuzion-d7-4.1/civicrm/packages/DB/DataObject.php, query, 2428
/var/www/civicrm/civicrm-fuzion-d7-4.1/civicrm/packages/DB/DataObject.php, _query, 442
/var/www/civicrm/civicrm-fuzion-d7-4.1/civicrm/CRM/Core/DAO.php, find, 733
/var/www/civicrm/civicrm-fuzion-d7-4.1/civicrm/CRM/Member/Form/MembershipBlock.php, getFieldValue, 124
/var/www/civicrm/civicrm-fuzion-d7-4.1/civicrm/CRM/Core/Form.php, buildQuickForm, 340
/var/www/civicrm/civicrm-fuzion-d7-4.1/civicrm/CRM/Core/QuickForm/Action/Display.php, buildForm, 97
/var/www/civicrm/civicrm-fuzion-d7-4.1/civicrm/packages/HTML/QuickForm/Controller.php, perform, 203
/var/www/civicrm/civicrm-fuzion-d7-4.1/civicrm/packages/HTML/QuickForm/Page.php, handle, 103
/var/www/civicrm/civicrm-fuzion-d7-4.1/civicrm/CRM/Core/Controller.php, handle, 292
/var/www/civicrm/civicrm-fuzion-d7-4.1/civicrm/CRM/Utils/Wrapper.php, run, 117
/var/www/civicrm/civicrm-fuzion-d7-4.1/civicrm/CRM/Core/Invoke.php, run, 210
/var/www/civicrm/civicrm-fuzion-d7-4.1/civicrm/drupal/civicrm.module, invoke, 482
, civicrm_invoke, 
/home/outdoorsnz/www/includes/menu.inc, call_user_func_array, 516
/home/outdoorsnz/www/index.php, menu_execute_active_handler, 21

But in terms of how it was set up

AMOUNTS: Amounts section enabled OFF

And in the DB i see in _membership_block
- display min fee = 0
- is separate payment = 0

You are welcome to have an account on that site if you want - and we can even run the upgrade to confirm that outcome, but think we both have better things to focus on.

CiviCRM Community Forums (archive)

News:

Author Topic: Upgraded membership page results in double billing of users (Read 1375 times)

petednz

Upgraded membership page results in double billing of users

Dave Greenberg

Re: Upgraded membership page results in double billing of users

petednz

Re: Upgraded membership page results in double billing of users

Dave Greenberg

Re: Upgraded membership page results in double billing of users

Dave Greenberg

Re: Upgraded membership page results in double billing of users

petednz

Re: Upgraded membership page results in double billing of users

Dave Greenberg

Re: Upgraded membership page results in double billing of users

petednz

Re: Upgraded membership page results in double billing of users