Hoe Terugkerende Factuurplanning Daadwerkelijk Werkt

Wanneer je terugkerende facturatie inschakelt voor een factuur, "onthoudt" het systeem niet simpelweg om deze opnieuw te versturen. Het maakt een apart planningsrecord aan, berekent een volgende uitvoerdatum, en geeft dat record door aan een achtergrondproces dat op vaste intervallen controleert welke planningen verschuldigd zijn. Dit artikel legt precies uit hoe dat werkt — de frequentie-opties, hoe de volgende datum wordt berekend wanneer een maand korter is dan verwacht, wat er met de vervaldatum gebeurt, en wat je moet controleren als een terugkerende factuur niet is verstuurd wanneer je dat verwachtte.

Wat Er Gebeurt Zodra Je Terugkerende Facturatie Inschakelt

Elke factuur behoort tot een factuurgroep. Wanneer je die groep markeert als terugkerend en een frequentie kiest, schrijft het platform één rij naar een toegewijde planningstabel: je werkruimte-ID, de factuurgroep-ID, de frequentie, en een berekende next_run_at-datum. Deze rij is volledig gescheiden van de factuur zelf — de factuur is je sjabloon, en de planning is de instructie voor wanneer deze de volgende keer moet worden gekloond.

Als je de factuur later bewerkt — het bedrag wijzigt, de frequentie omzet, of terugkerend uitschakelt — wordt de planning bijgewerkt om overeen te komen. Het uitschakelen van terugkerend verwijdert de planning niet; het zet een vlag die deze inactief markeert, zodat het later opnieuw inschakelen van terugkerend netjes wordt opgepakt in plaats van een dubbele planning te creëren.

De Vier Frequentie-Opties en Hoe de Volgende Datum Wordt Berekend

Er worden vier frequenties ondersteund: wekelijks, maandelijks, per kwartaal, en jaarlijks. Wekelijks is het eenvoudigst — het voegt gewoon zeven dagen toe aan de ankerdatum. Maandelijks, per kwartaal, en jaarlijks werken allemaal door kalendermaanden toe te voegen (één, drie, of twaalf) aan de datum.

Het deel dat de moeite waard is om te begrijpen, is wat er gebeurt wanneer de doelmaand korter is dan de maand waarin je begon. Als je factuurdatum 31 januari is en de frequentie maandelijks, heeft februari geen 31e dag. Naïef een maand toevoegen in JavaScript zou de datum stilletjes laten doorrollen naar 3 maart — een bug die je facturatiedatum elke maand verder zou laten afdrijven totdat het uiteindelijk geen zin meer zou hebben. In plaats daarvan detecteert het systeem wanneer de maandoverloop heeft plaatsgevonden en klemt het de datum terug naar de laatste geldige dag van de bedoelde maand. Dus 31 januari terugkerend maandelijks wordt 28 februari (of 29 in een schrikkeljaar), dan 31 maart, dan 30 april — elke gebeurtenis komt terecht op de laatste dag van zijn maand in plaats van naar voren te schuiven.

Hoe de Vervaldatum Wordt Doorgezet

Wanneer een nieuwe gebeurtenis wordt gegenereerd, kopieert het systeem niet zomaar de vervaldatum van de sjabloonfactuur — het herberekent deze. Het meet het gat in dagen tussen de oorspronkelijke factuurdatum en de vervaldatum (bijvoorbeeld, een Netto 14-voorwaarde is een gat van 14 dagen), en past datzelfde gat toe op de nieuwe factuurdatum. Dit betekent dat als je oorspronkelijk Netto 14-voorwaarden instelde, elke toekomstige gebeurtenis automatisch een vervaldatum krijgt die 14 dagen verwijderd is, ook al zijn de kalenderdata elke keer anders.

Wat Wordt Gekloond, en Wat Niet

Elke nieuwe gebeurtenis is een echt nieuwe factuurgroep met zijn eigen ID, geen bewerking van de vorige. De regelitems, klant, valuta, en sjabloon-instellingen worden allemaal ongewijzigd doorgezet. Wat wordt gereset: de factuurdatum wordt vandaag, de vervaldatum wordt herberekend op basis van de hierboven beschreven offset, het betaalde bedrag reset naar nul, en de betalingsdatum en -methode worden gewist. Als je een basisfactuurnummer hebt ingesteld, krijgt elke gebeurtenis een achtervoegsel zoals -R2, -R3, enzovoort, zodat je nummeringsreeks traceerbaar blijft naar de terugkerende serie zonder te botsen met je reguliere factuurnummers.

Als de oorspronkelijke sjabloonfactuur inmiddels is verwijderd, heeft de planning niets meer om van te klonen. In plaats van stilletjes te falen of een fout te gooien bij elke toekomstige controle, deactiveert het systeem die planning de eerste keer dat het ontdekt dat de bron weg is.

Concept versus Verzonden: Wat Bepaalt of de Nieuwe Factuur Automatisch Wordt Gemaild

Of de zojuist gegenereerde factuur wordt aangemaakt als concept of onmiddellijk wordt verzonden, hangt af van één ding: of de factuur een klant-e-mailadres heeft geregistreerd. Als dat zo is, wordt de nieuwe gebeurtenis gemarkeerd als "verzonden" en gaat er automatisch een e-mail uit naar dat adres. Als er geen klant-e-mailadres is gekoppeld, wordt de gebeurtenis in plaats daarvan opgeslagen als concept, en wordt er niets gemaild — je zou het moeten openen en handmatig moeten versturen. Dit is een bewuste beveiliging: het systeem mailt nooit stilletjes een document naar niemand, maar het blokkeert automatisering ook niet alleen omdat je niet elk veld hebt ingevuld.

Hoe Vaak Het Systeem Daadwerkelijk Controleert op Verschuldigde Facturen

Een achtergrondproces controleert standaard elk uur op verschuldigde planningen (configureerbaar via een omgevingsvariabele, hoewel de meeste accounts dit nooit aanraken). Omdat facturatiedata op dagniveau zijn — niets aan terugkerende facturatie vereist precisie op minuutniveau — is elk uur controleren meer dan voldoende; er is geen voordeel aan vaker pollen, en het zou alleen serverkracht verspillen. Wanneer het proces draait, zoekt het naar elke planning waarvan next_run_at vandaag of eerder is, genereert het de volgende factuur voor elk, en verplaatst het de volgende-uitvoerdatum van die planning één interval verder. Het verwerkt tot 50 verschuldigde planningen per doorloop, wat comfortabel zelfs een grote achterstand dekt als het proces een tijdje gepauzeerd was.

Als een Terugkerende Factuur Niet Is Verstuurd

De meest voorkomende oorzaken, in volgorde van waarschijnlijkheid: de planning is gedeactiveerd omdat terugkerende facturatie is uitgeschakeld (controleer de terugkerend-schakelaar van de factuur), de bron-sjabloonfactuur is verwijderd (de planning deactiveert zichzelf stilletjes), of er is geen klant-e-mailadres op de factuur, dus deze is correct gegenereerd maar bleef als concept staan in plaats van te worden verstuurd. Geen van deze zijn fouten in het onderliggende mechanisme — de planning en het proces doen precies wat hen wordt opgedragen; de gebruikelijke oplossing is controleren welke van de drie bovenstaande voorwaarden van toepassing is op jouw specifieke factuur.

Veelgestelde Vragen

Verandert het bewerken van een eerdere gebeurtenis toekomstige gebeurtenissen? Nee. Elke gegenereerde factuur is onafhankelijk zodra deze is aangemaakt. Het bewerken van gebeurtenis #3 heeft geen effect op gebeurtenis #4 — alleen het bewerken van de terugkerende instellingen op de actieve planning verandert wat er vanaf nu gebeurt.

Kan ik meer dan één terugkerende planning per klant hebben? Ja. De terugkerende status wordt bijgehouden per factuurgroep, dus een klant kan meerdere onafhankelijke terugkerende facturen hebben — bijvoorbeeld een maandelijkse retainer en een aparte kwartaal-onderhoudskost — die op volledig verschillende planningen draaien.

Wat gebeurt er als ik de frequentie halverwege wijzig? De volgende-uitvoerdatum wordt herberekend vanaf vandaag met de nieuwe frequentie, dus de wijziging treedt in werking bij de allereerstvolgende gebeurtenis in plaats van met terugwerkende kracht.