Srpski payroll i lokalni dokumenti: rupa svih stranih ERP sistema

Kada srpska firma bira ERP, obračun zarada retko stoji među prve tri stavke na listi zahteva. Obično je oko petnaestog mesta, ispod integracije sa bankom i iznad mobilnog pristupa. Ugovor se potpiše, projekat krene, i onda — najčešće na radionici o migraciji, u petom mesecu — neko pita kako će se obračunati mart. Odgovor je gotovo uvek isti: zarade ostaju tamo gde su.

Rupa nije funkcija koja fali — rupa je granica

Odoo, Business Central i SAP Business One su ozbiljni sistemi: širina, dimenzije u knjiženju, API, partnerska mreža. Ono što nemaju je srpski obračun zarada, i to nije previd. Payroll je najskuplja moguća lokalizacija — menja se svake godine, greška je vidljiva na svakom listiću, a tržište ima nekoliko hiljada kupaca. Nijedan globalni proizvođač taj račun ne zatvara sam. Rešava se na jedan od tri načina:

• Partnerski lokalizacioni paket — dodatak koji održava treće lice, sa svojim ciklusom izdanja.
• Odvojen domaći program — obračun se radi tamo, a u ERP se vraća jedan zbirni nalog mesečno.
• Knjigovodstvena agencija — obračun je usluga, a ERP dobija PDF ili tabelu.

Tri rešenja, jedno isto svojstvo: granica preko koje podatak prelazi rukom ili fajlom. Ne boli dok sve ide po planu. Boli kada treba objasniti zašto se trošak rada u glavnoj knjizi razlikuje od zbira listića, kada revizija traži rekapitulaciju po organizacionoj jedinici, i kada se mart obračunava ponovo u novembru.

Šta srpski obračun zaista traži

„Payroll“ u globalnom proizvodu znači: uzmi bruto, primeni stope, izbaci neto. Srpski obračun je drugi objekat — motor pravila koji ima istoriju. Šta u njemu mora da postoji:

• Porez na zaradu 10%, sa neoporezivim iznosom koji se menja i ima datum od kog važi.
• Doprinosi 19,90% na teret zaposlenog i 15,15% na teret poslodavca, sa najnižom i najvišom osnovicom koje seku obračun na oba kraja.
• Minuli rad: zakonski minimum 0,4% osnovne zarade po punoj godini rada u radnom odnosu.
• Naknade za odmor, praznik i plaćeno odsustvo — svaka sa svojom osnovicom, po pravilu prosekom prethodnih dvanaest meseci.
• Bolovanje 65% za bolest izvan rada i 100% za povredu na radu, sa granicom od trideset dana posle koje teret prelazi na RFZO.
• Topli obrok i regres unutar zarade, uz primanja van nje sa sopstvenim neoporezivim iznosima i datumima važenja.
• Olakšice za zapošljavanje, sa trajanjem i uslovima koji mogu da otpadnu usred godine.
• Ugovori van radnog odnosa — o delu, dopunski rad, autorski, zakup — svaki sa drugom oznakom vrste prihoda.

Minuli rad je dobar test. U stranom sistemu se modeluje kao dodatno polje u kalkulacionoj šemi i prvi obračun prođe uredno. Problem stiže kasnije: staž nije broj nego istorija, menja se sredinom meseca, a osnovica na koju se procenat primenjuje nije uvek iznos koji sistem zove „basic pay“. Polje koje je juče bilo tačno danas nije — a niko ne zna kada je prestalo, jer polje nema datum.

PPP-PD nije izveštaj nego posledica obračuna

Pojedinačna poreska prijava nosi po zaposlenom oznaku vrste prihoda (OVP), oznaku olakšice (OL), oznaku metoda finansiranja (MFP) i, kroz BOP, vezu ka konkretnoj uplati. To nije spisak zarada nego izvod iz obračuna po svakoj vrsti prihoda — i po njemu se plaća. Kada nastaje prepisom iz drugog programa, otvara se najskuplji raskorak: fajl je predat, novac uplaćen po BOP-u, a glavna knjiga zna nešto treće.

Lokalni dokumenti koje niko ne broji dok se ugovor ne potpiše

Payroll je najvidljiviji deo rupe, ali nije jedini. Uz njega ide grupa dokumenata koje globalni proizvod nema jer nemaju svetski ekvivalent — nastali su iz srpskih propisa. Svaki je pojedinačno mali. Zbir nije.

Nijedan od ovih dokumenata nije intelektualno težak. Svaki je tačka u kojoj sistem ili zna šta se desilo ili ne zna. Kada ih šest stoji izvan sistema, „jedna poslovna istina“ postaje šest tabela koje neko usaglašava — posao koji se nikad ne pojavi u projektnom planu, a pojede ozbiljan deo vremena finansija.

Zašto lokalizacija kao dodatak ne rešava problem

Odgovor na sve gore obično glasi: postoji lokalizacioni paket. I postoji — često pošteno napisan, od ljudi koji propise znaju bolje od proizvođača jezgra. Problem nije kvalitet paketa, nego gde paket stoji.

1. 1

   Paket kasni za zakonom, rok ne kasni

   Izmena se objavi u decembru, primenjuje se od januara. Paket mora da izađe, prođe test kod partnera i stigne do vaše instance; rok za PPP-PD se ne pomera. Procep se pokrije rukom, a mesec urađen rukom ostavlja rezultat bez traga kako je nastao.

2. 2

   Dva ciklusa nadogradnje koja se ne poklapaju

   Jezgro ima svoj kalendar izdanja, paket svoj. Nadogradnja jezgra ume da pomeri nešto na šta se paket oslanjao; nadogradnja paketa ume da traži verziju jezgra koju ne smete da uzmete. Instanca se zamrzne na verziji od pre dve godine i to postane politika.

3. 3

   Paket živi iznad modela koji ga nije predvideo

   Ako jezgro pamti samo tekuću vrednost poreske stope, paket ne može da uvede istoriju stopa — može da je simulira u svojoj tabeli. Ako knjiženje nema dimenzije na stavci, paket može samo izveštaj koji se ne slaže sa glavnom knjigom. Dodatak nasleđuje svaku pretpostavku jezgra, a nijednu ne sme da promeni.

4. 4

   Odgovornost podeljena na troje je odgovornost ničija

   Kada obračun ispadne pogrešan, proizvođač jezgra kaže da je payroll partnerski, partner da je izmena u jezgru, implementator da je konfiguracija. Sve tri tvrdnje mogu biti tačne istovremeno. To ne pomaže onome ko potpisuje prijavu.

Dve odluke koje se ne dodaju kasnije

Prva: svaki zakonski parametar pamti period važenja. Preobračun za mart urađen u novembru mora da koristi neoporezivi iznos, stope i osnovice koje su važile u martu, ne današnje. To nije redak slučaj nego redovan — aneks sa retroaktivnim dejstvom, naknadno priznato bolovanje, presuda, ispravka staža. Sistem koji čuva samo tekuću vrednost daje uverljiv, uredan i pogrešan rezultat. Gore od toga: daje ga tiho.

Druga: knjiži se sa dimenzijama na stavci. Trošak rada je najveći trošak većine firmi i jedini koji po pravilu stiže u knjige kao jedan zbir, bez organizacione jedinice, projekta i troškovnog mesta. Onda ga neko svakog meseca raspoređuje po ključu u tabeli. To nije controlling nego rekonstrukcija. Dimenzija koje nije bilo na stavci u trenutku knjiženja ne može se posle dodati pošteno — može se samo pretpostaviti.

Kako NG One to rešava

U NG One-u su srpski obračun zarada i lokalni dokumenti prvorazredni sadržaj sistema, a ne sloj iznad njega. Konkretno:

1. Obračun zarada je u jezgru, na istoj platformi kao glavna knjiga, sa istim workflow mehanizmom, autorizacijom i nepromenljivim dnevnikom. Bez izvoza i bez zbirnog naloga koji neko prekucava.
2. Zakonski parametri pamte period važenja, a knjiženje nosi dimenzije na stavci — obe odluke stoje u temelju, donete pre prvog reda payroll koda. Preobračun za mart koristi martovske stope zato što ih sistem i dalje zna, a ne zato što ih je neko zapisao sa strane.
3. PPP-PD XML, nalozi za isplatu i nalog za knjiženje nastaju iz istog zaključanog obračuna. Ne jedno iz drugog, nego sva tri iz istog izvora. Zato ne mogu da se raziđu.
4. Blagajna, kompenzacija i cesija, KEP, nivelacije, putni nalozi i otkup od fizičkih lica su tipovi dokumenata u jezgru — svaki sa svojom statusnom mašinom, autorizacijom i knjiženjem koje pogađa iste zalihe i isti saldakonto kao i sve ostalo. Nijedan nije tabela pored sistema.
5. Kanali ka ePorezima, eBolovanju i CROSO-u idu tačno dokle portali dozvoljavaju: sistem pripremi, validira i potpiše XML i vodi evidenciju predaja i statusa, a poslednji korak na portalu ostaje čoveku. Poluautomatski je ovde tačan opis granice, ne izgovor.

Pet pitanja za dobavljača

1. Ko piše i ko održava srpski obračun zarada — vi, partner, ili se izmešta u drugi program? Tražite ime pravnog lica koje za to potpisuje odgovornost.
2. Kada se neoporezivi iznos izmeni u decembru sa primenom od januara, koliko dana kasnije to stigne do naše instance, ko testira i ko plaća?
3. Uradite preobračun jednog prošlogodišnjeg meseca pred nama, sa parametrima koji su tada važili. Ne opišite — uradite.
4. Pokažite nalog za knjiženje zarada sa organizacionom jedinicom, projektom i troškovnim mestom na stavci, bez naknadne raspodele u izveštaju.
5. Gde žive blagajna, putni nalog, KEP i kompenzacija? Ako je odgovor „rešava se u implementaciji“, pitajte koliko traje i ko to održava na sledećoj nadogradnji.

Nijedno pitanje nije trik i nijedno ne traži obećanje — sva traže demonstraciju. Payroll je oblast u kojoj se razlika između „podržavamo“ i „radi“ vidi tek u petom mesecu projekta, kada je već skupa. Sistem se ne bira po broju modula na slajdu nego po tome koliko granica ostaje između mesta gde se posao desio i mesta gde se o njemu odlučuje. Kod payroll-a taj broj bi trebalo da bude nula.