Automatizacija elektronskih računa ne počinje dugmetom „pošalji“, već praktičnim pitanjem: odakle dolaze podaci i šta treba da se dogodi nakon izdavanja dokumenta? Ako je porudžbina već kreirana u prodajnom sistemu, obim usluge zapisan u ugovoru, a podaci o kupcu postoje u računovodstvenom programu, ponovni ručni unos postaje suvišna karika. On opterećuje računovodstvo i stvara neslaganja između porudžbine, računa, uplate i stvarnog izvršenja.
Za kompanije u Srbiji važan deo ovog procesa predstavlja Sistem elektronskih faktura, SEF. To je državni sistem Republike Srbije, a ne proizvod kompanije VMTech niti dokaz bilo kakvog institucionalnog partnerstva. Cilj automatizacije je drugačiji: organizovati kontrolisan put podataka od porudžbine ili obračuna do elektronskog računa, njegovog statusa, računovodstvene evidencije i naredne radnje unutar kompanije.
Dobro projektovan proces ne uklanja čoveka iz svih operacija. Standardni dokumenti mogu se obrađivati po unapred usaglašenim pravilima, dok odstupanja, ispravke, delimične uplate i sporne situacije zahtevaju odgovorno lice. Zato cilj projekta nije „potpuna autonomija“, već predvidiv tok u kome redovne operacije prolaze bez ponovnog unosa, a izuzeci na vreme stižu do odgovarajućeg stručnjaka.
U srpskom poslovnom kontekstu ovakav zadatak se često naziva eFaktura integracija. Taj izraz može značiti povezivanje SEF-a sa CRM-om, ERP-om, računovodstvenim programom, bazom porudžbina ili sopstvenom aplikacijom kompanije. Sastav rešenja ne određuje se prema nazivu zadatka, već prema stvarnoj putanji dokumenta: gde operacija nastaje, ko proverava podatke, gde se beleži rezultat i koja naredna radnja sme da se izvrši.
Šta znači eFaktura integracija sa SEF-om
eFaktura integracija je kontrolisana razmena između SEF-a i internih sistema kompanije. Za SEF je predviđeno povezivanje preko programskog interfejsa; pre razvoja potrebno je proveriti aktuelni postupak pristupa, generisanja i čuvanja ključa, kao i važeću tehničku dokumentaciju. Samo postojanje API-ja ne potvrđuje kompatibilnost sa konkretnim računovodstvenim programom: njegova verzija, podešavanja i dostupni načini razmene procenjuju se posebno.
Granica projekta može biti različita. U jednom slučaju sistem samo priprema i šalje podatke za dokument. U drugom takođe beleži tehnički rezultat obrade, povezuje ga sa porudžbinom i kreira zadatak za odgovorno lice. Spisak dostupnih statusa i radnji ne treba pretpostavljati unapred: proverava se prema aktuelnoj dokumentaciji SEF-a i usklađuje sa poslovnim pravilima kompanije pre projektovanja scenarija.
Ne treba automatizovati samo jedno dugme, već kontrolisanu putanju: izvor podataka, proveru obaveznih polja, formiranje dokumenta, evidentiranje rezultata, zasebnu potvrdu uplate i dozvoljenu narednu radnju.
Zašto ručno fakturisanje ne pogađa samo računovodstvo
Na prvi pogled izdavanje računa deluje kao lokalni računovodstveni zadatak. U praksi podaci za njega nastaju ranije: pri kreiranju porudžbine, usaglašavanju komercijalne ponude, potpisivanju ugovora, obračunu obima usluge ili pripremi robe za isporuku. Ako se ti podaci prenose ručno, računovođa ponovo unosi podatke o kupcu, stavke, količine, vrednosti, poreze, datume i interne brojeve.
Problem nije ograničen na utrošeno vreme. Jedna porudžbina može imati broj u prodajnom sistemu, drugi identifikator u računovodstvenom programu i posebnu oznaku na bankovnom izvodu. Zaposleni tada mora da utvrdi da li se svi zapisi odnose na istu operaciju. Kod sličnih iznosa, ponovljenih porudžbina ili više računa za istog kupca, verovatnoća pogrešnog povezivanja postaje veća.
Nakon slanja dokumenta počinje drugi ciklus ručnog rada. Neko proverava njegov status, javlja rezultat menadžeru, usaglašava podatke sa računovodstvom i prenosi informaciju operativnom timu. Ako potvrda stvarne uplate stiže odvojeno, ona se ponovo mora povezati sa računom i porudžbinom. Dok se ovaj lanac oslanja na poruke, tabele i pamćenje zaposlenih, ne postoji jedinstvena slika operacije.
Zato integracija ne treba da odgovori samo na pitanje „kako poslati račun“, već i na pitanja „odakle su došle vrednosti“, „ko ispravlja grešku“ i „šta se smatra završetkom operacije“. Tako se uklanja ponavljajući ručni prenos uz zadržavanje računovodstvene i operativne kontrole.
Put od porudžbine do elektronskog računa
Početna tačka može biti porudžbina robe, pretplata, dokument koji potvrđuje izvršenje faze, mesečni obračun, ugovor o usluzi ili prodaja koju je potvrdio menadžer. Pre formiranja dokumenta sistem mora da odredi kupca, osnov, sastav stavki, iznos, valutu, poreske parametre, datum i interno odgovorno lice. Ova pravila ne treba nagađati tokom razvoja: usaglašavaju ih poslovna strana, računovodstvo i tehnički tim.
Zatim se proverava potpunost podataka. Ako nedostaje obavezan podatak, identifikator kupca se ne podudara ili nije određeno pravilo za određenu vrstu operacije, dokument ne sme neprimetno nastaviti put. Prebacuje se u red izuzetaka sa jasnim razlogom i jasno određenim odgovornim licem. To je sigurnije nego automatski izdati formalno popunjen, ali netačan račun.
Nakon provere pripremljeni podaci šalju se predviđenim načinom. Tehnički rezultat operacije treba evidentirati pored internog broja porudžbine i identifikatora dokumenta. Koji su odgovori, statusi i radnje dostupni u SEF-u, tim utvrđuje prema važećoj dokumentaciji prilikom projektovanja, a ne prema zastareloj listi.
Konkretne obaveze kompanije, vrste dokumenata, poreske kategorije i pravila izdavanja zavise od operacije i primenljivih zahteva. Njih potvrđuje kvalifikovani računovođa ili pravni savetnik. Tehnički tim sprovodi usaglašenu logiku, ali ne zamenjuje stručno tumačenje računovodstvenih pravila.
Koje podatke treba povezati
Minimalni skup polja određuje vrsta operacije. Mapa podataka obično obuhvata interni broj porudžbine, identifikator kupca, stavke, iznose, valutu, datume i odgovorno lice. Poreska i računovodstvena polja odobrava stručnjak naručioca; programer ne treba samostalno da bira njihove vrednosti.
Za svako polje beleže se izvor, format, obaveznost i ponašanje pri grešci. Takva tabela preslikavanja pokazuje gde postoje neslaganja: kupac može biti upisan pod više naziva, valuta se možda ne prenosi izričito ili broj porudžbine nedostaje u računovodstvenom okruženju. Korisno je rešiti te probleme pre povezivanja razmene.
SEF API integracija ili razmena datoteka
Način prenosa podataka u računovodstveni program zavisi od njegovih stvarnih mogućnosti i podešavanja. Ne može se unapred tvrditi da svaki proizvod koji kompanija koristi podržava direktnu vezu ili će automatski proknjižiti primljeni dokument. To se proverava zasebno: prema dokumentaciji, dostupnim funkcijama, verziji programa i pravilima rada računovodstva.
Kada odgovaraju kontrolisani uvoz i izvoz
Razmena datoteka može biti razumno rešenje kada ima malo dokumenata, operacije se obavljaju paketno, a računovodstveni program ne pruža pouzdano direktno povezivanje. Važno je da to ne bude slučajno prebacivanje datoteka između fascikli, već utvrđena procedura. Ona treba da obuhvati proveru formata, evidenciju izvoza, zaštitu od ponovnog učitavanja, izveštaj o greškama i usaglašavanje rezultata.
Takav pristup zadržava kontrolu i omogućava uklanjanje ponovnog unosa bez složenog preuređivanja svih sistema. Posebno je prikladan u prvoj fazi, kada kompanija želi da proveri pravila procesa i kvalitet izvornih informacija. Nedostatak je jasan: razmena se obavlja određenom učestalošću, a deo posla ostaje na zaposlenom.
Kada razmatrati direktno povezivanje
Direktno povezivanje ima smisla proceniti kod redovnog toka dokumenata, potrebe da se usaglase podaci iz više sistema ili da se tehnički rezultat obrade vrati u CRM ili ERP. Mogućnost i obim takve razmene potvrđuju se tek nakon provere konkretnog softverskog okruženja i aktuelnih zahteva za pristup.
Ipak, direktna veza sama po sebi ne ispravlja loš proces. Ako nema jedinstvenog pravila numeracije, odgovornog za ispravke i postupka za obradu duplikata, automatizacija će samo brže proširiti grešku. Zato VMTech najpre proverava konkretne sisteme i logiku rada, a zatim određuje odgovarajući način razmene. Ova vrsta zadataka detaljnije je opisana na stranici o integraciji CRM-a, ERP-a i računovodstvenog sistema.
Za inženjersku procenu potrebne su verzije programa, dostupni načini povezivanja, anonimizovani primeri polja, ograničenja pristupa i očekivana učestalost operacija. VMTech može povezivati sisteme preko API-ja, webhook-ova, FTP-a i baza podataka, ali se primenljivost određenog rešenja utvrđuje nakon provere infrastrukture naručioca.
Status računa i stvarna uplata su različiti događaji
Status elektronskog dokumenta ne sme se automatski smatrati potvrdom prijema novca. On se odnosi na obradu samog dokumenta u odgovarajućem okruženju, dok se činjenica uplate odnosi na kretanje sredstava. Tačan skup tehničkih statusa i dostupnih operacija proverava se prema aktuelnoj dokumentaciji SEF-a pre realizacije.
Ovi događaji mogu nastupiti različitim redosledom i sa različitim kašnjenjem. Kupac može obraditi račun, ali ga platiti kasnije. Uplata može stići delimično, kao jedan iznos za više dokumenata ili sa svrhom plaćanja koja ne omogućava pouzdano automatsko povezivanje.
Zato su u modelu procesa potrebna posebna polja i posebna pravila za status računa i status plaćanja. Interfejs ih može prikazati jedno pored drugog, ali ih ne sme mešati. Naredna poslovna radnja pokreće se samo događajem koji je kompaniji zaista potreban: na primer, potvrđenim prijemom punog iznosa, ručnim odobrenjem finansijskog zaposlenog ili ispunjenjem više uslova istovremeno.
Kako povezati porudžbinu, račun, kupca i uplatu
Pouzdana automatizacija zasniva se na stabilnim identifikatorima. Porudžbina, kupac, račun i uplata mogu imati različite brojeve, ali sistem mora da čuva jasne veze između njih. Povezivanje samo po iznosu nije dovoljno: isti iznosi se redovno javljaju, a delimična ili objedinjena uplata ruši takvu logiku.
Za svaku operaciju korisno je definisati glavni interni identifikator i skup dodatnih obeležja. Ona mogu uključiti broj porudžbine, broj dokumenta, podatke o kupcu, iznos, valutu, datum i svrhu plaćanja. Što je veći rizik od pogrešne aktivacije, više nezavisnih uslova treba da se podudari pre automatskog nastavka.
Posebno pravilo potrebno je za ponovnu obradu. Ako ista poruka, datoteka ili dokument stigne drugi put, sistem treba da prepozna duplikat i ne kreira novi račun, ponovljeno knjiženje ili drugu aktivaciju. Zato se čuvaju identifikator operacije, njen rezultat i oznaka završene radnje.
Povezanost podataka pomaže da se vidi put porudžbine od početne operacije do dokumenta i naredne radnje. Opšti principi uklanjanja ponovnog prenosa detaljnije su obrađeni u tekstu o povezivanju CRM-a, ERP-a, porudžbina i računovodstva.
Šta raditi nakon potvrđene uplate
Potvrđena uplata nije vredna samo kao oznaka u tabeli, već kao osnova za sledeći kontrolisani korak. Za uslugu to može biti aktivacija pristupa, otvaranje plaćenog perioda, dodela izvršioca ili obaveštavanje tima. Za robu to može biti odobrenje za komisioniranje, priprema dokumenata, predaja porudžbine za isporuku ili informisanje odgovornog zaposlenog.
Izbor radnje zavisi od rizika. Menadžera je moguće automatski obavestiti uz dovoljno širok skup uslova. Aktiviranje skupe usluge, slanje robe ili davanje pristupa osetljivim podacima treba izvršiti tek nakon stroge provere iznosa, valute, kupca, svrhe plaćanja i veze sa konkretnim računom. Za neke operacije opravdano je zadržati ručnu potvrdu čak i kada je povezivanje ispravno.
Izvor potvrde uplate određuje arhitektura konkretnog rešenja. Ne može se automatski pripisati SEF-u niti smatrati istim za sve kompanije. Ako nakon provere treba pokrenuti komisioniranje ili prenos porudžbine, projekat automatizacije obrade porudžbina pokazuje vezu sa operativnim tokom.
Izuzeci, bezbednost i kontrola
Glavni tok obično izgleda jednostavno, ali kvalitet rešenja određuje ponašanje u nestandardnim situacijama. Pre pokretanja je potrebno pisano obraditi najmanje sledeće slučajeve:
- Greška ili odbijanje. Ko prima zadatak, gde se beleži razlog i kako se operacija vraća u glavni tok?
- Ispravka. Koje naredne radnje treba zaustaviti i ko potvrđuje izmenu?
- Delimična ili objedinjena uplata. Da li izvršenje može da se nastavi ili odluka ide računovodstvu?
- Duplikat. Kako se sprečava ponovljeno kreiranje dokumenta ili ponovno pokretanje usluge?
- Nepotpuni podaci. Ko dopunjuje podatke i proverava ispravku?
- Nedostupnost sistema. Gde se čuva operacija i kada je potrebna intervencija?
- Ručna izmena. Ko ima pravo da je izvrši i kako se radnja beleži u dnevniku?
Svaki izuzetak mora imati odgovorno lice, prihvatljiv rok reakcije i jasno definisano krajnje stanje. Zapis „greška razmene“ nije dovoljan: zaposlenom su potrebni broj porudžbine, vrsta dokumenta, razlog zaustavljanja i bezbedna radnja koju može da izvrši.
Finansijski proces obuhvata podatke kompanija, iznose, dokumente i ovlašćenja zaposlenih. Pristup treba dodeljivati po ulogama: menadžeru nije nužno potrebno ovlašćenje za računovodstvene ispravke, a tehnički stručnjak ne treba da donosi finansijsku odluku. Izmena kritičnog pravila ili ručno pokretanje rizične radnje može zahtevati dodatnu potvrdu.
Dnevnik treba da čuva korišćene podatke, vreme operacije, izmene, razlog zaustavljanja i osnov za nastavak. Ako jedan od sistema nije dostupan, operacija ne sme nestati niti se pogrešno smatrati završenom: unapred se određuju ponovni pokušaj, obaveštenje ili predaja odgovornom zaposlenom.
Ovaj materijal objašnjava organizaciju digitalnog procesa i nije računovodstveni, poreski ni pravni savet. Primenljive obaveze, kategorije dokumenata i pravila evidentiranja potrebno je proveriti za konkretnu kompaniju i operaciju.
Faze uvođenja eFaktura integracije
Automatsko fakturisanje je pouzdanije uvoditi postepeno. Pokušaj da se odjednom obuhvate sve vrste prodaje, dokumenti, ogranci i izuzeci otežava proveru i nalaženje uzroka grešaka.
- Mapa procesa. Zabeležiti izvore podataka, ručne radnje, sisteme, uloge i tačke odlučivanja.
- Provera povezivanja. Utvrditi verzije programa, dostupne interfejse, postupak pristupa SEF-u i infrastrukturna ograničenja.
- Tabela polja. Usaglasiti obavezne vrednosti, formate, identifikatore i odgovorna lica za računovodstvena pravila.
- Opis izuzetaka. Odrediti ponašanje kod duplikata, nepotpunih podataka, nejasne uplate i nedostupnosti sistema.
- Pilot jednog toka. Izabrati jednu jasnu vrstu operacije i usaglašavati rezultat sa postojećim postupkom.
- Prihvatanje. Proveriti ovlašćenja, dnevnik, ponovne pokušaje, obaveštenja i ručnu potvrdu rizičnih radnji.
- Proširenje. Dodavati nove vrste dokumenata i naredne procese tek nakon provere prethodne faze.
Rok i cenu ovakvog projekta nije moguće pravilno navesti bez procene sistema, obima dokumenata i pravila kompanije. Čak i isti računovodstveni programi mogu biti različito podešeni, a ista vrsta računa može pokretati različite radnje u dve organizacije.
Šta pripremiti za inženjersku procenu
Pre razgovora o realizaciji pripremite kratak opis postojećeg procesa. Navedite gde nastaje porudžbina, ko potvrđuje sastav i vrednost, u kom programu radi računovodstvo, koje vrste elektronskih računa se koriste i kako zaposleni sada saznaju za promenu statusa dokumenta.
Posebno opišite plaćanje: odakle dolazi potvrda, da li su moguće delimične i objedinjene uplate, koji se podaci koriste za povezivanje i koja radnja treba da usledi. Korisno je priložiti anonimizovane primere polja i navesti izuzetke sa kojima se tim susreće u stvarnom radu.
Za radno okruženje u Srbiji potrebno je takođe odrediti jezik polja i obaveštenja, valutu operacija, sastav imenika kupaca i odgovorno lice za proveru računovodstvenih pravila. Ovi parametri se ne smeju pretpostaviti unapred: naručilac ih utvrđuje sa svojim računovođom, nakon čega tehnički tim procenjuje putanju podataka i kontrolne tačke.
Tek tada se može odrediti da li je dovoljna kontrolisana razmena datoteka, da li je moguće direktno povezivanje i koje su provere potrebne pre pokretanja naredne radnje. Rezultat procene treba da bude jasna šema sistema, polja, odgovornih lica i izuzetaka, a ne obećanje univerzalne kompatibilnosti.
