View Payments shows "No payments found for this contribution record"

[TomCrawshaw]

Running Civi 5.8.2 on Drupal, and latest release of this extension. DD payments are working, and in summary contributions page are listed, but no "payments" are shown when drilling down. (see attached screen capture). All one-off contributions made by PayPal or Stripe are shown correctly, just not recurring ones. This means that when running GiftAid process, these contributions are rejected, presumably as no payment can be found. Table civicrm_contribution seems to have a complete record for these DD payments..

[artfulrobot]

Interesting. I don't get the same behaviour (D7, various CiviCRMs <=5.3). For Pending contributions I see "No payments found", but for Completed contributions, payments are found.

Do you have Financial Accounts set up correctly for the Donation Financial Type? /civicrm/admin/financial/financialType?reset=1

This extension does not create payment records; that's down to CiviCRM's internals. When you say you're running the latest release of this extension, can you clarify which version was running when the contributions were processed? Here's a timeline showing the release dates of this extension and the contributions in your screenshot.

• 16 Nov 2018: you have a contribution in your screenshot.

• 16 Nov 2018: v1.6 released, probably wasn't on CiviCRM extensions directory for another couple of days after this date.

• 17 Dec 2018: you have a contribution in your screenshot.

• 4 Jan 2019: latest release released (5 Jan on CiviCRM extensions dir).

V1.6 was quite a major change to the way recurring contributions created by the webhook are processed.

[TomCrawshaw]

Hi Rich

I’m checking the tables and comparing with correct payments to see if I can deduce where the problem is.

1. civicrm_contribution (a) Contribution_page_id, receipt_date, invoice_id, source, address_id, all NULL in DD entries. (b) contribution_recur_id not NULL (as you’d expect for recurring payments)

   I doubt if the problem is here

2. civicrm_line_item (a) price_field_id = 1 (aka "contribution amount"); In this table, wherever price_field_id = 1, participant_count = NULL, and these are all DD contributions. For other contributions p_f_i = 6 (aka “other amount”). … unlikely to be the problem.

3. civicrm_financial_item No obvious differences.

4. civicrm_financial_trxn (a) to_financial_account_id is NULL in all DD gross amount entries (but = 5 - "banking fees" - in the fees line in this table, like all contributions). I think the gross amount f_a_id field should be 7 - "accounts receivable” (b) payment_processor_id = NULL for all DDs (all others are 1,6 or 7, for Paypal or cards). Should be 12 for DD (live).

5. civicrm_entity_financial_trxn All looks ok

Following up difference 4(a), and checking the Payment Methods Options screen in CiviCRM, I have realised that the DD entries here are incomplete, and the Account field is blank. However, the GoCardless Payment Processor screen correctly shows Financial Account set to Accounts Receivable (which is probably why I never set the “Account” field in the Payments Method Options screen for DDs, not realising that this was needed).

I can’t understand difference 4(b), and don’t see where this is set in CiviCRM Admin, but don’t see why this would cause the problem.

I’ve now corrected the PMO entry for Direct Debit payment method, setting this to Accounts Receivable, and will wait for the next DD payment to come in (Feb 10th), and see if this changes things.

Thanks for the advice. I’ll let you know if it now works.

Regards

Tom

On 21 Jan 2019, at 09:30, Rich Lott notifications@github.com wrote:

Interesting. I don't get the same behaviour (D7, various CiviCRMs <=5.3). For Pending contributions I see "No payments found", but for Completed contributions, payments are found.

Do you have Financial Accounts set up correctly for the Donation Financial Type? /civicrm/admin/financial/financialType?reset=1

This extension does not create payment records; that's down to CiviCRM's internals. When you say you're running the latest release of this extension, can you clarify which version was running when the contributions were processed? Here's a timeline showing the release dates of this extension and the contributions in your screenshot.

16 Nov 2018: you have a contribution in your screenshot.

16 Nov 2018: v1.6 released, probably wasn't on CiviCRM extensions directory for another couple of days after this date.

17 Dec 2018: you have a contribution in your screenshot.

4 Jan 2019: latest release released (5 Jan on CiviCRM extensions dir).

V1.6 was quite a major change to the way recurring contributions created by the webhook are processed.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/artfulrobot/uk.artfulrobot.civicrm.gocardless/issues/51#issuecomment-456005196, or mute the thread https://github.com/notifications/unsubscribe-auth/AOLKTdwyyMVVRosaO3t33GZ940ycGsw5ks5vFYi-gaJpZM4aJw_P.

[artfulrobot]

My entry at civicrm/admin/options/payment_instrument was also blank for Account. I don't think it should be (it says it's mandatory), so I'll mark this as a bug. But that had clearly not caused the problem in my case.

[TomCrawshaw]

I’ve found that by setting the to_financial_account_id field = Deposit Bank Account (e.g) for DD payments these now show as “payments” in Find Contributions. However, I still can’t get most DD payments to qualify for adding to a Gift Aid batch, so something is still wrong.

I’ve tracked down the test which rejects these, in CRM/Civigiftaid/Utils/GiftAid.php, in the function at line 490:

static function isContributionEligible($contactID, $contributionID) {
  $contributionDeclarationDateMatchFound = FALSE;
  $declarations = self::getAllDeclarations($contactID);

  $eligibilityFieldId = civicrm_api3('CustomField', 'getsingle', array(
                    'return' => array("id"),
                    'name' => "eligible_for_gift_aid",
                    'custom_group_id' => "Gift_Aid",
                  ))['id'];
  $eligibilityFieldCol = 'custom_' . $eligibilityFieldId;
  $contribution = civicrm_api3('Contribution', 'getsingle', array(
                    'return' => array($eligibilityFieldCol, "receive_date"),
                    'id' => $contributionID,
                  ));
  if($contribution[$eligibilityFieldCol] == self::DECLARATION_IS_NO) {
    return FALSE;
  }

The api call for one of the DD contributions (#466) which is failing returns:

array(6) { ["contact_id"]=> string(1) "2" ["contribution_id"]=> string(3) "466" ["receive_date"]=> string(19) "2018-11-16 00:00:00" ["civicrm_value_gift_aid_submission_id"]=> string(0) "" ["custom_34"]=> string(0) "" ["id"]=> string(3) "466” }

so we see that custom_34 (Eligible for Gift Aid) is a zero length string, and self::DECLARATION_IS_NO is int(0) (is this comparison even allowed in PHP7?) . The test returns FALSE, so these contributions aren’t included in the batch. Should custom_34 be set to “1” or “Yes” somewhere, or is the comparison at fault?

btw, there are some “=& new’ lines in CRM/Giftaid/Utils/Contribution.php which PHP7 doesn’t allow. Seem to be still there in the latest master version on the github site, although I see mattire did a patch; will this be incorporated?

Regards

Tom

On 21 Jan 2019, at 14:57, Rich Lott notifications@github.com wrote:

My entry at civicrm/admin/options/payment_instrument was also blank for Account. I don't think it should be (it says it's mandatory), so I'll mark this as a bug. But that had clearly not caused the problem in my case.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/artfulrobot/uk.artfulrobot.civicrm.gocardless/issues/51#issuecomment-456101657, or mute the thread https://github.com/notifications/unsubscribe-auth/AOLKTcX6B1P80VahCMkc6y-QlfZL-4-xks5vFdVxgaJpZM4aJw_P.

[artfulrobot]

Hi Tom,

The PHP comparison operator == means allowing type conversion, so "" == 0 is true. They should probably be using === which also compares type as well as value, so "" === 0 is not true.

It seems that the problem is that the Giftaid field is not being set (by the Giftaid extension) on the contribution.

The Giftaid extension separate to this https://github.com/compucorp/uk.co.compucorp.civicrm.giftaid

It's possible that the missing account was in some way a cause of the Giftaid extension not doing its thing. Or any number of other possibilities. Tests would be: set up a new GC DD, tick the Giftaid box and inspect the contribution created - what's its Gift Aid status? What's its status when it gets marked Completed? Also then inspect the next one to come in. Nb. for testing, I think weekly is the shortest period you can specify for GC (it does not allow daily, which is annoying for testing!)