Operativno planiranje novčanog toka ili kako izgraditi sustav kontrole novčanog toka. Podsustav "elektroničke aplikacije" za trošenje sredstava Aplikacija za trošenje sredstava 1c upp

1. Uvod

Planiranje gotovine jedan je od glavnih zadataka upravljačkog računovodstva, za razliku od financijskog računovodstva.

Naravno, postoje i druge značajne razlike između menadžmenta i računovodstva (različiti zahtjevi za analitiku, za procjenu i revalorizaciju imovine/obveza, potreba za stvaranjem rezervi itd.), ali potreba za rješavanjem problema planiranja je najteži od ih.
Složenost planiranja nije samo u pripremi plana (izračunavanju, oblikovanju prema različitim scenarijima), već je također potrebno:

Izvršite reprogramiranje;
Ažurirati planove, prenijeti prilagodbe na naredna razdoblja;
Provesti plan – analizu činjenica.

Treba priznati da se u većini poduzeća (koristeći 1C za automatizaciju) planiranje ne provodi u programu.
“Trebali bismo uspostaviti računovodstvo...” - tako mnogi tvrde.

Računovodstvo treba unaprijediti, da, ali ne nauštrb planiranja.
Naravno, i dalje planiraju (ali ne u 1C, već u XLS). I prvi, glavni zadatak (koji pokušavaju riješiti) je planiranje gotovine.

(1) Strateški (proračun);
(2) Operativni.

A ako se proračun (naravno, s pristupom planiranju odozgo prema dolje) može napraviti pomoću XLS-a, onda se operativno planiranje ne može napraviti.
Zaključak je da najčešće minimalni broj korisnika (1-2 osobe) radi s proračunskim tablicama. Za većinu poduzeća broj proračunskih stavki i druge analitike nije tako velik. Odnosno, sve se može ručno obraditi u XLS-u.

Ali što se tiče operativnog planiranja d/s, ovdje je situacija drugačija. Odnosno, često postoji veliki broj faktura za plaćanje, mnogo redovitih plaćanja, očekivanih plaćanja za narudžbe kupaca itd.

Osim toga, sve se to može "povezati" s velikim brojem primarnih dokumenata s kojima rade različiti korisnici programa, dokumenti se prilagođavaju, mijenja situacija itd.

Još jedna važna razlika između operativnog planiranja i proračuna je da ono često dolazi odozdo prema gore. Odnosno iz “Zahtjeva za d/s troškove” koje uvijek popunjavaju djelatnici odjela.

I te zahtjeve, sukladno tome, treba obraditi na vrijeme, prihvatiti/odbiti, “zakazati” i platiti.

Ukupno: operativno planiranje za d/s je prvi zadatak planiranja, koji bi trebao biti automatiziran u 1C za bilo koje poduzeće.

I kao rezultat planiranja, financijski odjel / riznica bi trebali "vidjeti" u sustavu:

Kada, kome, s kojeg bankovnog računa/gotovine, za koji iznos se mora platiti;
Kakvo će biti stanje gotovine na "taj i takav" datum, uzimajući u obzir trenutna stanja, planirane troškove i novčane primitke. Mora se izbjegavati tzv. "gotovinski jazovi"
Odnosno, postoji potreba za radom s kalendarom plaćanja.
Što dug s drugim ugovornim stranama će biti na navedeni datumi, uzimajući u obzir planirana plaćanja, primitke i trenutno stanje međusobnih obračuna.
Odnosno, postoji potreba za radom s kalendarom izračuna.

Svrha ovog članka – govoriti o mogućnostima automatizacije operativnog planiranja za d/c. Istodobno će se provesti usporedna analiza 3 različite konfiguracije cirkulacije (dvije su standardne iz 1C, jedna je specijalizirana iz tvrtke wiseadvice).

Svaka od konfiguracija može se koristiti za rješavanje problema operativnog planiranja, ali treba napraviti uravnotežen izbor na temelju opsega i razmjera vašeg projekta.

2. Značajke mekog pokretača 1.3

U ovom trenutku 1C još nije objavio dugo očekivano, novo izdanje UPP-a (revizija 2). I zbog toga ćemo se usredotočiti na ono što je dostupno - odgovarajuće podsustave SCP 1.3:

Potrebno je napomenuti da je podsustav „Zahtjevi za izdatak gotovine“ relativno nedavno ažuriran u konfiguraciji (2011.). I kao rezultat toga, u načinu upravljanog sučelja, stavka "Zahtjevi za potrošnju d/s/" pojavila se na ploči odjeljka.

Ako pokušate u standardnoj konfiguraciji, u modu datoteke, otvoriti obrazac dokumenta “Zahtjev za D/s Troškove” (aka, ZRDS), tada se odmah pojavljuje greška za varijablu “Globalne vrijednosti” iz općeg modula “Rad s Opće varijable”.

Takve se pogreške mogu ispraviti, ali kako kažu: “talog ostaje”. Odnosno, u podsustavu UPP ZRDS ima dovoljno “hrapavosti”.
Mogućnost sastavljanja ZRDS dokumenta putem WEB preglednika je korisna, no u praksi ćete morati dobro razmisliti o pojednostavljenju i ergonomiji standardnog oblika dokumenta. To će biti posebno važno za mobilne uređaje.

Ali što se tiče kalendara plaćanja, u načinu tankog klijenta, daljinski putem WEB preglednika itd. nećete ga moći koristiti. Razlog je taj što podsustav Upravljanje gotovinom nije ažuriran dugo vremena, a posebno izvješće Kalendar plaćanja nije izgrađeno na sustavu sastavljanja podataka. Stoga se ovo izvješće ne može koristiti u tankim klijentima; ne postoji mogućnost kreiranja prilagođenih postavki za njega.

U radu sa ZRDS-om važno mjesto zauzimaju propisi za usklađivanje i odobravanje zahtjeva. Ovisno o organizacijska struktura poduzeća i drugih poslovnih značajki, interni postupak za odobravanje zahtjeva (propisi o odobrenju) može biti prilično složen (višefazni, varijabilan itd.). Dakle, ovo nije lak zadatak za automatizaciju.

U UPP-u je implementiran podsustav koordinacije i odobravanja. Omogućuje prilično fleksibilne postavke.

Odobrenje je potvrda o potrebi plaćanja prijave. Tipično, odobrenje mora proći kroz šefove odjela, menadžere i druge odgovorne osobe tvrtke.
Odobrenje je konačna potvrda (od strane blagajnika) da će zahtjev biti plaćen. U tom slučaju potrebno je odrediti datum plaćanja i bankovni račun/blagajnu iz koje će se izvršiti plaćanje. Dakle, plaćanje ulazi u operativni plan (kalendar plaćanja).

Mora se primijetiti da niz aspekata standardne funkcionalnosti soft startera ne osigurava ono što je potrebno za stvarnu implementaciju podsustava.
Kasnije ću pisati o tim "trenucima", ali za sada pogledajmo koju funkcionalnost pruža tipična konfiguracija.

Za svaku organizaciju možete zasebno omogućiti korištenje mehanizma za odobravanje zahtjeva.

Moguće je konfigurirati redoslijed aplikacije kroz rute i hijerarhiju ruta.

Treba napomenuti da se hijerarhija u imeniku odjela ne uzima u obzir u mehanizmima usmjeravanja aplikacija.
Također je potrebno ukinuti da su koordinacija i suglasnost tehnički konstruirane bez korištenja mehanizma poslovnih procesa.

U svakoj točki možete odrediti jednog/više korisnika za koje će biti dostupno odobrenje aplikacije. Odnosno, zahtjev može odobriti bilo tko od njih (tko prvi to uspije).

Za svaki odjel možete dodijeliti odgovarajuću točku rute odobrenja. Suština ovoga je sljedeća: prilikom ispunjavanja prijave (ZRDS) mora biti naveden Središnji federalni okrug (odjel). I ovisno o navedenoj podjeli, UPP "pronalazi" odgovarajuću točku odobrenja i "šalje" zahtjev za odobrenje na tu točku.

Također je moguće ne navesti odjel prilikom postavljanja rute odobrenja. U ovom slučaju, takva koordinacijska točka bit će "primijenjena" na sve CFD-ove za koje odgovarajuća točka rute nije posebno naznačena.

Samo odobrenje se provodi posebnom obradom “Odobrenje aplikacije”

Analiza planirane raspoloživosti sredstava, dinamika plaćanja i praćenje blagajničkih jazova vrši se u izvješću „Kalendar plaćanja“.

Uz planiranu potrošnju d/s (ZRDS) možete uzeti u obzir i planirani primitak d/s. Za te potrebe predviđena je izrada posebnog dokumenta „Planirani primitak prihoda“.

Treba napomenuti da iako dokument „Planirani primitak d/c“ ima stanja (izrađeno, dogovoreno i sl.), ne postoji mogućnost usuglašavanja ovog dokumenta (kao ni ZRDS). Odnosno, promjena statusa dokumenta moguća je samo u " ručna kontrola».

I u UPP-u je moguće uzeti u obzir planirani primitak gotovine od kupaca bez pripreme dokumenata „Planirani primitak gotovine“.

Odnosno, ako se za kupca izdaju „Nalozi kupaca“, tada se u zasebnom izvješću „Kalendar plaćanja uzimajući u obzir narudžbe“ može vidjeti ovaj planirani primitak.

Uz izvješće Kalendar plaćanja postoji i izvješće Analiza raspoloživosti gotovine.

Istovremeno je moguće rezervirati d/s (temeljem zahtjeva za troškove) ili staviti zahtjeve prema planiranim prihodima.

Tu je i funkcionalnost zatvaranja ZRDS-a i planiranih prihoda iz d/s. Za te potrebe, u načinu rada „redovni klijent“, dostupni su dokumenti „Zatvaranje zahtjeva za izdatke/primitke“.

Međutim, ova funkcionalnost također nije podržana u načinu tankog/web klijenta.
Ovdje morate razumjeti da je tehnika "tvrde rezervacije" snažno povezana s kronologijom unosa dokumenata, a to otežava prilagodbe i ponovno planiranje.

Stoga je funkcionalnost ostavljena u UPP-u radije kao „nasljeđe prošlosti“, a kalendar plaćanja treba koristiti za analizu dostupnosti d/s.

Dakle, razmotrili smo funkcionalnost mekog pokretača i sada ću navesti one aspekte standardne konfiguracije koji se u praksi, na projektima, moraju modificirati:

Prema dokumentu „Zahtjev za trošak d/s”:
1. U dokumentu možete označiti "Diviziju" (usput, u konfiguraciji je označena kao Središnji savezni okrug - središte financijske odgovornosti). No sasvim je moguće da se zahtjev podnese iz jednog odjela (CFD), au tom slučaju će se troškovi morati dalje pripisati/distribuirati drugom(im) odjelu(ima) (CFD - centri za financijsko upravljanje).
  Sposobnost određivanja digitalnih funkcija, itd. - odsutan.
  Ne postoji mogućnost promjene rute ili preusmjeravanja aplikacije na druge rute.

Ne postoji mogućnost planiranja prijenosa gotovine između tekućih računa, s računa na blagajnu i sl.

Proces dogovora:
1. Moguće je uskladiti ZRDS, ali ne postoji mogućnost koordinacije planiranog primitka d/s.
2. U praksi postaje potrebno provoditi odobrenja za druge zaposlenike. Istovremeno, sustav treba bilježiti i podatke o tome “tko je i za koga izvršio odobrenje”.
  Mogućnost instaliranja više mogućih izvršitelja na jednoj koordinacijskoj točki često nije prikladna, pa se taj izvršitelj može naznačiti u drugim fazama koordinacije. Kao rezultat toga, sve će to dovesti do činjenice da će zaposlenik istovremeno imati i glavne i neizravne zadatke odobrenja na popisu zahtjeva za odobrenje. Naravno, to zbunjuje korisnika i nije zgodno.
  Ukratko, izostala je mogućnost koordinacije za drugog izvođača, sposobnost da se naznači tko za koga ima pravo koordinacije.
3. U postupku odobravanja zahtjeva, kada se zahtjev prosljeđuje na odobrenje sljedećem na ruti, potrebna je funkcionalnost automatskog obavještavanja (e-mailom) sljedećeg izvršitelja, kao i autora zahtjeva. .
4. Ako je autor aplikacije već odgovoran za koordinaciju/odobrenje (u bilo kojoj fazi rute!), onda je sasvim logično da program automatski “skrati” rutu, preusmjeravajući aplikaciju na najvišu dostupnu razinu. No, to UPP-om nije predviđeno.
- Svi gore navedeni zahtjevi, iako nisu uključeni u standardnu konfiguraciju, ipak su .

Izvješća, prava pristupa.
1. Traži se mogućnost ograničenja pristupa prijavama samo raspoloživim autorima/izvođačima (koordinatorima); po odjelima dostupnim korisniku.
2. Ne postoji izvješćivanje o praćenju (po danima i intervalima) stvarnog i planiranog duga. To vrijedi i za kupce i za dobavljače.
3. Izvješćivanje i neke od funkcionalnosti nisu prikladni za rad u načinu tankog/web klijenta.
Računovodstvo redovnih sporazuma i ugovora.
1. Česte su situacije kada je potrebno redovito plaćati dobavljače. Na primjer, plaćanje najma itd.
  UPP to ne prikazuje automatski u kalendaru plaćanja itd. ove nadolazeće troškove. Odnosno, potrebno je ručno pratiti takva plaćanja i ispunjavati zahtjeve za plaćanje, što je nezgodno i dugotrajno.
2. Ugovorom s kupcima i dobavljačima mogu se ugovoriti uvjeti o postotku avansa, rokovima plaćanja i sl.
  UPP ne bilježi automatski sve te podatke i (kao rezultat) automatski ih odražava u kalendaru plaćanja.

3. Značajke UT 11.1

Izlaskom nove konfiguracije “Trade Management Rev.11” pojavile su se mnoge nove korisne značajke za zadatke operativnog planiranja i financijske kontrole.
Možda najznačajnija stvar u ovom dijelu u UT11 (u usporedbi s UPP 1.3) je mehanizam za obračun plana plaćanja. Ovaj mehanizam “zatvara” ono što je nedostajalo – automatizaciju planiranja/računovodstva po redovnim ugovorima i ugovorima.

Dakle, u UT11 uopće ne morate sastavljati dokumente (ako nema potrebe, naravno) za planiranje troškova i primitaka, a istovremeno će se normalno formirati kalendar plaćanja.

Možete poništiti da "standardne postavke" izvješća "Kalendar plaćanja" ne ispunjavaju očekivanja (kao takav, kalendar se ne prikazuje), ali u korisničkom načinu možete dodati grupiranje prema "datumu plaćanja" i izvješće će se generirati u uobičajenom obliku.

Funkcionalnost izvješća znatno je proširena (u usporedbi sa SCP 1.3) zbog korištenja sustava za sastavljanje podataka. Sada se izvješće može generirati u tankom/web klijentu, spremiti u bazu podataka i dodijeliti različitim korisnicima potrebne postavke.

Osim planiranja potrošnje i primitka robe za kućanstvo, UT11 sada ima i funkcionalnost planiranja kretanja robe za kućanstvo. U te svrhe možete sastaviti dokumente „Nalog za preseljenje kućanstava“.

U odnosu na UPP 1.3 za dokument “Zahtjev za izdatak gotovine” povećan je broj razmatranih vrsta poslovnih transakcija:

Sada je moguće odobriti i dokumente „Zahtjev za utrošak sredstava“ i druge naloge:

Za analizu duga po intervalima/rokovima, postoji izvješće “Potraživanja”. Po potrebi možete izraditi i kalendar duga. Da biste to učinili, u prilagođenom načinu rada dodajte grupiranje prema datumima plaćanja.

Nažalost, UT11 (kao i prije) ne pruža mogućnost analize kalendara zaduženja po dobavljačima. Međutim, UT11 treba dovršiti za ovaj zadatak.

Sažeti: nova metodološka rješenja "1C", zajedno s mogućnostima platforme 8.2, daju dobru osnovu za automatizaciju poslova operativnog planiranja i kontrole d/s.

Ali u isto vrijeme morate razumjeti da konfiguracija UT11 nije potpuno, gotovo rješenje za automatizaciju riznice i financijsko planiranje.

Prvo, UT11 implementira u vrlo pojednostavljenom obliku mehanizam za koordinaciju/odobravanje zahtjeva za troškove i druge d/s planske dokumente. Odnosno, nema mehanizama usmjeravanja, proces odobravanja zahtjeva sveden je na jednostavno postavljanje statusa.
Drugo, UT11 nema proračunski podsustav i (kao rezultat toga) ne postoji funkcionalnost za praćenje aplikacija za planirane proračune.

4. WA Značajke: Financijer

Povijesno gledano, konfiguracija WA:Financier razvijena je na temelju proizvoda Treasury Management.

U isto vrijeme, novo rješenje "Financier" iz WiseAdvice također uključuje:

Podsustav planiranja proračuna;
Podsustav za upravljanje ugovorima;
Podsustav za formiranje i obračun stvarnih plaćanja;
Fleksibilan, prilagodljiv mehanizam za generiranje/ispunjavanje dokumenata na temelju predložaka;
Fleksibilan, prilagodljiv integracijski podsustav klijent-banka.

Razmotrimo glavnu funkcionalnost "WA: Financier" u smislu riznice - od uzimanja u obzir uvjeta ugovora do stvaranja kalendara plaćanja.

Tijekom procesa odobravanja zahtjeva ne možete samo odobriti/odbiti dokument (kao što se radi u UPP-u), već su dostupne i druge funkcije: na primjer, poslati dokument na reviziju ili zatražiti dodatne informacije. informacija.
Cijeli ovaj proces je automatiziran te se sukladno tome daje izvješće o statusu obrade odobrenja dokumenata.

5. Rezultati

Zaključci:

Automatizirati rad financijskih odjela, riznica, organizacija složene organizacijske strukture. struktura je najprikladnije rješenje "WA: financijer".
Ovo se rješenje razvijalo i razvijalo dugo vremena, akumulirajući specifičnosti i zahtjeve različitih financijskih institucija. odjela i blagajne. Ukupni troškovi rada za razvoj rješenja iznosili su više od 5000 osoba/sati.
Prednost rješenja WA:Financier je njegova napredna funkcionalnost i velik broj mehanizama programskih postavki. Dakle, implementacija ovog rješenja moguća je u kratkom vremenu (tzv. “out-of-the-box implementacija”), bez dodatnih. razvoj, programiranje itd.
Budući da rješenje sadrži mehanizme za dvosmjernu razmjenu sa svim glavnim standardnim konfiguracijama, integracija u postojeću strukturu (razmjena podataka s bazama podataka UT, UPP, Kompleksnaya, Bukh) neće biti teška.
Automatizirati financijski odjel/riznicu u okviru opsežnog projekta automatizacije najbolje rješenje je na temelju UPP-a.
Istodobno, morate razumjeti da će funkcionalnost mekog pokretača zahtijevati poboljšanja.
Specifičnosti, financijski zahtjevi. odjeli i riznice nisu tako duboko ugrađeni u UPP kao što je to učinjeno u zasebnim, specijaliziranim rješenjima.
Stoga bi se implementacija SCP-a za ove zadatke trebala provoditi samo kao dio projekta automatizacije.
Za velike organizacije, za automatizaciju odjela riznice UT11 ne odgovara.
U ovoj odluci, prvo, nema mehanizama za usklađivanje/odobravanje planskih dokumenata.
Drugo, ne postoji proračunski podsustav i kontrola izvršenja proračuna tijekom operativnog planiranja.
Međutim, UT11 savršeno za automatizacija (uključujući operativno planiranje d/c) male financijske odjela poduzeća.

Dokument “Zahtjev za utrošak sredstava” namijenjen je planiranju i koordinaciji plaćanja.
Dokument “Zahtjev za trošenje DS” možete kreirati odlaskom na odjeljak “Riznica” - “Planiranje i kontrola sredstava” - “Zahtjevi za trošenje DS” - Kreiraj.
Dokument “Zahtjev za izdatak DS” ima više tipova operacija koje se odabiru prilikom izrade. Svaka vrsta aplikacije namijenjena je odražavanju različitih poslovnih transakcija, od kojih će svaka biti opisana u ovoj uputi.
Kreirani dokumenti „Zahtjev za trošenje DS“ prikupljaju se i usuglašavaju pomoću dokumenta „Registar uplata“. Nakon odobrenja, temeljem zahtjeva, automatski se kreiraju dokumenti “Otpis bezgotovinskog DS” koji se učitavaju u banku klijenta za plaćanje od strane banke.
Slijede primjeri izvršenja dokumenata „Zahtjev za izdatke DS“ za svaku vrstu operacije.

Plaćanje dobavljaču
Za obradu platnog prometa prema dobavljaču namijenjen je tip transakcije dokumenta „Zahtjev za izdatak DS“ - „Plaćanje dobavljaču“.
U novom dokumentu “Zahtjev za trošenje DS” crvenom bojom označena su polja koja je potrebno popuniti za obradu dokumenta. Dokument se kreira u statusu „Nije odobreno“, status se automatski mijenja prilikom odobravanja očevidnika plaćanja. Prioritet aplikacije nakon izrade automatski se postavlja na "Srednji".

Slika 1. Obrazac dokumenta „Zahtjev za utrošak DS“, tip operacije „Plaćanje dobavljaču“ (neispunjeno)
Pojedinosti dokumenta „Zahtjev za trošenje DS” potrebno je popuniti na sljedeći način:
Osnovna kartica
Broj– generira se automatski tijekom izvođenja, ne može se postaviti ručno.
datum– kada se kreira, postavlja se trenutni datum.
Organizacija– potrebno je odabrati s predloženog popisa organizacija pomoću gumba ili upisom naziva u polje, tražena vrijednost će biti ponuđena za odabir.
Podjela– iz imenika „Struktura poduzeća” morate odabrati odjel za koji treba izvršiti plaćanje.
Podnositelj zahtjeva– prema zadanim postavkama naznačen je trenutni korisnik sustava koji kreira aplikaciju.
Planiranje– zadana postavka je “U valuti plaćanja” i ne može se mijenjati.
Iznos– označava iznos tražene uplate.
Valuta– navesti valutu traženog plaćanja.
Operacija– odražava se vrsta transakcije dokumenta „Zahtjev za izdatke DS“ odabranog tijekom kreiranja
Datum plačanja– označava datum na koji se mora zakazati plaćanje dobavljaču.
Oblik plaćanja– zadana postavka je “U bilo kojem obliku” i ne može se mijenjati.
Primatelj– označava dobavljača iz imenika „Druge ugovorne strane” kojem je potrebno izvršiti plaćanje.
Račun primatelja– prilikom odabira „Primatelja“ automatski se postavlja račun primatelja; ako je potrebno, ako je na „Fakturi za plaćanje“ koju dostavlja dobavljač naveden drugi račun, potrebno je odabrati željeni iz imenika „Bankovni računi“.
Preko granice– ako sustav održava sustav limitiranja gotovinskih izdataka u kontekstu poslovnica odnosno stavki novčanog tijeka, ako iznos plaćanja koji se vrši nije prethodno uključen u limit, prilikom knjiženja dokumenta korisnik će dobiti poruku o pogrešci i prijava neće biti obrađena.

Slika 2. Primjer greške prilikom postavljanja naloga za koji nije planiran limit.
Da biste naručili preko ograničenja, morate postaviti oznaku "Over Limit".
Prijenos u proračun– ova se zastavica postavlja ako je uplata prijenos u proračun. Postavljanje zastavice omogućuje unos vrijednosti KBK, OKTMO itd. potrebnih za uplate u proračun.

Slika 3. Primjer postavljanja oznake “Prijenos u proračun”.
UIP– jedinstveni identifikator plaćanja, naznačen samo ako je to predviđeno ugovorom s primateljem plaćanja.
Svrha uplate- program nudi nekoliko opcija za automatsko popunjavanje svrhe plaćanja pomoću gumba "Umetni".

Slika 4. Mogućnosti za automatsko popunjavanje polja “Svrha plaćanja”.
Popis dokumenata, uklj. PDV- prikazat će informacije o objektima poravnanja iz kartice "dešifriranje plaćanja".

Uključuje PDV (18%) (za cijeli iznos), uklj. PDV (10%) (za cijeli iznos), Bez poreza (PDV)- Podaci o PDV-u bit će dodani unesenom tekstu.

Tekst s bankovnog računa primatelja- unosi tekst naveden u polju "Tekst svrhe plaćanja" iz kartice računa druge ugovorne strane.

Slika 5. Primjer popunjavanja kartice “Osnovno”.

Kartica Podaci o plaćanju
Kartica “Dekodiranje plaćanja” pruža detaljne informacije o plaćanju i međusobnim obračunima s primateljem.
Plaćanje se može unijeti kao lista, tj. raspodijeliti na više objekata obračuna ili bez cijepanja moguće je odabrati samo jedan objekt obračuna.
Plaćanje iz državnih fondova za obranu– zastavica je postavljena samo ako se plaćanje odvija u okviru naloga vlade obrane, u ostalim slučajevima zastavica nije postavljena.
Obračunski objekt– kao objekt poravnanja možete navesti „Ugovor s drugom ugovornom stranom“ (za ovu vrstu operacije prijavnog dokumenta, kada je odabrano, dostupni su ugovori s tipom odnosa „S dobavljačem/izvršiteljem“) ili dogovoreni dokument „Narudžba dobavljaču”.
Davatelj
Iznos međusobnih obračuna– postavlja se automatski prilikom knjiženja dokumenta.
Valuta– postavlja se automatski prilikom odabira objekta izračuna.
DDS članak– označiti stavku novčanog tijeka koja odgovara vrsti plaćanja.
Komentar– po potrebi navesti komentar na dešifriranje plaćanja.

Slika 6. Primjer popunjavanja kartice „Dekodiranje plaćanja“.
Kartica raspodjele računa
Na kartici "Raspodjela na račune" naveden je bankovni račun organizacije s kojeg se sredstva trebaju teretiti. Iznos i datum uplate postavljaju se automatski prema podacima navedenim na kartici “Osnovno”.

Slika 7. Primjer popunjavanja kartice “Raspodjela po računima”.

Slika 8. Primjer automatski kreiranog dokumenta „Otpis bezgotovinskog DS“ za aplikaciju s tipom transakcije „Plaćanje dobavljaču“.

Povrat uplate klijentu
Za obradu transakcija povrata klijentima namijenjena je vrsta transakcije u dokumentu “Zahtjev za trošenje DS” - “Povrat uplate klijentu”.
Sastav detalja dokumenta „Zahtjev za izdatak DS“ kod ove vrste operacije identičan je sastavu detalja kod plaćanja dobavljaču, jedina razlika je u vrsti druge ugovorne strane i predmetu namirenja.

Slika 9. Obrazac dokumenta “Zahtjev za utrošak DS”, tip operacije “Povrat uplate klijentu”
Primatelj– označava klijenta iz imenika „Druge strane” koji treba izvršiti plaćanje.
Obračunski objekt– kao objekt poravnanja možete navesti „Ugovor s drugom ugovornom stranom“ (za ovu vrstu operacije prijavnog dokumenta pri odabiru su dostupni ugovori s tipom odnosa „S kupcem/kupcem“) ili ugovoreni dokument „ Narudžba kupca”.
Kupac– polje se popunjava automatski prilikom odabira objekta obračuna. Instaliran je element imenika "Partneri" naveden u odgovarajućem polju objekta izračuna.

Slika 10. Primjer popunjavanja kartice „Dekodiranje plaćanja“.
Nakon prolaska svih faza odobrenja, dokumentu „Zahtjev za trošenje DS-a” dodjeljuje se status „Za isplatu” i automatski se kreira dokument „Otpis bezgotovinskog DS-a”.

Slika 11. Primjer automatski kreiranog dokumenta „Otpis bezgotovinskog DS-a“ temeljem aplikacije s tipom operacije „Povrat uplate klijentu“.

Izdavanje odgovornom
Za formaliziranje transakcija za izdavanje sredstava na bankovni račun odgovorne osobe namijenjen je tip transakcije dokumenta „Zahtjev za trošenje DS” - „Izdavanje odgovornoj osobi”.

Slika 12. Obrazac dokumenta „Zahtjev za trošenje DS“, tip operacije „Izdavanje odgovornom“
Odgovorna osoba– zaposlenik je naznačen iz imenika “ Pojedinci”, kome je potrebno prenijeti novac.
izvješće– iz predloženog popisa razdoblja potrebno je naznačiti razdoblje do kojeg računovođa treba podnijeti izvještaj o primljenom iznosu.

Slika 13. Primjer popunjavanja kartice „Dekodiranje plaćanja“.
Nakon prolaska svih faza odobrenja, dokumentu „Zahtjev za trošenje DS-a” dodjeljuje se status „Za isplatu” i automatski se kreira dokument „Otpis bezgotovinskog DS-a”.

Slika 14. Primjer automatski kreiranog dokumenta „Otpis bezgotovinskog DS-a“ temeljem aplikacije s tipom operacije „Izdavanje obveznicima“.

Bitan uvjet za učinkovito postojanje poduzeća u suvremenom konkurentskom okruženju je stvaranje učinkovitog mehanizma upravljanja Gotovina teče osiguranje generiranja brzih i pouzdanih informacija, reguliranje međusobnih obračuna, povećanje discipline plaćanja iu konačnici ubrzanje gotovinskog prometa.

Konfiguracija sadrži alate za automatizirano upravljanje gotovinom poduzeća, koji obavlja dvije glavne funkcije:

operativno računovodstvo stvarnog kretanja sredstava poduzeća na računima za poravnanje i blagajnama;
operativno planiranje novčanih primitaka i izdataka poduzeća.

Opće planiranje rashoda i primitaka sredstava poduzeća provodi se u okviru proračuna. Financijski plan koji se izrađuje - proračun - djeluje kao skup smjernica i ograničenja za podsustav upravljanja gotovinom.

Ali u okviru funkcionalnosti upravljanja gotovinom održava se operativni financijski plan - kalendar plaćanja. Ima smisla izraditi kalendar plaćanja nekoliko dana unaprijed.

Isplatni kalendar je zbirka zahtjeva za trošenje sredstava i planiranih novčanih primitaka. Kalendar plaćanja je sastavljen s detaljima do mjesta gdje su sredstva pohranjena - bankovni računi i blagajne poduzeća. Prilikom sastavljanja kalendara plaćanja automatski se provjerava njegova izvedivost - dostatnost novčanih rezervi na mjestima gdje su pohranjene.

Podjela funkcije financijskog planiranja na dva konfiguracijska podsustava - podsustav proračuna i podsustav upravljanja gotovinom - odgovara podjeli funkcija financijskog upravljanja između različitih odjela i zaposlenika poduzeća. Ako proračun sastavljaju financijske službe, tada zahtjeve za trošenjem sredstava generiraju zaposlenici i odjeli koji izravno komuniciraju s ugovornim stranama tvrtke.

U konfiguraciji se generiraju novčani dokumenti (nalozi za plaćanje, potvrde o primitku i zaduženju itd.), osigurava interakcija sa specijaliziranim bankovnim programima kao što je „Klijent banke“, kontroliraju se financijski tokovi te dostupnost sredstava u skladišnim prostorima. pratio. Omogućena je mogućnost gotovinskog plaćanja u stranim valutama.

Dokument „Zahtjev za utrošak sredstava“ služi za evidentiranje odluke o gotovinskom ili bezgotovinskom plaćanju (skupina plaćanja) ili premještanju sredstava. Podaci o dokumentima i postupak njihove uporabe u osnovi su slični dokumentima „Nalog za plaćanje (odlazni)“ i „Nalog za izdatak u blagajni“.

Parametri rezervacije i plasmana mogu se popuniti automatski. U tu svrhu dokument predviđa zastavice i "Automatsko postavljanje".

Ako su ove zastavice postavljene, tada se stupac "Položaj" može automatski ispuniti kada kliknete gumb "Ispuni i objavi".

Automatska i ručna shema postavljanja mogu se kombinirati. Kad su zastave postavljene "Automatska rezervacija" I "Automatsko postavljanje" Možete ručno odrediti opciju plasmana za dio iznosa prijave. Zatim kada pritisnete tipku "Ispuni i objavi" Bit će automatski plasman samo za preostali iznos.

Kada je vrsta operacije postavljena na " Plaćanje dobavljaču" ili " Povrat novca kupcu" izvršene su promjene u operativnim nagodbama s drugim ugovornim stranama.

Na temelju dokumenta “Zahtjev za utrošak sredstava” mogu se unijeti bankovni i gotovinski isplatni dokumenti. Takvi dokumenti pružaju potrebnu “ Primjena", koji se popunjava dok upisujete na temelju njega ili se može ispuniti ručno. Prilikom knjiženja dokumenata plaćanja s navedenim zahtjevom za trošenje sredstava, provjerava se usklađenost iznosa dokumenta s trenutnim stanjem nepodmirenih plaćanja za ovaj zahtjev.

Prilikom postavljanja dodatnih prava korisniku je moguće zabraniti obradu platnih dokumenata bez navođenja zahtjeva za trošenje sredstava.

Dokument „Zahtjev za utrošak sredstava“ također može poslužiti kao poveznica između podsustava za upravljanje gotovinom i podsustava za proračun. U tu svrhu aplikacija nudi blok detalja sličan dokumentu „Proračunsko poslovanje“ (scenarij planiranja, stavka prometa, središnji financijski okrug, projekt itd.). Navedenim podacima, prilikom podnošenja zahtjeva, prati se usklađenost ukupnog iznosa sredstava odobrenih za utrošak s prethodno utvrđenim graničnim vrijednostima.

Značajke rada s aplikacijama pri korištenju mehanizma odobravanja aplikacija

Mehanizam odobravanja zahtjeva koristi se izborno: za popis organizacija.

Pri korištenju mehanizma podudaranja aplikacija pojavljuju se sljedeće značajke:

Ukoliko u prijavi nije navedena organizacija, ova prijava ne sudjeluje u odobravanju

Ruta za odobravanje zahtjeva određuje se u skladu s postavkama ovisno o Odjelu navedenom u zahtjevu.

Ukoliko zahtjev nije prošao put odobrenja (status zahtjeva nije “Odobreno”), na temelju njega se ne može izdati dokument o plaćanju

Ako aplikacija počne prolaziti kroz put odobrenja, aplikacija se može promijeniti

Korisnik čija se prijava trenutno odobrava

Korisnici koji odobravaju aplikaciju u višim fazama odobravanja
Drugi korisnici ne mogu promijeniti aplikaciju.

Ako je narudžba u stanju "Odobreno", ne može se mijenjati

Ako aplikacija prijeđe u stanje "Odbijeno", prijava se poništava

Trenutačni status prijava nalazi se u popisu prijava

status se prikazuje u posebnom stupcu

Koristi se grupiranje prema statusu narudžbe

aplikacije su označene bojom pozadine
- odbijeno - ružičasto

U drugom dijelu članka razmotrit ćemo princip kreiranja „Zahtjeva za utrošak sredstava“, njegovo prosljeđivanje putem odobrenja i izdavanje sredstava prema kreiranoj aplikaciji.
Pogledajmo primjer:

Računovođa nabave formira zahtjev za utrošak sredstava kako bi izvršio avansno plaćanje dobavljaču IP Dobronravov za nabavu materijala;
Financijski direktor mora pregledati i odobriti prijavu;
Na temelju odobrene prijave računovođa nabave generira blagajnički nalog (bez oznake „Plaćeno“, ali s oznakom „Prikazati u operativnom knjigovodstvu“);
Stariji blagajnik, nakon što je provjerio nalog za blagajnu, izdaje sredstva (i označava dokument kao "Plaćeno");
Računovođa gotovinskog prometa provjerava blagajnički nalog (označava kućicu za prikaz u knjigovodstvenim i porezno knjigovodstvenim evidencijama kako bi se generirale računovodstvene i porezno knjigovodstvene knjižice).

Kako bismo lakše prikazali transakcije, prebacimo sučelje na "Upravljanje gotovinom".
Prije nego počnete raditi sa zahtjevima za utrošak sredstava, morate unijeti sve popratne informacije. Prvo što trebate ispuniti je informator „Postavke za odobravanje zahtjeva za utrošak sredstava“. U “Podešavanje odobravanja zahtjeva” navedene su organizacije za koje se ovaj mehanizam koristi i datum početka korištenja mehanizma odobravanja. Ova postavka je potrebna kako bi program mogao odrediti da će organizacija StroyTorg LLC koristiti mehanizam za odobravanje zahtjeva za trošenje sredstava od 1.1.2013.

Također je potrebno konfigurirati koordinacijske rute (slika 2). Ova postavka navedena je u registru informacija „Postavke za početak odobrenih ruta”: utvrđuje se korespondencija odobrenih ruta odjelima. Ruta odobrenja (direktorij „Putovi odobrenja”) označava fazu i popis osoba koje odobravaju u ovoj fazi. U našem primjeru, kreirana aplikacija će prvo morati proći jednu fazu odobrenja od strane financijskog direktora.

Također je potrebno uspostaviti informacijski registar „Postavljanje odobrenja zahtjeva za utrošak sredstava“ (Slika 1) i odrediti faze (rutu) odobravanja zahtjeva (Slika 2)

Riža. 1

Riža. 2

Koordinacijski put Prijava se utvrđuje sukladno postavkama i ovisno o odjelu navedenom u prijavi.

Bilješka da jedna podjela mora odgovarati samo jednoj koordinacijskoj ruti. Put odobrenja mora biti naveden za svaki odjel jer u suprotnom proces odobrenja za sve aplikacije stvorene za ovaj odjel neće stupiti na snagu.

1. Računovođa nabave kreira dokument “Zahtjev za utrošak sredstava”.

U sučelju “Upravljanje gotovinom” koje smo odabrali, idite na stavku izbornika “Planiranje” - “Zahtjevi” - “Zahtjev za trošenje sredstava” (slika 3). Kreirajmo “Prijavu za utrošak sredstava” sa statusom tipa “Pripremljeno” (slika 5)

Aplikacija ima nekoliko tipova operacija koje ponavljaju tipove operacija „Izlazni nalog za gotovinu“ i „Izlazni nalog za plaćanje“ (Slika 4.)

U "Zahtjevu za trošenje sredstava" na kartici "Obračuni s drugim ugovornim stranama" navedeni su osnovni podaci: druga ugovorna strana za plaćanje kojoj se sredstva trebaju izdati, kao i ugovor, iznos, organizacija, podjela i status.

Na kartici "Opis" možete odrediti Dodatne informacije u bilo kojem obliku.

Kartica “Dodjela” pruža mogućnost rezervacije i plasiranja sredstava (slika 6). To znači da u našem primjeru knjigovođa nabave može rezervirati sredstva za isplatu predujma dobavljaču, te navesti s koje će se blagajne sredstva izdati. Parametri rezervacije i plasmana mogu se popuniti automatski. Za tu svrhu u dokumentu postoje oznake. "Automatska rezervacija" I "Automatsko postavljanje". Ako su ove zastavice postavljene, tada se stupac "Položaj" može automatski ispuniti kada kliknete gumb "Ispuni i objavi". Automatska i ručna shema postavljanja mogu se kombinirati.

Podaci na kartici “Budžetiranje” mogu se koristiti kao poveznica između podsustava za proračun i podsustava za upravljanje gotovinom. Podaci prikazani na ovoj kartici služe za kontrolu iznosa sredstava planiranih za isplatu u skladu s planiranim proračunom (slika 7).

Budući da knjigovođa nabave ima ograničena prava pristupa, u dokumentu „Zahtjev za utrošak sredstava“ može postaviti samo status „Pripremljeno“, a statusi kao što su: „Odobreno“, „Odgođeno“, „Usuglašeno“, „Odbijeno“ su postavljaju korisnici, odgovorni za odobravanje aplikacije.

2. Financijski direktor razmatra i odobrava zahtjev za utrošak sredstava u iznosu od 120.000 rubalja.

Financijski direktor može analizirati popis zahtjeva koji zahtijevaju razmatranje pomoću obrade "Status odobrenja zahtjeva" (Slika 8).

Kada započnete obradu “Statusa odobrenja prijave”, prikazuje se popis svih prijava grupiranih prema određenim statusima (stanjima), kao što su: “Pripremljeno”, “Odobreno”, “Odgođeno”, “Usuglašeno”, “Odbijeno”. Radi praktičnosti, možete odabrati "Postavljanje razdoblja" pomoću gumba, na primjer, za dan, tjedan, mjesec, desetljeće, kvartal, polugodište, godinu itd., a zatim, od svih prijava ostat će samo one koje padnu u zadani rok.

Kako biste promijenili status zahtjeva za trošenje sredstava, npr. iz „Pripremljeno” u „Odobreno”, potrebno je koristiti drugu obradu („Status zahtjeva”).

U ovoj obradi možete birati između opći popis aplikacije, na primjer, aplikacije sa statusom „Čeka odobrenje“, „Odgođeno“, „Čeka odobrenje u prethodnim fazama“, „Obrada“ (slika 9).

Obrada prikazuje popis neusklađenih prijava i možete promijeniti status prijave (Sl. 10). Na ovu obradu možete prijeći kroz stavku izbornika “Planiranje” - “Zahtjevi” - “Koordinacija prijava”.

Financijski direktor može “Odobriti” Zahtjev za trošenje sredstava, “Odgoditi” ili “Odbiti”. Kada odaberete “Promijeni status” - “Slažem se”, potvrdni okviri označavaju one aplikacije koje je potrebno odobriti. Preostale prijave koje su bile u redu čekanja možete vidjeti u dnevniku dokumenata „Odobrenje prijava“.

Ukoliko zahtjev nije prošao put odobrenja (status zahtjeva nije “Odobreno”), tada se na temelju njega ne može izdati dokument o plaćanju.

Ako aplikacija počne prolaziti putem odobrenja, tada se aplikacija može promijeniti:

Korisnik čija se prijava trenutno odobrava;

Korisnici koji odobre aplikaciju u višim fazama odobravanja.

Drugi korisnici ne mogu promijeniti aplikaciju.

Ako je aplikacija u stanju “Odobreno”, tada nije dostupna za promjenu (postaje neaktivna za uređivanje), pa polja u aplikaciji postaju siva za knjigovođu nabave i ne mogu se mijenjati.

3. Na temelju odobrenog zahtjeva, računovođa nabave sastavlja blagajnički račun s vrstom transakcije „Plaćanje dobavljaču” bez oznake „Plaćeno” za izdavanje predujma dobavljaču IP Dobronravov (slika 11)

Bilješka, da su u blagajničkom nalogu koji je izradio knjigovođa nabave označeni samo okviri “Ogledaj u upravljačkom računovodstvu” i “Ogledaj u operativnom knjigovodstvu”. Potvrdni okvir “Plaćeno” mora označiti viši blagajnik nakon provjere ispravnosti formiranja naloga za gotovinski račun. Na blagajničkom nalogu također naznačujemo temeljem kojeg zahtjeva ga generiramo.

Ako u blagajničkom nalogu postoje kvadratići samo za poslovodno računovodstvo, tada takav dokument ne generira knjiženja (knjigovodstvene evidencije). Ali on vrši unose u registre akumulacije: „Gotovina za otpis” i „Namirenja s drugim ugovornim stranama” (slika 12). Ove informacije ulaze u izvješće „Kalendar plaćanja” u odjeljku „Neplaćeni izlazni dokumenti” (Slika 13).

4. Stariji blagajnik provjerava blagajnički nalog, označava polje “Plaćeno” i izdaje gotovinu.

Nakon plaćanja naloga za blagajnu, polja u dokumentu postaju siva i ne mogu ih uređivati knjigovođa nabave i ostali sudionici u našem primjeru. Ovisno o tome koja su prava pristupa konfigurirana za pojedinog korisnika, određeni dokumenti, polja u dokumentima itd. mogu biti dostupni za uređivanje.

Bilješka: Ako ima više blagajni i kod svake morate označiti polje “Plaćeno”, možete koristiti grupnu obradu imenika i dokumenata (stavka izbornika “Usluga”). Možete prijeći na ovu obradu odlaskom na puno sučelje, stavku izbornika "Service" (Sl. 14).

Za promjenu pojedinosti kliknite na gumb "Postavke" i odaberite zastavu "Dopusti promjenu pojedinosti objekta". Radi lakše analize, postavimo zastavicu "Prikaži sve stupce" (slika 15).

Grupnom obradom želimo staviti oznaku “Plaćeno” u blagajnički nalog. Da bismo to učinili, u odjeljku "Odabir" grupne obrade označavamo organizaciju StroyTorg LLC; Odabiremo samo obrađene dokumente za razdoblje od 01.01.2013. do 21.01.2013. s opcijom “Plaćeno” - “Ne”.

Klikom na gumb “Odaberi” na kartici “Obrada” pojavit će se dokumenti u kojima je potrebno označiti “Plaćeno” (slika 16). U retku "Akcija" odaberite "Promijeni detalje [Link.Paid] - Instaliraj. I "Trči".

Nakon promjene vrijednosti pojedinosti, potrebno je ponovno knjižiti promijenjene dokumente: u polju „Akcija” odaberite „Promjena: [Knjiži dokumente] – Postavi – „Pokreni” (vidi sliku 17).

5. Računovođa blagajne provjerava nalog za primitak blagajne (označava kućicu za odraz u knjigovodstvenim i porezno knjigovodstvenim evidencijama kako bi se generirale računovodstvene i porezno knjigovodstvene knjižice).

Nadalje, npr. na kraju radnog dana knjigovođa gotovinskog prometa provjerava sve naloge za izdavanje gotovine koji imaju oznaku “Plaćeno” i označava u dokumentu kvadratiće BU i NU tako da dokument generira računovodstvena i porezna knjigovodstvena knjiženja. (Sl. 18)

Bilješka: ako ima puno naloga za isplatu blagajne u kojima treba označiti kućice BU i NU, tada možete koristiti „Grupnu obradu uputnica i dokumenata“ (slika 19).

U grupnoj obradi imenika i dokumenata odabiremo dokumente „Blagajnički izdatni nalog [TC: Dekodiranje plaćanja]“, u čijem tabelarnom dijelu treba označiti kućicu „Prikaži u knjigovodstvu“.

U polju „Odabir“ označavamo za koju organizaciju trebamo odabrati dokumente, označavamo da nas zanimaju samo dokumenti koji su obrađeni za interval od 01.01.2013. do 21.01.2013. potvrdni okvir “Odrazi u računovodstvu” nije označen) računovodstvo"). Nakon popunjavanja svih parametara kliknite gumb “Odaberi”: bit će odabrani dokumenti koji zadovoljavaju navedene uvjete. U donjem dijelu prozora za obradu odaberite “Promijeni atribute” - “Odrazi u računovodstvo" - "Instaliraj" i kliknite gumb "Pokreni". Nakon što su dokumenti obrađeni potrebno ih je ponovno knjižiti (slika 16). Zatim morate ponoviti istu stvar, ali označiti kućicu “Prikaži u poreznom knjigovodstvu”

Kod knjiženja dokumenta „Blagajnički izdatni nalog“ ne generiraju se samo kretanja na knjigovodstvenim kontima, već i u registrima (sl. 20, 21)