Jedan od važnih razloga implementacije ERP sistema je automatski obračun troškova zaliha. Ovaj aspekt od krucijalne je važnosti za svaku kompaniju koja se bavi proizvodnjom i/ili trgovinom, a posebno ukoliko organizacija ima veliki broj artikala i transakcija, a dodatno ako se javljaju i retroaktivna knjiženja. U takvom okruženju, bez kvalitetnog softverskog rešenja, može biti dosta izazovno evidentirati svaku transakciju do nivoa artikla i pratiti sva ažuriranja za naknadne promene vrednosti zaliha (usled kašnjenja dokumenata ili naknadnih zavisnih troškova).
Kvalitet ERP sistema i razlika između najboljih i najzastupljenijih svetskih ERP softvera i ostalih je u velikoj meri i u ovom obračunu. Svetski ERP sistemi omogućavaju veliki broj parametara kojima se definišu pravila obračuna, kao i automatska usklađivanja troškova za sve promene ili naknadna knjiženja čak i na obimu od nekoliko stotina hiljada artikala i milionima transakcija.
U ovom tekstu pojasnićemo osnovne parametre i pravila obračuna troškova u sistemu Microsoft Dynamics 365 Business Central, pošto korisnici često navode ovaj aspekt kao jedan od nekoliko ključnih za izbor baš ovog rešenja.
METOD OBRAČUNA TROŠKOVA
Politika obračuna troškova definiše se na nivou artikla. Business Central omogućava opciju definisanja nekoliko metoda obračuna i to posebno za svaki artikal.
Praksa pokazuje da je najbolje koristiti jedan metod obračuna troškova za sve artikle u okviru organizacije, ali u praksi nisu strane ni situacije da klijenti istovremeno koriste različite metode (posebno u proizvodnji, gde se ponekad gotovi proizvodi drugačije tretiraju).
Najčešće se u praksi koriste FIFO, Prosečni ili Standardni. Kod prosečnog troška, dodatno je važno definisati na kom nivou se prosek kreira (najčešće je to dan kao vremenska jedinica) i da li se prosek formira na nivou artikla ili po lokacijama.
Istaći ćemo i da varijanta gde se metod obračuna troškova definiše na nivou lokacije nikako nije ispravna varijanta. Business Central ne podržava takvu opciju, dok se u nekim lokalnim knjigovodstvenim sistemima može sresti. Ovakav obračun troškova je pogrešan, jer dovodi do toga da prenos artikla između magacina (prenos sa jedne lokacija na drugu) može promeniti vrednost zaliha ili interna odluka da li prodati artikal sa jednog ili drugog magacina (najpre preneti) utiče na iznos troška. To znači da kompanija internim prebacivanjem artikala može promeniti vrednost svojih zaliha i trošak.
PARAMETRI ZA OBRAČUN TROŠKOVA
U okviru sistema Microsoft Dynamics 365 Business Central nekoliko je važnih parametara za obračun troškova:
- Automatsko knjiženje troškova. Ova opcija određuje da li se troškovi knjiže u glavnu knjigu odmah knjiženjem transakcija. Iako je najčešće ova opcija uključena, postoje situacije gde opcija naknadnog knjiženja u glavnu knjigu može biti korisna. Radi se o kompanijama sa enormno velikim brojem transakcija u toku dana. Sa ovom opcijom, ubrzava se proces obrade dnevnih transakcija (jer ih sistem ne knjiži u glavnu knjigu), a naknadno (na primer, u toku noći) pokreće procedura koja vrši knjiženje u glavnu knjigu. Na ovaj način se rasterećuje dnevno knjiženje i praktično knjiženje radi u dva koraka (evidencija u glavnu knjigu se vrši tek tokom noći).
- Knjiženje očekivanih troškova u glavnu knjigu. Termin očekivanih iznosa odnosi se na vrednosti zaliha koji još uvek nisu ispraćene finansijskim dokumentom (najčešće fakturom). ERP sistemi razlikuju fizički deo procesa (na primer, prijem i isporuku iz magacina) i finansijski deo procesa (knjiženje fakture). Ukoliko se u sistemu evidentira prijem u magacin, po kome još uvek nije stigla faktura, sistem ovaj iznos beleži kao „Očekivani iznos“. Uobičajeno je da se ovaj iznos ne knjiži u glavnu knjigu, već da se knjiženje evidentira tek kada se proknjiži faktura. U praksi se to pokazalo kao bolje rešenje čisto zbog jednostavnosti praćenja i manjeg broja transakcija. Ako se knjiže očekivani troškovi, sistem knjiži prijem, a zatim vrši storno tog očekivanog iznosa i knjiženje fakture. Nakon fakture, krajnji efekti su isti, ali ima dodatnih knjiženja. Upotrebna vrednost ove opcije posebno se ogleda u situacijama kada postoji veliki vremenski period između očekivanog i stvarnog iznosa (fizičkog i finansijskog procesa), ali, osim u specifičnim industrijama, sugerišemo da se proveri i reši uzrok kašnjenja, a ne da se rešava posledica koja iz toga proizilazi.
- Automatski obračun troškova. Kao što smo pomenuli, Business Central ima ugrađene procedure za usklađivanje troškova i vrednosti zaliha, najčešće, mada ne ograničeno, zbog retroaktivnih knjiženja. Naime, u praksi je česta situacija da se faktura dobavljača knjiži sa zakašnjenjem u odnosu na prijem u magacin ili da se naknadno evidentiraju zavisni troškovi nabavke, koji menjaju vrednost ulaza. Nisu tako retke ni situacije naknadnih promena standardnih troškova, evidencija preskočenog dokumenta, rešavanje nekog spornog dokumenta koji je čekao na obradu ili druge slične situacije. Usklađivanje je od značaja ukoliko je ta zaliha već preneta, potrošena ili prodata, kako bi se osigurao ispravan obračun. Sistem podržava opciju da se obračun troškova izvršava:
- Automatski, pri svakom knjiženju. Sugerišemo da budete obazrivi sa ovom opcijom, jer ista može usporiti proces obrade dokumenata, posebno kod kompanija koje imaju veliki broj artikala i transakcija.
- Automatski, periodično. Ova opcija podrazumeva da se podesi automatsko izvršenje procedure za usklađivanje troškova (na primer, dnevno ili nedeljno). Preporučeno je da se izvršenje procedure postavi van radnog vremena ili u periodu kada je manji intenzitet rada u ERP sistemu.
- Ručno. Ova opcija zahteva da se, s vremena na vreme, pokrene procedura ručno.
SPECIFIČNE SITUACIJE U PRAKSI
U nastavku ćemo pomenuti nekoliko situacija koje se sreću u praksi oko obračuna troškova u sistemu Microsoft Dynamics 365 Business Central. Ukoliko imate neko drugo pitanje, slobodno nam pišite.
- Retroaktivna knjiženja
Ukoliko se razmišlja o promeni metoda obračuna troškova ili definišu parametri i pravila za obračun i knjiženje kod uvođenja ERP sistema, posebnu pažnju treba staviti na retroaktivna knjiženja. Ovde ne mislimo na situacija da proces nije organizovan adekvatno, pa da se unos u ERP sistem vrši sa zakašnjenjem, već na situaciju da dokumenta dobavljača stižu nešto kasnije ili da se dokumenta koja pristižu odnose na ranije ulaze (pa naknadno menjaju vrednost ranije primljenih zaliha).
Većina teorije bavi se situacijama idealnog toka dokumenata, gde fizička izrada, dostavljanje i knjiženje prate stvarnu hronologiju. Ponekad se i korisnici bave samo ovim situacijama pri izboru metoda ili definisanju pravila za novi ERP.
U praksi nije tako, pa, posebno kod većeg obima dokumentacije, nije neuobičajeno da se dokumenta u ERP sistemu ne knjiže redom prema datumu, već kako pristižu u kompaniju, a određena dokumenta kasne. Dešava se da se neka dokumenta proknjiže sa par dana zakašnjenja (nekada i više) i to nakon nekih drugih, po datumu novijih dokumenata. Takođe, u praksi se često javljaju situacije storna, ispravki ili korekcija vrednosti u prošlosti (makar se radi i o nedelju-dve dalekoj prošlosti).
U teoriji se često preporučuj Prosečan metod obračuna. U tekstovima autori uglavnom pišu o uticaju proseka na troškove, pa često sugerišu da je to najbolji metod. Ipak u ovim tekstovima i primerima koji se navode se često ne pominju situacije retroaktivnih knjiženja, čega u praksi ima puno.
Prosečan metod obračuna troška najosetljiviji je na nepoštovanje hronologije transakcija (u smislu praćenja i čestih promena iznosa troškova), pa to treba imati na umu. Ističemo da ovde ne mislimo na tačnost obračuna, niti želimo naglasiti da su drugi obračuni univerzalno bolji od Prosečnog metoda. Ističemo samo da se u računovodstvenoj literaturi prednost daje prosečnom trošku, ali se sagledava samo idealni tok dokumenata. Sa prosečnim troškom i retroaktivnim knjiženjima, teže je ispratiti i biti siguran da iznos na kontu/artiklu u nekom trenutku već narednog trenutka neće biti promenjen, iako je nastao juče ili prošle nedelje. Sličan problem postoji i kod drugih metoda obračuna, ali je kod proseka izraženiji, jer će promenjeni prosek tangirati i mnoge druge transakcije.
Zato sugerišemo da i ovaj aspekt treba sagledati kod odluke.
- Upotreba zalihe za koju još nije stigao ulazni račun u Business Centralu
Korisnike nekada zbunjuje navedena situacija. Dešava se da u izveštajima za vrednovanje zaliha identifikuju artikle koji imaju negativnu vrednost ili na kontima imaju artikal koji ima negativan saldo. Logika sistema je sledeća (uz pretpostavku da je postavljeno automatsko knjiženje troškova, bez knjiženja očekivanih troškova):
- Ako se evidentira prijem zaliha u magacin, bez fakture, sistem iznos beleži kao „Očekivani“ iznos, ali stvarna vrednost zaliha je i dalje nula (na kontu je takođe nula).
- Kada se evidentira potrošnja ili prodaja artikla, sistem evidentira umanjenje vrednosti zaliha i trošak koji odgovara očekivanoj vrednosti.
- U tom trenutku praktično imamo situaciju nultog ulaza i neke vrednosti izlaza.
- Međutim, treba imati na umu da ova situacija postoji samo dok se ne evidentira ulazni račun. Čim se isti proknjiži, dodaje se stvarna vrednost zaliha (ulaza) i situacija postaje potpuno čista.
Savet je da se uvek u ovim situacijama provere prijemi za koji nisu vezane fakture. Takođe, korisnici mogu napraviti pregled filterima i povremeno pratiti ove situacije (posebno radi identifikovanja i rešavanja spornih situacija).
- Vrednost proizvodnje
Slična situacija javlja se kod proizvodnih kompanija. U proizvodnji, centralni dokument je radni nalog i za ERP sistem finansijska transakcija koja definiše radni nalog je proces zatvaranja. Kada se radni nalog zatvori, sigurni ste da je sistem odradio sve obračune, sveo vrednost izlaza na vrednost potrošnji materijala i vremena, ali i sve proknjižio u glavnu knjigu. Dok radni nalog nije zatvoren, nisu sprovedeni svi obračuni.
Stoga, korisnici nekada u izveštajima mogu videti negativnu vrednost polu ili gotovih proizvoda ili neslaganje na kontu zaliha ili proizvodnje u toku. Savet je proveriti po kojim radnim nalozima je artikal stavljen na stanje i da li su ti radni nalozi zatvoreni. Zatvaranje radnih naloga veoma je važan proces u proizvodnji i isti treba pažljivo organizovati.
- Kombinovanje ručnog i automatskog pokretanja obračuna troškova u Business Centralu
Na kraju, pomenućemo situaciju koja se u praksi povremeno dešava. Naime, korisnici ponekad postavljaju automatsko izvršenje (Job) procedure obračuna zaliha, ali dodatno povremeno ručno pokreću navedenu proceduru. Ovde ističemo da je veoma važno da se procedura obračuna zaliha, prilikom pokretanja, obavezno pokreće bez filtera i sa akcijom za knjiženje u glavnu knjigu. Ručno pokretanje procedure sa filterom i bez kvačice, može dovesti do toga da i automatska procedura nastavi izvršavanje sa istim parametrima. Job će se uredno izvršavati, ali neće obuhvatiti sve artikle, niti izvršiti knjiženje u glavnu knjigu, što može biti ozbiljan problem ako se ne primeti na vreme.
U praksi postoji još puno situacija oko obračuna troškova. Ako imate neko pitanje ili nejasnoću, javite nam se, rado ćemo pomoći.
#Microsoft Dynamics 365 Business Central #Microsoft Dynamics #NAV #Microsoft Dynamics Srbija #Navision #Navision Srbija #Business Central #Business Central Srbija #NAV Srbija #BC #BC Srbija #ERP #ERP Srbija #Obračun troškova #Costing
