Vremenski važeći zakonski parametri: kad se stopa promeni, prošlost ne sme

Od uvođenja PDV-a 2005. godine u Srbiji su se stope promenile dva puta: opšta je 1. oktobra 2012. otišla sa 18 na 20 odsto, posebna je 1. januara 2014. otišla sa 8 na 10. Dve promene u dvadeset godina. Ta retkost je tačan razlog zašto se stopa u velikom broju sistema i dalje nalazi kao konstanta u kodu ili kao jedan red u šifarniku koji se prepiše kad zatreba — i zašto se problem otkriva tek onog dana kad promena stvarno stigne, kada je za izmenu modela kasno.

Tri načina da stopa živi u sistemu

• Konstanta u kodu — stopa je napisana u formuli za obračun. Promena stope je izmena softvera i nova verzija u produkciji.
• Jedan red u šifarniku — parametar je podatak, ali ima tačno jednu vrednost: onu trenutnu. Promena stope je UPDATE nad tom vrednošću.
• Verzionisan parametar — svaka vrednost ima opseg važenja i izvor. Promena stope je nov zapis; stari ostaje netaknut.

Konstanta u kodu

Kad je stopa konstanta, zakonska promena postaje inženjerski zadatak sa rokom koji određuje Službeni glasnik. To je nezgodno, ali podnošljivo jednom u deceniju. Nepodnošljiva je posledica: verzija koda koja je znala staru stopu nestaje iz produkcije istog trenutka. Sistem od 2. oktobra 2012. ne ume da izda knjižno odobrenje za septembarski promet, jer u njemu 18 odsto više ne postoji ni kao pojam. Ono što se tada uradi gotovo uvek izgleda isto: grananje po datumu, zakopano u jednoj metodi, koje niko ne dokumentuje i koje se ne pojavljuje ni u jednom šifarniku ni izveštaju. To jeste verzionisanje parametra — samo napisano na najgorem mogućem mestu.

Jedan red koji se prepisuje

Drugi pristup deluje kao rešenje: stopa je podatak, menja je knjigovođa iz šifarnika, programer nije potreban. Cena se plaća u jednoj rečenici koju niko ne vidi. UPDATE nad vrednošću parametra traje nekoliko milisekundi i nema inverz — stara vrednost ne odlazi u istoriju, ona prestaje da postoji. Od tog trenutka svaki izveštaj koji stopu čita iz šifarnika, a ne sa knjižene stavke, za sve prošle periode vraća nove brojeve.

Knjiženje ne pita koja je stopa danas

Ovde se model najčešće lomi. Stopa se ne razrešava „sada“, nego na određujući datum, i taj datum nije isti za sve parametre. Dokument u ozbiljnom ERP-u zato nosi više datuma — dokumenta, prometa, knjiženja, valute i unosa — jer nijedan od njih ne može sam da posluži svim obračunima nad tim dokumentom.

Tabela nosi zaključak koji se ne vidi dok se ne ispiše: na isti dan, u istom sistemu, tri parametra se razrešavaju na tri različita datuma. „Trenutna vrednost“ zato nije pojednostavljenje modela, nego pojam koji u ovom domenu nema definiciju. Srednji kurs NBS je koristan test: niko ga ne hardkoduje i niko ne čuva samo poslednji, jer se menja svakog radnog dana pa je istorija očigledna. Model mu je ipak identičan modelu stope PDV-a — vrednost sa opsegom važenja, razrešena na određujući datum. Razlikuje se samo učestalost.

Backdated dokument nije izuzetak, nego pravilo

Da svaki dokument nastaje na dan svog prometa, ovo bi bila akademska rasprava. U stvarnom radu je dokument sa datumom u prošlosti svakodnevna pojava:

• Knjižno odobrenje za promet iz prethodne godine — osnovica se umanjuje po stopi sa dana prvobitnog prometa, ne po današnjoj.
• Storno fakture izdate pre promene stope, urađen posle nje.
• Faktura dobavljača koja stigne dva meseca posle prometa, sa svojim datumom prometa i svojim pravom na odbitak prethodnog poreza.
• JCI koja se zaključi posle prijema robe: landed cost ulazi u nabavnu vrednost unazad i tera preobračun zaliha, a deo LOT-ova je u međuvremenu već izdat po FEFO redosledu.
• Manjak utvrđen popisom, koji se evidentira internim obračunom PDV-a.
• Izmenjena PPP-PD prijava za mesec unazad, posle ispravke jedne stavke obračuna.

Prvi slučaj vredi ispisati do kraja. Faktura iz septembra 2012, osnovica 100.000 dinara, PDV 18.000. Kupac reklamira u novembru; izdaje se knjižno odobrenje na celu vrednost. Sistem koji stopu razrešava „sada“ upisuje 20.000 dinara PDV-a. Obveznik je obračunao 18.000, a umanjuje 20.000 — 2.000 dinara razlike koja u POPDV-u nema gde da se smesti. Na jednom dokumentu to je greška koju knjigovođa ručno ispravi. Na četiri hiljade dokumenata iz spornog kvartala to je pozicija koja se ne može ni objasniti ni rekonstruisati u razumnom roku.

Doprinosi: isti mehanizam, teža posledica

Kod PDV-a se parametar menja retko. Kod zarada se menja gotovo svake godine, i to na više mesta odjednom: najniža i najviša mesečna osnovica doprinosa, neoporezivi iznos zarade, povremeno i same stope. PPP-PD se pri tom podnosi pojedinačno po primaocu, sa šifrom vrste prihoda koja tek određuje koji se skup parametara primenjuje. Broj kombinacija u kojima „poslednja vrednost“ može da promaši je red veličine veći nego kod PDV-a.

Izmenjena prijava za mart, podneta u julu, redovna je radnja. Ispravan sistem ponavlja martovski obračun po martovskim parametrima i menja tačno ono što je pogrešno bilo. Sistem koji zna samo julske vrednosti proizvodi prijavu koja se od originalne razlikuje u svakom redu, iako se suštinski ispravlja jedna stavka. Poreska uprava ne vidi ispravku — vidi drugačiji obračun. Objašnjenje te razlike postaje posao koji traje danima, nema pisani trag i ponavlja se pri svakoj sledećoj izmeni, jer sistem i dalje smatra da je u pravu.

Dve vremenske ose

Postoji i drugi red problema, koji se otkriva tek u radu: parametar ima dva vremena — kada važi i kada smo saznali da važi. Izmena objavljena u decembru sa primenom od 1. januara ta dva vremena drži poklopljenim i sve radi. Ispravka objavljena u martu, sa primenom unazad od 1. januara, razdvaja ih, i sistem mora da odgovori na dva pitanja: šta je primenjeno na januarski dokument (istina koja stoji u podnetoj prijavi) i šta je trebalo primeniti (osnov za izmenjenu prijavu). Razlika između ta dva odgovora je tačno ono što se prijavljuje. Model sa jednom vremenskom osom ne ume ni da postavi pitanje. Zato ispravka pogrešno unetog parametra nikada nije UPDATE, nego nova verzija zapisa nad istim opsegom važenja — sa svojim trenutkom unosa i listom dokumenata knjiženih po staroj.

Model koji radi

1. 1

   Parametar je interval, ne vrednost

   Svaka verzija nosi šifru, vrednost, opseg važenja i izvor — broj Službenog glasnika ili internu odluku. Vrednost se ne prepisuje.

2. 2

   Rezolucija ide preko određujućeg datuma

   Svaki tip parametra deklariše koji datum dokumenta ga razrešava. Datum knjiženja je razuman podrazumevani odgovor za tačno nijedan poreski parametar.

3. 3

   Rezultat se zamrzava na stavci

   Knjižena stavka nosi i primenjenu vrednost i referencu verzije. Vrednost — da izveštaj ne zavisi od ponovnog računanja. Referenca — da se zna ko je tu vrednost rekao.

4. 4

   Ponovni obračun je događaj, ne posledica

   Kad se parametar ispravi unazad, sistem ne prepisuje stavke tiho. Pravi listu pogođenih dokumenata, računa razliku i traži odluku: korekcija, izmenjena prijava ili obrazloženo zadržavanje stanja.

5. 5

   Svaka stavka ume da objasni sebe

   Odgovor na pitanje zašto 18 odsto glasi: datum prometa je 12. septembar 2012, ovaj parametar se razrešava na datum prometa, verzija koja je tada važila je ta, izvor je taj. Bez tog lanca revizija dobija tvrdnju umesto dokaza.

Zašto se ovo ne dodaje kasnije

Ovo je jedna od malobrojnih odluka u ERP-u koja se ne može odložiti. Šifarnik parametara je lako naknadno napuniti istorijom: Službeni glasnik je javan, intervali su poznati, posao je jednodnevni. Ono što se ne može napuniti naknadno je referenca verzije na tri stotine hiljada već knjiženih stavki. Za nju ne postoji izvor — mora se pogoditi, i to po istoj logici datuma koju sistem do tada nije imao. Tamo gde je stari sistem koristio pogrešan datum, migracija verno reprodukuje grešku i daje joj formu dokaza. To je gore od greške koja se bar vidi kao greška.

Pet pitanja za bilo koji ERP

1. Zatražite da se POPDV za period od pre tri godine ponovo generiše i uporedite ga sa podnetim. Brojevi moraju da budu identični.
2. Pitajte koji datum dokumenta razrešava stopu PDV-a i tražite da vam to pokažu u konfiguraciji, ne u objašnjenju.
3. Napravite knjižno odobrenje za promet iz perioda pre poslednje promene stope i pogledajte koja se stopa sama ponudi.
4. Otvorite jednu knjiženu stavku i tražite da vam sistem kaže koja je verzija parametra primenjena i odakle je došla.
5. Pitajte šta se dešava kad se parametar ispravi unazad: da li sistem ćuti ili pravi listu dokumenata koje ta ispravka pogađa.

Nijedno od ovih pitanja nije teško. Zato su i korisna: sistem koji na njih nema odgovor nema ga ni na jedno teže.