March 1, 2019 at 7:13 pm #19756
Self-hosting on 4.5.11 but tested on all versions back to 4.5.7
This morning I was expecting our recurring invoices to be sent out to clients. The cron job runs a simple script at 06:30UTC that pipes the output of artisan to a file so we can check for errors etc.
This morning the script ran, counted the number of recurring invoices correctly but didn’t create or send them. At 08:00 I manually ran the cron script and the log file was exactly the same. I then went to a meeting and came back at 09:10 to continue debugging this. When I ran the cron script then, the invoices were created and the email system triggered.
I had a problem with triggers when I first setup IN. The cron job originally ran at 00:15UTC but as above, nothing was created.
So what causes the system to create/send recurring invoices?
I ask because I edited one of the invoices yesterday afternoon and wondered if the time of the edit has a bearing on the trigger mechanism.
Is there a way to control this trigger so that I could run the cron job at a time of my choosing safe in the knowledge that invoices would be created and emailed?
I rely on the recurring invoice feature so I’m very keen to get this working reliably as I’m often travelling on the first day of the month when they are due to be created so can’t do it manually (like today) if there is a problem.
Many thanks as always for your help.March 2, 2019 at 4:44 pm #19759
Maybe it’s related to the timezone, which timezone are you in?March 2, 2019 at 4:53 pm #19761
I’m in the UK so UTC – we ignore summer time on our serversMarch 2, 2019 at 5:28 pm #19764
Sorry, in that case I’m not sure what the problem is.
You want to try running the cron later in the day.March 3, 2019 at 11:02 pm #19792
I was afraid of that 😉
ThanksMay 1, 2019 at 7:35 pm #20615
Apologies or revisiting an old post, but the problem re-occurred this morning with a twist.
The cron job ran at 05:30UTC (we’re in the UK) as usual. Last month all recurring invoices were sent out so I thought this problem had righted itself. Today 50% of the recurring invoices were sent and 50% not. WTF???
Where do I start looking to get the bottom of this? As I travel extensively I must have recurring invoices working reliably as I’m often unable to “baby sit” this for several days and late invoicing means late revenue for me ;}
ThanksMay 2, 2019 at 5:17 am #20617
Is there a pattern between the ones that were/weren’t sent?
If you keep the log output of the cron it’s worth reviewing, otherwise you can try running the cron from the command line to review the output.May 3, 2019 at 6:55 am #20627
OK this is now getting weird. Because I was travelling, I couldn’t make any changes in the app and yesterday the remaining recurring invoice was sent out 24 hours after it should have been. I’ve always felt that there was some sort of time/date “trigger” to this problem and this delayed send would suggest that.
I always capture the output of the cron job so I can check for any issues (like this one!) and I took a copy of the one on 1st May which is below – it’s not very helpful as far as I can see. Is there any way of increasing the debugging information/output from artisan?
Wed, 01 May 2019 05:30:10 +0000 Running SendRecurringInvoices…
Wed, 01 May 2019 05:30:16 +0000 2 recurring invoice(s) found
Wed, 01 May 2019 05:30:18 +0000 Processing Invoice: 48
Wed, 01 May 2019 05:30:28 +0000 Not billed – Sending Invoice
Wed, 01 May 2019 05:31:04 +0000 0 recurring expenses(s) found
Wed, 01 May 2019 05:31:04 +0000 Done
Wed, 01 May 2019 05:31:07 +0000 Running SendReminders…
Wed, 01 May 2019 05:31:08 +0000 2 due recurring invoice instance(s) found
Wed, 01 May 2019 05:31:08 +0000 0 accounts found with fees enabled
Wed, 01 May 2019 05:31:08 +0000 1 accounts found with reminders enabled
Wed, 01 May 2019 05:31:08 +0000 Enhancing Clarity Ltd: 0 invoices found
Wed, 01 May 2019 05:31:08 +0000 Enhancing Clarity Ltd: 0 endless invoices found
Wed, 01 May 2019 05:31:09 +0000 0 scheduled reports
Wed, 01 May 2019 05:31:17 +0000 DoneMay 3, 2019 at 6:56 am #20628
We don’t support changing the log level.
Do the recurring invoices have the same date settings?May 3, 2019 at 7:27 am #20629
Re log level, is there any other log I can review to try and resolve this? PHP or MySQL?
With respect to “same date settings” I’m not sure what you are asking for. Each recurring invoice is set up when we take on a new client. All recurring invoices are set to fire on the 1st day of the month as my company is paid a monthly retainer. So if we land a new client this month, the initial date for their recurring invoice will be 1st June 2019.
Is that what you were asking?May 3, 2019 at 7:29 am #20630
So you’re saying the start date was changed by a day?
Anything’s possible but this is the first time I’m hearing of this issue, if this bug existed I would expect to hear about it from more users. The start date can get changed but it would happen if it’s the 31st and the month only has 30 days.May 3, 2019 at 7:36 am #20631
Correct. The invoices should have fired on 1st May – one did (which was the first invoice for a new client), one fired yesterday (2nd May) for a long standing client – 1st January was when we switched over to IN for our invoicing needs – and then changed the future firing date for this client’s invoices to 2nd of the month going forwards (I’ve filed a report on GitHub)May 3, 2019 at 7:39 am #20632
Can you clarify, did you manually “change the future firing date for this client’s invoices to 2nd” or did this happen on it’s own?May 3, 2019 at 7:55 am #20633
It happened on it’s own (ie IN changed the date to 2nd of the month because the invoice fired on 2nd May). As I mentioned above, I was travelling on the 1st without access to the system – the logs are rotated by my cron script for that reason.
I have today edited the invoice and reset to start date to 1st June 2019 so that it fires correctly next month.
You must be logged in to reply to this topic.