Recurrent Invoices in 2.4 is not sending

There might be a delay in generating the PDF file that needs to be emailed. Try a sleep time waster or check for the presence of the last invoice in the PDF before attempting to email.

It is hard to guess what is going wrong, so perhaps you could so some more troubleshooting to find the source of the bug.

1. On your browser, position your cursor on the Email Recurring Invoice line.  On Firefox, the url will display in the lower left corner and you can right-click to bring up a menu with the Open Link in New Tab/Window or Copy Link Location.

This should run the code to send your invoice email, but obviously that does not work on your system.  But you can examine the URL to see if there is anything wrong with it.

REP_ID=107 is the Print Invoices report, the same one that appears in Customer Sales Reports.   In this report,

    $from = $_POST['PARAM_0'];
    $to = $_POST['PARAM_1'];
    $currency = $_POST['PARAM_2'];
    $email = $_POST['PARAM_3'];
    $pay_service = $_POST['PARAM_4'];
    $comments = $_POST['PARAM_5'];
    $customer = $_POST['PARAM_6'];
    $orientation = $_POST['PARAM_7'];

One change in 2.4 is more flexible reference numbers.  Perhaps PARAM_0 or PARAM_1 have some unsupported special characters?

2.  You have said that  the Print Invoices report works on these invoices.  If so, then the problem has to be the calling parameters or some obscure problem with the print redirect page, which is very simple.  The next step then would be to instrument these pages to see where the call is being dropped.

3.  Look to see if the email is being sent out of your system.  On most linux systems, this is logged in /var/log/syslog.   Or, if you have a SMTP server, you can log into that and review its log files.   Do this to confirm that the problem is indeed internal to FA.

I still suggest capturing the email link from Create and Print Recurrent Invoices and running it directly in the browser, as I suggested in point 1.  This should work and display the email sent message in that window.  If that does not work but selecting the invoice in Print Invoices does, then the problem has to be the invocation of the Print Invoices page from the print redirect page.   This could be a browser or server issue as well, so checking the apache server logs or changing browsers could change the result.

Also make sure that debugging is turned on in config.php ($debug = 1).

Good work!  Now you can see the url that does work (Direction invoice creation) and the url that does not work (recurrent invoice) and lo and behold they differ which must somehow explain why one works and the other doesn't. 

Oddly, on my 2.4.6 system, the direct invoice email link is:

/reporting/prn_redirect.php?PARAM_0=11-10&PARAM_1=11-10&PARAM_2=&PARAM_3=1&PARAM_4=&PARAM_5=&PARAM_6=&PARAM_7=0&REP_ID=107

and the recurrent invoice email link is:

/reporting/prn_redirect.php?PARAM_0=12-10&PARAM_1=12-10&PARAM_2=&PARAM_3=1&PARAM_4=0&PARAM_5=&PARAM_6=1&REP_ID=107

Oddly, these seem to be reversed on your system?  (Might I assume that you got them backwards in your post?)

Note that you can enter these urls in your browser and they should send mail, although we know the recurrent invoice url on your system will not work.  I suggest putting the recurrent invoice url into your browser, and removing the "1" after PARAM_6.

On my system, the link would be:

/reporting/prn_redirect.php?PARAM_0=12-10&PARAM_1=12-10&PARAM_2=&PARAM_3=1&PARAM_4=0&PARAM_5=&PARAM_6=&REP_ID=107

All these urls send mail on my system.  My latest guess is that you might be having a php version issue that is causing this problem.  What version are you running?

I tried php 7.1 and it works fine.

I suggest playing with the url in the browser as I mentioned in my last post.  The goal is to find out why one url works and the other doesn't.   That will give a clue as to what the problem is.  My thinking is that it is PARAM_6 but that is a guess at this point.

This is coded in sales/create_recurrent_invoices.php.  The code:

        $ar = array('PARAM_0' => $min."-".ST_SALESINVOICE,  'PARAM_1' => $max."-".ST_SALESINVOICE, 'PARAM_2' => "",
            'PARAM_3' => 0, 'PARAM_4' => 0, 'PARAM_5' => "", 'PARAM_6' => user_def_print_orientation());
        display_note(print_link(sprintf(_("&Print Recurrent Invoices # %s - # %s"), $min, $max), 107, $ar), 0, 1);
        $ar['PARAM_6'] = 1; // orygina³
        $ar['PARAM_3'] = 1; // email
        display_note(print_link(sprintf(_("&Email Recurrent Invoices # %s - # %s"), $min, $max), 107, $ar), 0, 1);

looks to me to be in error, because as I listed in my first post, PARAM_6 is the customer and PARAM_7 is the print orientation.

The code should probably be:

       $ar = array('PARAM_0' => $min."-".ST_SALESINVOICE,  'PARAM_1' => $max."-".ST_SALESINVOICE, 'PARAM_2' => "",
            'PARAM_3' => 0, 'PARAM_4' => 0, 'PARAM_5' => "", 'PARAM_6' => "", 'PARAM_7'=>user_def_print_orientation());
        display_note(print_link(sprintf(_("&Print Recurrent Invoices # %s - # %s"), $min, $max), 107, $ar), 0, 1);
        $ar['PARAM_3'] = 1; // email
        display_note(print_link(sprintf(_("&Email Recurrent Invoices # %s - # %s"), $min, $max), 107, $ar), 0, 1);

Ha ha.  I had been testing using customer 1, and the code erroneously hard coded PARAM_6 to 1, so coincidentally it worked for me.

This has been fixed in core and committed to stable repo.

The fixed file can be downloaded here.

Thanks for finding this!

/Joe