CiviCRM Community Forums (archive)

This is my first foray into recurring memberships.  I have a client whose Civi was modified by someone outside of the community to generate an entry in civicrm_membership_payment every time a recurring contribution was received.  If you pull up a membership record, you see a history of ALL payments made on that membership.  Sadly, they made that modification by hacking core on Civi 3.4.8; I recently upgraded them to Civi 4.4.6.

Now, I was going to just make an extension that hooks civicrm_post to reimplement this feature, but I wonder - shouldn't this be in core?  Is there a use case where you want to view a membership_payment history for a membership and NOT see all the payments?

If I get the feedback that this belongs in core, I'll try to submit it for Civi 4.6.

What is the current status on this bug?  I didnt see anything specific in JIRA.  Is there a bug track issued for this?  I am running on Civi 4.4.6 and we see the same error.  The problem is more profound because all the reports for contribution and membership use the civicrm_membership_payment table to associated all the data.  Since the recurring contributions are not creating a row in the table the reports show no data for the effected contributions. 

Can you link to the JIRA if its submitted.  Thanks

There is a JIRA issue - https://issues.civicrm.org/jira/browse/CRM-15203

However, after posting this, Joe Murray and dgg and I discussed that MembershipPayments are going to go away in future versions of CiviCRM, so I told them not to merge my commit.  Also - I found a quite serious bug in the PR attached to that ticket - please don't use it!  I ended up replacing the BAO code with DAO code that does the same for my client.  I'll dig that code up real quick for you and post it here and on the ticket.

Jon,

In one sense it would be Ok to merge - well - as long as you used BAO::create to create it - at the moment the line items are appropriately edited within that function I believe.

However, assuming yours is pegged for 4.6 & we will be each doing our own hacks until then I guess by 4.6 hopefully it would be redundant. (my preference would be to 'get it in' along with a unit test so even if the code changes the outcome can't - the test can test the line items)

I should have found this one sooner, but I've been having problems with Recurring payments and Memberships.  See: http://forum.civicrm.org/index.php/topic,34454.msg146262.htm

I'm also kinda blindsided with the post above that Membership Payments are going away in a future version of CiviCRM.    One of the reasons I chose this software was because it can handle all the functions needed for online membership payment, tracking, contact, event registration, etc.    I'd appreciate some background as to why this is being considered, or am I misreading that post and its referring to something else.

Membership payments aren't going away - they're being tracked in the underlying database in a better way starting in CiviCRM 4.5.  Instead of treating them as their own special entity, membership payment info is now logged on the line item.

Whew ... thanks for the clarification.    Could this be the reason that recurring membership payments are not being processed?    I've noticed that recurring payments made the last few years processed properly, but it appears that after install of v4.5, they are not.

There is a bug fix in 4.6.3 (due 5 Nov) which may fix that

Thanks .. I'll keep an eye on what happens after that.

it would be great for our members to look at their accounts and see this same payment history information.

this is already possible via the user dashboard or if you are using drupal via a view.