\u010cesto se javlja slu\u010daj da se ne mogu evidentirati promene u glavnoj knjizi i poreskoj evidenciji pod istim datumom. Primera ima u toku godine, ali su najkriti\u010dniji primeri na kalendarskom prelasku iz stare u novu poslovnu godinu.<\/p>\n\n\n\n
Kao primeri se mogu\nuzeti ra\u010duni za tro\u0161kove (EPS, mobilni i fiksni operateri\ntelefonije i dr.) koji se odnose na period iz teku\u0107e poslovne godine\n(kalendarski ve\u0107 stare godine), a koji su kasnije prispeli na\nknji\u017eenje u novoj kalendarskoj godini. Ovo je \u010desta praksa, gde\nisporuka ra\u010duna kasni zbog neradnih dana oko Nove godine i Bo\u017ei\u0107nih\npraznika. Situacija se dodatno komplikuje ako ra\u010duni prispevaju\nnakon obra\u010duna PDV, gde je izvr\u0161eno podno\u0161enje POPDV prijave i\nizvr\u0161eno pla\u0107anje u skladu s njom. Odbitni PDV, po ovom osnovu\nmo\u017eemo odlo\u017eiti za naredni poreski period, bez kr\u0161enja poreskih\npropisa koji \u017eelimo ovde objasniti. Praksa je da se u BusinessWise\nsoftveru izvr\u0161i zaklju\u010dak poreskog perioda, pa se nakon toga sve\npromene PDV moraju evidentirati u novom poreskom periodu, u na\u0161em\nprimeru kao promene novoj poreskoj godini u razli\u010ditom poreskom\nperiodu od finansijskog.<\/p>\n\n\n\n
U ranijim verzijama\nsoftvera ovo je bilo dosta ote\u017eano s obzirom na automatizovan na\u010din\nknji\u017eenja poreske evidencije, koja nije uzimala ovakve slu\u010dajeve u\nobzir. Sada je problem re\u0161en na manje-vi\u0161e poznat na\u010din starijim\nkorisnicima BusinessWise softvera uvo\u0111enjem, ili izjedna\u010davanjem sa\nporeskim datumom, datuma knji\u017eenja kao datuma pod kojim \u0107e se\nizvr\u0161iti knji\u017eenje poreske evidencije.<\/p>\n\n\n\n
Neko bi ispravno\npostavio pitanje: Za\u0161to nije uveden poseban datum za poresku\nevidenciju?<\/strong><\/p>\n\n\n\n Nekako se automatski\nname\u0107e odgovor da sama priroda posla vremenskog evidentiranja\npromena kasni, iz objektivnih (a mo\u017eda i iz subjektivnih!) razloga i\nda datum knji\u017eenja mora pratiti datum stvarne evidencije promene. U\ntom slu\u010daju se datum knji\u017eenja uvek poklapa sa datumom poreske\nevidencije, \u0161to elimini\u0161e potrebu za uvo\u0111enjem dodatnog datuma,\nkoji bi optere\u0107ivao unos podataka stalnom potrebom za unosom i kada\nza to nije slu\u010daj iz gornjeg primera.<\/p>\n\n\n\n Dakle sada se datum\nknji\u017eenja tretira i kao poreski datum za knji\u017eenje promena u\nporeskoj evidenciji. Naravno da datum knji\u017eenja nije time izgubio\nsmisao koji ima po MSFI i ra\u010dunovodstvenim standardima i da je uvek\nmogu\u0107e bez kr\u0161enja MSFI i standarda evidentirati PDV u poreskoj\nevidenciji. Na kraju i ako se poka\u017ee potreba za razdvajanjem datuma\nknji\u017eenja od datuma poreske evidencije, uvek je mogu\u0107e zadr\u017eati\ndatum knji\u017eenja da bude u skladu sa MSFI i standardima, uz takozvano\nru\u010dno knji\u017eenje poreske evidencije sa proizvoljim datumom poreske\nevidencije.<\/p>\n\n\n\n Sve opisane promene\nsu realizovane u verziji BusinessWise 10.0.25<\/strong>,\nu decembru mesecu\n2020. godine i odnose se na sve programske pakete iz opusa\nBusinessWise<\/strong>. Tako\u0111e se u ovoj verziji javlja novi \u0161ablon za\nknji\u017eenje ulaznog i izlaznog delovonika za knji\u017ena odobrenja\nprilikom knji\u017eenja finansijskog naloga glavne knjige. Uskoro se\nplanira dodavanje \u0161ablona za knji\u017eenje i finansiskih zadu\u017eenja.<\/p>\n","protected":false},"excerpt":{"rendered":" \u010cesto se javlja slu\u010daj da se ne mogu evidentirati promene u glavnoj knjizi i poreskoj evidenciji pod istim datumom. Primera ima u toku godine, ali su najkriti\u010dniji primeri na kalendarskom prelasku iz stare u novu poslovnu godinu. Kao primeri se mogu uzeti ra\u010duni za tro\u0161kove (EPS, mobilni i fiksni operateri telefonije i dr.) koji se … \u041d\u0430\u0441\u0442\u0430\u0432\u0438 \u0441\u0430 \u0447\u0438\u0442\u0430\u045a\u0435\u043c Vremenska razgrani\u010denja u finansijama i poreskoj evidenciji<\/span><\/a><\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-1029","post","type-post","status-publish","format-standard","hentry","category-vesti"],"_links":{"self":[{"href":"https:\/\/www.micro.co.rs\/blog\/wp-json\/wp\/v2\/posts\/1029","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.micro.co.rs\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.micro.co.rs\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.micro.co.rs\/blog\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/www.micro.co.rs\/blog\/wp-json\/wp\/v2\/comments?post=1029"}],"version-history":[{"count":1,"href":"https:\/\/www.micro.co.rs\/blog\/wp-json\/wp\/v2\/posts\/1029\/revisions"}],"predecessor-version":[{"id":1030,"href":"https:\/\/www.micro.co.rs\/blog\/wp-json\/wp\/v2\/posts\/1029\/revisions\/1030"}],"wp:attachment":[{"href":"https:\/\/www.micro.co.rs\/blog\/wp-json\/wp\/v2\/media?parent=1029"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.micro.co.rs\/blog\/wp-json\/wp\/v2\/categories?post=1029"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.micro.co.rs\/blog\/wp-json\/wp\/v2\/tags?post=1029"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}