Nemoguća misija

Polako privodeći kraju rad na programu za obračun zarada, naleteo sam na kako mi se čini nerešiv problem – zahtevano iskazivanje zaokruženih iznosa u pojedinim obrascima.

Naime, iz ko zna kog razloga, državne birokrate su propisale da što se njih tiče iznosi ispod dinara ne postoje te iako se obračun zarade vrši sa decimalama koje izražavaju pare (koliko ja znam u Srbiji je to još uvek važeća veličina) većina obrazaca vezanih za obračun zarade moraju da se iskazuju u zaokruženim iznosima.

Tako na primer OD obrazac ima polja u kojima se iskazuju iznosi doprinosa za socijalno osiguranje na teret poslodavca i zaposlenog, što je u slučaju prijavljenim od strane knjigovođe sa kojim sarađujem tokom testiranja obračuna dovelo do sledećeg slučaja.

Precizno obračunati doprinosi na zaradu:

  • PIO na teret radnika           3600,79 din
  • ZDR na teret radnika          2013,17 din
  • NEZ na teret radnika            245,51 din.
  • PIO na teret poslodavca      3600,79 din
  • ZDR na teret poslodavca      2013,17 din
  • NEZ na teret poslodavca       245,51 din

UKUPNO: 11.718,94 din

Ako zaokružim ovaj zbir dobijam naravno 11.719 din uz vrlo malu grešku tako da je to ciljani zbir zaokruženih sabiraka.

Prosto zaokruživanje

Ako sad krenem onako da zaokružujem svaki sabirak zasebno dobijam

  • PIO na teret radnika           3601 din
  • ZDR na teret radnika          2013 din
  • NEZ na teret radnika            246 din.
  • PIO na teret poslodavca     3601 din
  • ZDR na teret poslodavca    2013 din
  • NEZ na teret poslodavca      246 din

UKUPNO: 11.720 din.

Problem: dinar previše.

Balansirano zaokruživanje.

Ja sam pre par meseci za ove potrebe razvio ceo algoritam oko “pametnog zaokruživanja” koji uzima u obzir kumulativni efekt zaokruživanja kod sekvence zaokruživanja te ako bi njega primenio na ova 6 iznosa rezultat bi bio nešto poput ovog:

  • PIO na teret radnika           3601 din
  • ZDR na teret radnika          2013 din
  • NEZ na teret radnika           245 din.
  • PIO na teret poslodavca     3601 din
  • ZDR na teret poslodavca    2013 din
  • NEZ na teret poslodavca      246 din

 

UKUPNO: 11.719 din.
Problem: Doprinosi za nezaposlenost na teret radnika i poslodavca nisu isti – razlikuju se za dinar

Evo kako sam došao do tih iznosa 3600,79+0.00 = 3600,79 =>  ~= 3601 din
3600.79 – 3601   = -0.21 balans2013.17 – 0.21= 2012.96 =>  ~=2013 din
2013.17 – 2013 = +0.17 – 0.21 = -0.04 balans 245.51-0.04 = 245.47 => ~= 245 din.
245.51 – 245 = 0.51 – 0.04 = +0.47 balans

3600,79 + 0,47 = 3601.26 => ~= 3601 din
3600.79 – 3601 = – 0.21 + 0.47 = + 0.26 balans

2013.17+0.26= 2013.43  =>  ~=2013 din
2013.17 – 2013 = 0.17 + 0.26 = +0.43 balans

245.51+0.43 = 245.94 => ~= 246 din.
245.51 -246 = -0.49 + 0.43 = -0.06 balans

Rešenje?

Moj zaključak je da je problem nemoguće rešiti kako je postavljen i da je jedin pravo rešenje ili da birokrate dobiju obrasce sa preciznim ciframa ili da kao zemlja ukinemo parice i sve svuda izražavamo u celim dinarima.

Do tad, pošto rešenja tačnog nema ja sam odlučio da idem sa najprostijim – prostim matematičkim zakruživanjem.

A vi?

1.022 thoughts on “Nemoguća misija

  1. Prvo bih napomenuo da nigde ne postoji propis po kome se iznosi na obračunu zaokružuju. Po meni obračun treba raditi na dve decimale i isto tako popunjavati naloge za plaćanje. Tačno je da PU zadužuje firmu ovim zaokruženim iznosima, ali zakon ne kaže da se PIO plaća 10.99 ili 11.01 nego tačno 11%. Jedino postoji obaveza ispisana na obrascima da se upisuju „celi brojevi, bez decimala“, što čak i ne znači zaokruženje, ali to je najmanji problem. OD i OPJ uglavnom nisu problem i proći će kontrolu bez većih problema. Najveći problem predstavlja specifikacija poreza po opštinama koja se takođe ispisuje bez decimala. E sad, zbir ovih zaokruženih vrednosti treba da se poklopi sa zaokruženom sumom na obrascu OPJ, što može da se poklopi samo slučajno. Metod koji trenutno preporučuju iz PU glasi „stavi negde taj dinar, šta ima veze“ 😉 Shodno tome, algoritam treba da krene redom i da visećih dinar-dva doda ili oduzme nekoj opštini kako bi se sve složilo.

    Ali, po mojim informacijama sprema se masivna rekonstrukcija obračuna plata kojom će sve ovo + još dosta problema biti daleko bolje rešeno.

    1. Daj Bože da to odrade pa makar bacio sve što sam radio zadnjih par meseci 🙂

      Juče sam razmišljao o tome koja je prirorad svih tih izveštaja i došao do zaključka da je to relikt prošlosti iz vremena kada kompjuteri nisu postojali.

      Naime, ako pogledamo suštinu tih obrazaca to su reporti koji sumiraju dokumente po različitim kriterijuma po tome šta koje birokratsko telo treba za svoje potrebe.
      U 2013-oj po meni za tim nema apsolutno nikakve potrebe, već bi preduzeća trebala da predaju samo jedan jedini obračunsku tabelu koji sadrži sve radnike i za svakog od njih u kolonama pojedinacne iynose obracuna ya tog radnika (npr. doprinos za PIO za tog zaposlenog itd)

      Jednom kada država dobije tu jednu jedinu tabelu (i to naravno elektronski) može da radi kakve god hoće statističke izveštaje sa njom i dobije ne samo fiksni set podataka čije računanje prevaljuje na preduzeća, već bukvalno bilo kakvu statistiku može da izvuče iz podataka čak i retroaktivno. Hadoop clasteri su danas trivijalno jeftini da se podese u oblaku, a mogu da sazvaću te podatke bez ikakvih problema.

      Ja se iskreno tome nadam: smislenoj revoluciji u skladu sa vremenom u kome živimo, a ne „karminu na svinji“ – ne vidim nijedan razlog zašto ne…

      1. Upravo je takvo rešenje. Predavaće se samo jedan obrazac i to elektronski, a on će sadržati spisak radnika sa svim podacima neophodnim za obračun. Firma će za sve dažbine plaćati samo jedan nalog, a on će se automatski dalje raspoređivati. Sam obračun neće biti menjan, a svi iznosi će se naravno iskazivati na dve decimale.

      1. Ja se ipak nadam da će rok biti nešto kraći, a evo i zašto. Prvo, postoje veoma konkretni predlozi šta i kako treba uraditi. Jedan od njih možete naći na upss.rs, a veoma sličan predlog je dala i PU. Drugo, sličan sistem već par godina radi u Crnoj Gori, pa ne vidim razloga da se i ovde ne napravi nešto slično. Na kraju, radi se o relativno prostom sistemu, pa ne postoje ozbiljni tehnički problemi. Najveći rizik je naravno u ljudskom faktoru, ali se nadam da će se i to nekako prevazići.

Оставите одговор

Ваша адреса е-поште неће бити објављена. Неопходна поља су означена *

Real-user monitoring for Accessibility, Performance, Security, SEO & Errors (SiteLint)