Recurring templates say when they are failing, and which period they last invoiced
is_failing flags a template from its first failed run, and last_generated_scheduled_date gives the latest period it has already invoiced.
Two read-only fields on every recurring template. They answer two questions you used to have to work out from the history: is this template in trouble, and how far has it invoiced.
Both are derived on every read from what is already stored. Nothing else changes because of them.
What else changed
is_failingistruefrom the first failed unattended run, even whilestatusis stillACTIVEand before any warning email, which only goes out every third failure in a row. It is alsotruefor a template paused because generation kept failing. A successful generation clears it.last_generated_scheduled_dateis the latest period already invoiced: the highestscheduled_datein the generation history, ornullif the template never generated an invoice.- It is not the date of
last_generated_at. That is when the most recent invoice was created. A generate-now creates today an invoice for a future period, so the two diverge on purpose. - A skip does not move it, and neither does deleting an invoice, with one exception: deleting the draft of the latest generation frees that period, so the date moves back to the previous one.
Endpoints
- GET/v1/companies/{company_id}/recurring-invoices/{recurring_invoice_id}is_failing and last_generated_scheduled_date
Where to go next
A recurring template that emails its invoices needs someone to email
Saving a template with `send_automatically: true` and no recipient now answers `422 SIN_DESTINATARIO_RESOLUBLE`, and malformed recipient addresses are rejected.
A recurring template cannot produce an invoice with a negative total
Negative line totals on a template, a generated invoice adding up below zero, and editing a draft to a negative total are now rejected.