Bug with XML SEPA generation for FRST

[LesCarnets]

Hello,

I am facing issue with XML SEPA generation for FRST

Bug

From the invoice list generate oders for 2 customer (one with FRST set on his bak account, the other with RCUR). Then from the "Bank" generate the 2 prelevment orders: one for FRST, the other for RCUR. The RCUR XML file is well working. But the FRST XML file is wrong: sum on transation in the header of the order is "0€" (it should be sum of the lines).

Environment

• Version: 14.0.2
• OS: Linux webdb46.lwspanel.com 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) x86_64
• Web server: Lunix shared hosting
• PHP: 7.0.33
• Database: MySQL or MariaDB 5.5.5-10.3.25-MariaDB-0+deb10u1
• URL(s): /compta/prelevement/create.php

Edit

I did a test with Version 13.0.3 and 13.0.4, Direct debit orders are wrong whatever we are in FRST or in RCUR as you can see:

[eldy]

This looks strange as i can't reproduce trouble with this versions. Can you reproduce this on demo.dolibarr.org ?

[LesCarnets]

Hi @eldy,

Thank you for your time.

Unfortunatly, I cannot test on the demo as I am told my ICS is missing even if it is configured (cf. screenshots) And I was not able to test on this version 14.0.3 as it seems not available on SourceForge (the button "Create direct debit file (all)" seems so good as, till version 14.0.2 I have to create separately 2 XML files: one for FRST, the other for RECUR)

When you try to reproduce, did you create a global order by selecting several invoices from the billing module? I just tried again for 2 clients with default banck account defined as "FRST" and the direct debit order is still with a global amount of 0€ instead of the sum of my invoices :( From /compta/facture/list.php

Please find dolibarr log file: dolibarr.log

Thank you for your help, Best regards

[eldy]

I have updated demo so you should be able to test now (i think). Also, version 14.0.3 is now available on sourceforge...

[LesCarnets]

Hi @eldy,

Thank you for that!

I upgraded my sandbox to 14.0.3 and, unfortunatly, I am still able to reproduce the bug for both (RCUR and FRST orders):

Besides, I have 2 concerns (maybe it is just bad settings on my side): 1) On demo.dolibarr.org, there is a single button creating a direct debit order for both FRST and RCUR: But on my sandox with same version, there are still dedicated orders for FRST and RCUR How can I get the same?

2) When I create an order for clients with their banck account set as "FRST", then I would except once the order is validated, the client account to be automatically set to "RCUR" and this is not the case. How can I configure that to avoid a manual operation (taking time and bringing high risk of human mistake)?

Thanks you again for your help and best regards,

[LesCarnets]

PS: Regarding test on demo.dolibarr.org

I created my invoices did a direct debit request from there:

But I am still told the ICS is not configured (even is this is done for the account I used):

Thanks and best regards,

[LesCarnets]

Hello @eldy,

I just noticed the bug happend only on clients imported from my previous system via an excel file. So I created one of them manualy in Dolibarr and checked in DB the différences, then I corrected it in SQL: UPDATE llx_societe SET tva_assuj=1, localtax1_assuj=NULL, name_alias='', fk_pays=1, fk_account=0; I can confirm this SQL fixed my issue as the Direct Debit Orders are now fine!

Reminding questions:

1. On demo.dolibarr.org, there is a single button creating a direct debit order for both FRST and RCUR but on my sandox (with same version), there are still dedicated orders for FRST and RCUR. How can I get a sigle one as you did on demo.dolibarr.org? It seems Dolibarr doesn't allow it for European companies (the button is in the "else" of the if ($mysoc->isInEEC()) at line 253 of compta/prelevement/create.php). But I cannot explain this limitation as all other tools allow you to create SEPA XML files with both FRST ans RCUR even in Europe.
2. When I create an order for clients with their banck account set as "FRST", then I would except once the order is validated, the client account to be automatically set to "RCUR" and this is not the case. How can I configure that to avoid a manual operation (taking time and bringing high risk of human mistake)?
3. Was this strange total during direct debit orders generation normal behaviours due to thirdparties fields values or do we need to keep the issue open? Here are previous values: tva_assuj=NULL, localtax1_assuj=0, name_alias=NULL, fk_pays=NULL, fk_account=NULL

Thanks and best regards,

[eldy]

"On demo there is a single button". You probably are testing the SEPA "credit transfer" or supplier instead of "Direct debit" of customers. On credit transfer, there is no "FIRST" RECUR" status to do. There is for the moment no way to auto switch the FIRST/RECUR but you must know this information is not (and was probably never used correctly by the bank). You can make all payment with mode FIRST (even if this is not first) and you may use RECUR even for the first one on some banks. I still don't have explanation why things are wrong with record imported. Do you know what was the value for each field before you did the sql update ?

[LesCarnets]

Hi @eldy,

Yes, here are the values before in table llx_societe: tva_assuj=NULL, localtax1_assuj=0, name_alias=NULL, fk_pays=NULL, fk_account=NULL and values after corection: tva_assuj=1, localtax1_assuj=NULL, name_alias='', fk_pays=1, fk_account=0 I don't know if the fix was linked to only one of these filds or a combinaison.

Regarding the sigle button, I confirm I can see it for Direct Debit on demo.dolibarr.org Acctually, it seems Dolibarr doesn't allow it for European companies (the button is in the "else" of the if ($mysoc->isInEEC()) at line 253 of compta/prelevement/create.php). But I cannot explain this limitation as other tools allow you to create SEPA XML files with both FRST ans RCUR even in Europe.

About the auto switch from FIRST to RCUR, if this is your recommandantion, I will request all my payments as FRST. I hope my clients will not be notified by their bank each month (I know some banks are sending email to their clients when a new direct debit is requested on their account). In the future, it would be wonderful if this auto switch can be added to the roadmap in case banks change their mind and become less lax.

Thanks and best regards

[eldy]

To be able to generate a SEPA file, your company must be inside th ECC. If not, SEPA files should be useless for you. Autoswitching FIRST to RCUR was planned, but seeing that FIRST and RCUR has same effect, priority has been set to very very low. You should not experience trouble. If you have, thanks to report us.

i still dont understand why the field update have an impact on feature. May be a test by setting fk_pays=1 or fk_account=0 back to NULL will allow to find which of this 2 fields generated the bug (i think it is one of them, it is on of this two one)

[LesCarnets]

Ok, thank you.

I will try with FRST for a couple of months and let's see what happends.

Best regards,

[LesCarnets]

Hello @eldy,

I wish you a merry Christmas.

I tried your suggestion and send November and December paiements order as "FRST" for all my clients and I got the money for everybody.

Nevertheless, some of them received a mail from their bank telling a new direct debit will start on their account. And, unfortunately, they got it for both occurrences I generated.

You should not experience trouble. If you have, thanks to report us.

So, I am coming back to you :(

NB: the couple of affected clients have their account hosted in the same bank (Crédit Agricole) but I know some other clients using the same bank didn't receive any postal mail

Here is a picture of what the client got from his bank:

Thanks and best regards,

[LesCarnets]

Hello @eldy,

I can see version 15.0.0 is now available, will it improve de way how the FRST/RCUR works? (the 2 clients are still get the bank notification each month :( )

Thanks and best regards

[youl94]

Hello, I have the same problem on a 13.0.4 version, where the client imported Tiers without filling in fk_account or/and fk_pays, i find NULL on many society.

This, by filling in fk_pays = 1 AND fk_account = 0, the SEPA generation works again. No matter FRST or RECUR mode...

This corrects the SEPA generation problem.

[github-actions[bot]]

This issue is stale because it has been open 1 year with no activity. If this is a bug, please comment to confirm it is still present on latest stable version. if this is a feature request, please comment to notify the request is still relevant and not yet covered by latest stable version. This issue may be closed automatically by stale bot in 10 days (you should still be able to re-open it if required).