SEPA payment processor (classic version) produces extra (erroneous) financial_transactions

[Detsieber]

Actual behaviour:
The classical SEPA payment processor creates a (wrong) financial_transaction record in the table civicrm_financial_trxn, at the time the mandate is entered. These entries are marked as "completed", and have a wrong payment method.

When the SEPA group is marked as "received", another financial_transaction record is created, with the correct values.

This creates severe problems for use cases, that are using the table civicrm_financial_trxn: e.g. CiviCRM invoices, accounting export.

The issue is only happening with OOFF payments, not with FRST/RCUR payments.

Workaround:

With the SEPA NG payment processor, this does not happen.
However, the SEPA NG payment processor currently does not support event payments (see #17)

[UeNu9]

We are experiencing the same problem in our system, using Memberships that create One-off Contributions: https://civicrm.stackexchange.com/questions/44791/creation-of-one-off-membership-creates-a-completed-payment-too

[peetCreative]

As this Link from @UeNu9 is dead I copy the text here.

We are experiencing the same problem in our system, using Memberships that create One-off Contributions: https://civicrm.stackexchange.com/questions/44791/creation-of-one-off-membership-creates-a-completed-payment-too

Our CiviCRM system (CiviCRM 5.58.1) uses Civi Membership as well as the CiviSEPA extension (SEPA Direct Debit version 1.8.0 with CiviSEPA Payment Processor version 1.1.0) to process payments. The system provides a public online form (CiviCRM contribution page) where people can create a one-off membership for themselves. When this membership is created in the system, at the same time a payment with status "Completed" is also created. Which seems wrong.

Later, the new member actually pays, and a script I wrote would fetch this payment from the bank statement and create it in CiviCRM via API. So now, in the GUI, the membership shows two completed payments instead of one. And, most importantly, the membership duration doubles because two payments exist. Which is wrong. This only affects one-off memberships, recurring memberships are fine.

I only found this other issue about the same topic, but without solution: #5

Can anyone give me a hint as to why this might happen? Does someone work closely with the CiviSEPA extension and could point me to the code responsible for this functionality?

I understand that the CiviSEPA extension does not fully support membership payments yet, but if I can fix this problem, this could be a step towards a more complete payment processing available for CiviCRM :)

[peetCreative]

#44
Solves this issue for Contribution for non repeating Memberships.
Because the creation of a Payment (FinacialTrxn) is here dependent on the payment_status_id.
https://github.com/civicrm/civicrm-core/blob/48e6e28f1af3023577e16437620fdf751c005d0b/CRM/Contribute/Form/Contribution/Confirm.php#L1560

As the apiv3 call to contribution completetransaction will create a Payment.

However for events this problem still remains. Because the parameter is_paylater is set false, a payment is created here:
https://github.com/civicrm/civicrm-core/blob/48e6e28f1af3023577e16437620fdf751c005d0b/CRM/Contribute/BAO/Contribution.php#L3183

because here:
https://github.com/civicrm/civicrm-core/blob/48e6e28f1af3023577e16437620fdf751c005d0b/CRM/Contribute/BAO/Contribution.php#L2950

[vurt2]

@peetCreative Thanks again... sorry for the delay.