Banku, kasu i mejl sam spojio u jedan tok tako što n8n čita mejl banke sa izvodom, izvuče svaku uplatu, po pozivu na broj nađe predračun u Tezga eKasi, zatraži izdavanje fiskalnog računa i pošalje kupcu mejl. Ručni deo koji je ostao: pregled uplata koje nemaju poziv na broj, jednom dnevno, pet minuta.
- Motiv je bio prost: svako jutro sam gledao izvod, tražio ko je platio i kucao račun; sa dvadeset uplata dnevno to je sat vremena i bar jedna greška.
- Tok ima pet čvorova: okidač na mejl banke, izvlačenje redova izvoda, pretraga predračuna po pozivu na broj, poziv API-ja kase za račun, mejl kupcu.
- Puklo je tri puta u prvom mesecu: kupac platio dvaput, dva kupca platila isti iznos bez poziva na broj, mejl izvoda kasnio pola dana.
- Rešenje nije bilo pametniji algoritam nego tri pravila: poziv na broj je obavezan, uplata bez para se ne fiskalizuje sama, isti identifikator ne sme da napravi dva dokumenta.
- Ono što sam naučio u n8n prototipu kasnije je ušlo u samu kasu, pa danas izvod ulazi direktno u nju, a n8n ostaje za ono oko kase: obaveštenja, tabele, poruke vlasniku.
Zašto sam uopšte krenuo da spajam banku i kasu?
Kad sam pravio Tezga eKasu, prvi kupci su bili ljudi koji prodaju bez web shopa: šalju predračun, čekaju uplatu, pa izdaju račun. Taj tok sam i sam živeo. Predračun sa IPS QR kodom ode kupcu, kupac plati, i onda nastupi deo koji niko ne voli: otvoriš e-banking ili mejl sa izvodom, tražiš uplatu, uporediš iznos, setiš se ko je taj kupac, otvoriš kasu, izdaš račun, pošalješ mejl. Šest koraka, tri aplikacije, jedan čovek.
Sa pet uplata dnevno to prođe. Sa dvadeset, kad se posao pokrene, to je sat vremena ujutru i bar jedna greška nedeljno: pogrešan kupac, pogrešan iznos, račun izdat dvaput, račun zaboravljen. A zaboravljen račun nije samo neuredno, to je prekršaj po Zakonu o fiskalizaciji, jer je promet nastao naplatom i račun se izdaje tada, ne kad se setiš. Zato sam hteo da uplata sama nađe svoj predračun i da račun nastane bez mene. Zašto sam uopšte pravio kasu, pisao sam ranije u tekstu zašto sam napravio online fiskalnu kasu; ovo je nastavak te priče na najdosadnijem mogućem mestu, na bankovnom izvodu.
n8n sam izabrao jer sam hteo da vidim tok, ne da ga programiram. Hteo sam da probam ideju za jedan vikend, da vidim gde puca, pa tek onda da odlučim šta ide u samu kasu. To se pokazalo kao ispravan redosled, jer je pucalo na mestima koja nisam predvideo.
Kako izgleda tok od pet čvorova?
Prva verzija je imala pet čvorova i stala je na jedan ekran. Namerno je nisam širio dok nije proradila na stvarnim uplatama.
Pet čvorova u liniji i jedna grana za uplate bez para: to je cela prva verzija toka, a takva je i ostala.
- Okidač na mejl banke. Banka svako jutro šalje izvod kao PDF u prilogu. n8n IMAP čvor gleda samo poruke sa te adrese i samo one sa prilogom. Ništa pametno, ali je prvi izvor problema (o tome niže).
- Izvlačenje redova. Iz PDF-a izvučem tekst i podelim ga na uplate: datum, iznos, platilac, poziv na broj, svrha. Poziv na broj čistim od razmaka i crtica jer ga banke i kupci pišu na tri načina.
- Pretraga predračuna. Za svaku uplatu zovem
GET /api/integrations/documents?externalId=sa identifikatorom koji sam ugradio u poziv na broj. Ako predračun postoji i nije zatvoren, idem dalje. Ako ne postoji, uplata ide u granu „bez para”. - Račun u kasi. Zovem
POST /api/integrations/ordersa istimexternalIdkao predračun,tipDokumenta: racun,nacinPlacanja: Prenos na računi stavkama sa predračuna. Kasa preko V-PFR-a izda fiskalni račun i vrati PFR broj i javni PDF. - Mejl kupcu. Kupac dobije mejl sa računom i linkom na PDF. U prvoj verziji sam mejl slao iz n8n; kasnije sam to prepustio kasi, jer ona ionako ume da pošalje račun mejlom i ne zaboravlja.
Telo poziva za račun, ono što se zaista šalje, izgleda ovako. Ključ ide u zaglavlje i drži se u n8n credentials, ne u čvoru:
POST https://pos.narbiz.com/api/integrations/order?provider=custom
X-Tezga-Api-Key: tzg_<48 heks znakova>
{
"externalId": "PR-2026-0187",
"tipDokumenta": "racun",
"tok": "fiskalni",
"posaljiMejl": true,
"nacinPlacanja": "Prenos na račun",
"kupac": { "naziv": "Kupac sa predračuna", "email": "kupac@primer.rs" },
"stavke": [
{ "naziv": "Konsultacija, 60 min", "sifra": "K60", "kolicina": 1,
"cenaSaPdv": 6000, "poreskaStopa": "OZNAKA_IZ_TAX_LABELS" }
]
}Ceo API, sa svim poljima i kodovima odgovora, opisan je na strani API za fiskalizaciju, a pregled šta se sve može automatizovati ima Trek u vodiču kroz API integracije i automatizacije.
Zašto je poziv na broj postao zakon, a ne preporuka?
U prvoj verziji sam uparivao po iznosu. Predračun na 6.000 dinara, uplata 6.000 dinara, gotovo. Radilo je tačno četiri dana. Petog dana su dva kupca platila po 6.000 i tok je izdao račun jednom od njih dvaput, a drugom nijednom. Storniranje računa nije problem, kasa to ume, ali sam shvatio da uparivanje po iznosu nije uparivanje nego nagađanje.
Od tada je pravilo: poziv na broj je jedini ključ. Predračun bez poziva na broj se ne pravi (kasa to i ne dozvoljava, API odbija predračun bez njega), a poziv na broj nosi identifikator dokumenta. Kad kupac skenira IPS QR kod, poziv na broj putuje sa uplatom bez ijednog kucanja. Kad kupac kuca ručno, može da pogreši, i tada uplata ide u granu za proveru, ne u nagađanje.
Samo prvi stepenik sme da izda račun bez čoveka; drugi traži jedan klik, treći nikad ne pravi dokument sam.
Ovaj dijagram je zapravo najvredniji rezultat celog eksperimenta. Nije algoritam, nego dogovor sa samim sobom šta automatizacija sme, a šta ne sme. Fiskalni račun je dokument koji ide Poreskoj upravi u trenutku izdavanja; pogrešan račun se može stornirati, ali svaki storno ostaje zabeležen. Bolje je da desetak uplata mesečno sačeka moj klik nego da jedan račun ode pogrešnom kupcu.
Šta je puklo u prvih mesec dana?
Ovo je tabela koju sam vodio dok je tok bio nov. Nisam je ulepšavao; ovako je izgledala i ovako su problemi rešeni.
| Šta se desilo | Zašto | Posledica | Kako sam rešio |
|---|---|---|---|
| Kupac platio dvaput | Aplikacija banke mu je prijavila grešku, pa je ponovio | Dve uplate sa istim pozivom na broj, tok pokušao dva računa | Isti externalId u kasi pravi tačno jedan dokument; druga uplata ostaje neuparena i vlasnik vraća novac bez računa jer drugog prometa nije bilo |
| Dva kupca, isti iznos | Uparivao sam po iznosu | Jedan kupac dobio dva računa, drugi nijedan | Poziv na broj postao obavezan; iznos je samo drugi stepenik uz potvrdu |
| Mejl izvoda kasnio pola dana | Banka je promenila vreme slanja | Kupci platili ujutru, račune dobili uveče | Dodao drugi ulaz: PDF izvoda može da se ubaci ručno u bilo koje doba; račun nosi vreme izdavanja, a kupac je unapred obavešten da račun stiže mejlom po knjiženju |
| Poziv na broj sa razmacima | Kupac kucao ručno „2026 0187” | Pretraga nije našla predračun | Normalizacija: uklanjam razmake i crtice pre pretrage; i dalje ne nagađam ako posle toga nema poklapanja |
| Banka promenila raspored kolona u PDF-u | Nova verzija izvoda | Iznos pročitan u koloni datuma, tok stao | Provera zdravog razuma pre uparivanja: iznos mora da bude broj veći od nule, datum mora da bude datum; inače ceo izvod ide na proveru |
| Isti mejl obrađen dvaput | n8n se restartovao usred izvršenja | Rizik od duplih računa | Idempotentnost u kasi ga je pojela: isti identifikator, jedan dokument; ali sam dodao i beleženje obrađenih mejlova |
| V-PFR nedostupan | Prekid na strani Poreske uprave | Račun nije mogao odmah da se izda | API vraća 202, kasa sama ponavlja; tok ne mora ništa, samo ne sme da šalje mejl kupcu pre nego što račun zaista postoji |
Ako bih morao da izvučem jednu lekciju: gotovo svaki problem je bio problem dupliranja ili kašnjenja, a nijedan nije bio problem samog fiskalnog računa. Kasa je radila. Ono što je pucalo bila je moja pretpostavka da spoljni svet (banka, kupac, mejl) radi uredno i na vreme.
Kako izgleda vremenska linija jedne uplate?
Da bih objasnio kupcima zašto račun ne stiže sekund posle uplate, nacrtao sam vremensku liniju jedne prosečne uplate. Ona je i najbolji odgovor na pitanje „gde se gubi vreme”.
Od uplate do računa prođe koliko banci treba da pošalje izvod; sam tok od izvoda do mejla traje sekunde.
Zato sam odustao od obećanja „račun odmah”. Umesto toga kupcu na predračunu piše da račun stiže mejlom po knjiženju uplate, obično sledećeg radnog jutra. Ko hoće brže, može PDF izvoda da ubaci u kasu ručno u toku dana, i to je danas ugrađeno u samu funkciju za novac, banku i naplatu. Sa čime se sve kasa povezuje, uključujući banku i web shop, Trek je opisao u tekstu Sa čim se Tezga eKasa povezuje.
Šta je iz prototipa ušlo u kasu, a šta je ostalo u n8n?
Ovo je deo koji mislim da je najkorisniji za nekoga ko pravi proizvod. n8n prototip je bio ispit: svaki kvar je bio zahtev za proizvod. Posle mesec dana sam imao listu i ona je ušla u kasu ovim redom:
- Izvod ulazi direktno u kasu, mejlom ili kao PDF, bez n8n u sredini. Kasa čita redove i normalizuje poziv na broj.
- Uparivanje po pozivu na broj, pa po jedinstvenom iznosu, sa istim pravilom: samo prvi stepenik izdaje račun sam.
- Predračun bez poziva na broj ne postoji: API ga odbija, a u samoj kasi se poziv na broj dodeljuje automatski.
- Konačan dokument bira firma: fiskalni račun, e-faktura preko SEF-a ako je kupac firma sa PIB-om, ili oba.
- Mejl kupcu šalje kasa, tek kad račun zaista ima PFR broj, nikad pre.
- Neuparene uplate su vidljive na jednom mestu sa obaveštenjem vlasniku, umesto da tiho leže u nekoj tabeli.
n8n nisam izbacio, samo je promenio ulogu. Danas kasa šalje odlazni webhook racun.fiskalizovan, a n8n tok ga hvata i radi ono što kasa ne treba da zna: upiše red u tabelu vlasnika, pošalje mu poruku, obavesti kurira da paket sme da krene. Slično sam radio i sa tokom u kome uplata sama pravi račun, opisano u tekstu o automatskoj fiskalizaciji po uplati. Ceo tok od IPS QR koda do izvoda, sa strane kupca i prodavca, opisan je i u tekstu o naplati IPS QR kodom i uparivanju sa izvodom.
Za svakog ko hoće da pravi slične tokove bez proizvoda iza sebe, agencija je objavila listu 12 n8n automatizacija za male firme, i tri od njih su tačno ovi čvorovi. Sam pristup da prototip pravim u alatu za automatizaciju, pa tek onda kodiram, opisao sam i u tekstu o tome kako razvijam softver sa AI alatima.
Tri pravila koja su ostala kad je prašina legla
Ako preskočiš sve gore, ovo su tri pravila koja bih dao svakome ko spaja banku i kasu, bilo u n8n, bilo u kodu, bilo u glavi.
- Poziv na broj je ključ, iznos je trag. Bez poziva na broj nema automatskog računa. Iznos sme da pomogne, ali samo uz potvrdu čoveka. Ako ti se čini da je to sporo, seti se da pogrešan račun znači storno, objašnjenje kupcu i zapis kod Poreske uprave.
- Isti identifikator, jedan dokument, uvek. Spoljni svet duplira: banka, mejl, webhook, čovek. Idempotentnost u kasi nije opcija za napredne, to je osnovna higijena. Ako tvoja kasa to nema, n8n ne može da je spase.
- Kupca obavesti kad račun postoji, ne kad misliš da će postojati. Mejl pre PFR broja je laž, čak i ako je dobronamerna. Kad je V-PFR nedostupan, čekaj, ponavljaj, ćuti, pa javi.
Ova tri pravila nisu mudrost, nego ožiljci. Svako je nastalo iz konkretne greške iz tabele gore. Ono što mi je drago jeste da su sva tri danas ugrađena u proizvod, pa vlasnik pekare ili salona ne mora da ih uči na svojoj koži. Kako to izgleda iz ugla knjigovođe koji na kraju meseca mora da upari sve to, pišem u tekstu šta knjigovođa traži od web shopa, a jedan korak dalje, gde AI agent prima narudžbine pre nego što uplata uopšte stigne, u eksperimentu sa AI agentom i Viberom.
Propisi koje ovaj tok poštuje su jednostavni: Zakon o fiskalizaciji traži račun u trenutku prometa, a promet kod uplate unapred nastaje naplatom; Pravilnik o vrstama fiskalnih računa kaže da predračun nije fiskalni račun i da uplata na tekući račun nosi način plaćanja „Prenos na račun”. Pravila IPS QR standarda su na sajtu NBS IPS, a tumačenja o elektronskoj dostavi računa kupcu na daljinu na sajtu Poreske uprave. Za sopstveni slučaj proveri sa knjigovođom; ovo nije pravni savet nego iskustvo.
Izvori: Zakon o fiskalizaciji (Sl. glasnik RS 153/2020, 96/2021, 138/2022); Pravilnik o vrstama fiskalnih računa, tipovima transakcija, načinima plaćanja; Tehničko uputstvo za ESIR (Poreska uprava); NBS IPS QR specifikacija; OpenAPI opis Tezga eKase i uputstvo za integratore; sopstveni dnevnik grešaka iz prvog meseca rada toka.
Česta pitanja
Da li mi treba n8n da bih uplatu pretvorio u račun?
Ne. Ono što sam naučio u n8n prototipu ugrađeno je u samu kasu: izvod ulazi mejlom ili kao PDF, uparivanje ide po pozivu na broj, račun nastaje sam. n8n koristim za ono oko kase, na primer poruku vlasniku ili upis u tabelu, preko odlaznog webhooka. Ako ti je dovoljan račun i mejl kupcu, dovoljna je kasa.
Šta ako moja banka ne šalje izvod mejlom?
PDF izvoda može da se ubaci u kasu ručno u bilo koje doba dana, pa uparivanje kreće odmah. To je i brže od čekanja jutarnjeg mejla. Ako banka nudi izvoz u drugom formatu, proveri sa podrškom kase da li ga čita; ne bih tvrdio za svaki format bez provere. Preporuka je da izvod ide svaki radni dan, ne jednom nedeljno.
Kako kupac sazna da će račun stići kasnije, a ne odmah?
Na predračunu i na strani sa IPS QR kodom piše da račun stiže mejlom po knjiženju uplate, obično sledećeg radnog jutra. To očekivanje rešava devet od deset pitanja podrške. Kupac koji plati kartično u shopu navikao je na račun odmah; kupac koji plaća prenosom navikao je da banka radi u svom ritmu, samo mu to treba reći unapred.
Šta ako kupac uplati manje nego što piše na predračunu?
Poziv na broj i dalje nađe predračun, ali iznos se ne slaže, pa uplata ide na potvrdu umesto da sama izda račun. Vlasnik odlučuje: traži dopunu, izdaje račun na manji iznos ako je tako dogovoreno, ili vraća novac. Fiskalni račun uvek mora da odgovara onome što je stvarno naplaćeno, ne onome što je bilo planirano.
Da li ovaj tok radi i za avans?
Radi, uz jednu razliku: ako se novac prima pre isporuke robe ili usluge koja tek sledi, po Pravilniku se izdaje avansni račun, a konačni račun sa pozivom na avansni nastaje pri isporuci. Kasa ima oba dokumenta i API poziv za avans. Kad je promet istovremen sa naplatom, na primer usluga izvršena odmah, dovoljan je običan fiskalni račun.
Koliko je bezbedno da n8n drži ključ kase?
Dovoljno, ako se ključ drži u n8n credentials, a ne u samom čvoru, ako je vezan za IP adresu servera sa koga se zove i ako se rotira na 90 dana, što kasa podržava. Ključ se vidi samo jednom pri pravljenju i čuva se kao heš. Za osetljivije integracije koristim i HMAC potpis zahteva, pa i ukraden ključ bez tajne za potpis ne vredi mnogo.
Šta bih danas uradio drugačije?
Krenuo bih odmah od poziva na broj kao jedinog ključa i preskočio četiri dana uparivanja po iznosu. I ranije bih prepustio mejl kupcu kasi umesto n8n-u, jer kasa zna kad račun zaista postoji, a n8n to samo pretpostavlja. Sve ostalo, uključujući grešku sa PDF izvodom, ponovio bih, jer bez tih grešaka ne bih znao šta da ugradim.
Ako i ti svako jutro gledaš izvod i kucaš račune, taj posao može da nestane. Probaj Tezga eKasu, ubaci prvi izvod i vidi kako uplata sama nađe svoj predračun.
