The fixed file can be downloaded here.

Thanks for finding this!

/Joe

        $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.

Where would this be coded?

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.

On the one system I have FA 2.4.4  with PHP Version 7.1 and the other system I have FA 2.4.6 and PHPversion 7.1 Both have the same issue not sending email on recurring invoices.

Normal email tax invoice is the one:

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

The one without the _7 is then recurring invoice email.

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?

On the Direct Invoice creation email option it has the following for email function:

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

On recurrent invoices the email option have the following:

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

It seems like the difference is that the recuurent invoice has a _7=0&REP_ID=107 whereas the Direct invoice email function have _6=1&REP_ID=107

Maybe you can figure out the difference, but I think the recurrent invoice email option should not have the _7, since the print function does not have a _7

Trust this will help to resolve the issue?

Wynand

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

They both point to REP_ID=107

You can email it from sales reports, and you can mail it from Template invoices but not from Recurring invoices. Normally it would display a green bar that the email was successfull, but it does not do anything.

Surely it would use the same PARAM is the email function is used either via Sales Reports, or after editing the invoice via Transaction Inquiry?

Have no idea what you are talking about here.

There is nothing. not send, no record.

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.

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.

@apmuthu

Have no idea what your are suggesting with sleep time waster.

In 2.3.26 it worked fine, no issues. In 2.4 nothing happens once you created the repeating invoice and you select the email invoice. You can open and print the invoice in pdf, but not mail it.

I think it is not reading the customer email addres or something. Not sure what the inner workings is supposed to do her and how that would differ from the normal direct or template invoice creations?