Jak jsem přidával funkci pravidelných faktur do FakturHuko
Systém pravidelnosti potřeboval vlastní UX, vlastní práci s drafty, samostatné e-mailové nastavení a taky několik ochran proti chybám, které se v ostrém provozu umí nepříjemně projevit.
Základ celé funkce stojí na šablonách. Každá má svoji periodu, datum dalšího vystavení, stav automatického odesílání a navázaný draft další faktury. Důležité pro mě bylo, aby uživatel na první pohled viděl nejen samotnou šablonu, ale i to, co se bude dít dál.
Velké téma bylo první odeslání. Jeden univerzální proces vypadal na začátku jednoduše, ale v praxi vedl ke zmatku. Lepší bylo rozdělit akce jasně na vystavit a odeslat hned, nebo teprve naplánovat odeslání. U takové funkce je lepší vést uživatele dvěma srozumitelnými cestami než jedním chytrým formulářem.
Důležité bylo i oddělení šablony od konkrétního draftu. Pravidelná šablona nesmí být totéž co faktura, která se má právě odeslat. Draft musí jít upravit zvlášť, aniž by rozbil původní nastavení celé série. Díky tomu se dají řešit i jednorázové výjimky bez toho, aby se rozpadlo další opakování.
Zajímavé bylo i chování položek s nulovou nebo nevyplněnou cenou. V šabloně dávají smysl jako připravené řádky pro pozdější doplnění, ale nemají se objevit v PDF, tisku ani veřejném náhledu. Bylo tedy potřeba oddělit interně uloženou strukturu od toho, co skutečně uvidí klient.
Podobně dopadly i e-mailové šablony. U běžných faktur často stačí výchozí nastavení na klientovi, ale u pravidelných faktur to přestává fungovat. Jeden klient může mít více různých sérií a každá může chtít jiný text e-mailu nebo jiné chování příloh. Proto dává větší smysl držet tohle nastavení přímo na úrovni konkrétní šablony pravidelné faktury.
Nakonec se ukázaly i klasické provozní detaily: časová pásma, lokalizace a bezpečnost. Nestačí uložit jen datum, protože správný čas musí sedět i z pohledu klienta, který může být v jiném časovém pásmu. Právě u automatizovaných procesů se nejrychleji ukáže, jestli je datový model opravdu čistý.
Ve výsledku se potvrdilo, že pravidelné faktury nejsou jen „faktura + cron“. Jakmile má být celý proces použitelný a spolehlivý, začne se řešit UX, stav draftů, e-maily i spousta malých detailů okolo. Mám pocit, že bych na tom mohl strávit klidně ještě pár dalších seancí a ladit a ladit a ladit.