Operativno načrtovanje denarnega toka ali kako zgraditi sistem nadzora denarnega toka. Podsistem "elektronske prijave" za porabo sredstev Aplikacija za porabo sredstev 1c upp

1. Uvod

Načrtovanje denarnih sredstev je ena glavnih nalog poslovodnega računovodstva v nasprotju s finančnim računovodstvom.

Seveda obstajajo tudi druge bistvene razlike med vodenjem in računovodstvom (drugačne zahteve po analitiki, po ocenjevanju in prevrednotenju sredstev/obveznosti, potreba po oblikovanju rezerv ipd.), a reševanje načrtovalskih problemov je najtežje. njim.
Kompleksnost načrtovanja ni le v pripravi načrta (izračunu, oblikovanju po različnih scenarijih), ampak je potrebno tudi:

Izvedite prerazporeditev;
Posodabljanje načrtov, prenos popravkov v naslednja obdobja;
Izvedite načrt – analizo dejstev.

Treba je priznati, da se v večini podjetij (z uporabo 1C za avtomatizacijo) načrtovanje ne izvaja v programu.
"Morali bi vzpostaviti računovodstvo ..." - tako mnogi trdijo.

Računovodstvo je treba izboljšati, ja, a ne na račun načrtovanja.
Seveda še vedno načrtujejo (vendar ne v 1C, ampak v XLS). In prva, glavna naloga (ki jo poskušajo rešiti) je načrtovanje gotovine.

(1) strateško (proračun);
(2) Operativno.

In če je proračun (seveda s pristopom k načrtovanju od zgoraj navzdol) mogoče izvesti z uporabo XLS, potem operativnega načrtovanja ni mogoče izvesti.
Bistvo je, da najpogosteje najmanj uporabnikov (1-2 osebi) dela s proračunskimi tabelami. Za večino podjetij število proračunskih postavk in druge analitike ni tako veliko. To pomeni, da je vse mogoče obdelati ročno v XLS.

Kar pa se tiče operativnega načrtovanja d/s, je tukaj situacija drugačna. To pomeni, da je pogosto treba plačati veliko število računov, veliko rednih plačil, pričakovanih plačil za naročila strank itd.

Poleg tega je vse to mogoče "povezati" z velikim številom primarnih dokumentov, s katerimi delajo različni uporabniki programa, dokumenti se prilagajajo, spreminja stanje itd.

Druga pomembna razlika med operativnim načrtovanjem in proračunom je, da pogosto prihaja od spodaj navzgor. To je iz “Zahtevkov za stroške d/s”, ki jih vedno izpolnijo zaposleni v oddelku.

In te vloge je zato treba pravočasno obdelati, sprejeti/zavrniti, "razporediti" in plačati.

Skupaj: operativno načrtovanje za d/s je prva načrtovalska naloga, ki bi moral biti avtomatiziran v 1C za vsako podjetje.

In kot rezultat načrtovanja bi morala finančna služba / zakladnica v sistemu "videti":

Kdaj, komu, iz katerega bančnega računa/gotovine, za kakšen znesek je treba plačati;
Kakšno bo stanje denarnih sredstev na "ta in ta" datum ob upoštevanju tekočih stanj, načrtovanih odhodkov in denarnih prejemkov. Izogibati se je treba t.i. "denarne vrzeli"
To pomeni, da je treba delati s plačilnim koledarjem.
Na kakšen dolg pri nasprotnih strankah bo določene datume, ob upoštevanju načrtovanih vplačil, prejemkov in trenutnega stanja medsebojnih obračunov.
To pomeni, da je treba delati s koledarjem za izračun.

Namen tega članka – pogovor o možnostih avtomatizacije obratovalnega načrtovanja za d/k. Hkrati bo izvedena primerjalna analiza 3 različnih konfiguracij kroženja (dve sta standardni iz 1C, ena je specializirana iz podjetja Wiseadvice).

Vsako od konfiguracij je mogoče uporabiti za reševanje težav pri operativnem načrtovanju, vendar je treba izbrati uravnoteženo glede na obseg in obseg vašega projekta.

2. Lastnosti mehkega zaganjalnika 1.3

Trenutno 1C še ni izdal dolgo pričakovane nove izdaje UPP (revizija 2). In iz tega razloga se bomo osredotočili na to, kar je na voljo - ustrezne podsisteme SCP 1.3:

Treba je opozoriti, da je bil podsistem "Zahtevki za porabo gotovine" posodobljen v konfiguraciji relativno nedavno (2011). Posledično se je v načinu upravljanega vmesnika na plošči razdelka pojavila postavka »Zahtevki za porabo d/s/«.

Če poskušate v standardni konfiguraciji v datotečnem načinu odpreti obrazec dokumenta »Zahtevek za stroške D/s« (tudi ZRDS), se takoj pojavi napaka za spremenljivko »Globalne vrednosti« iz splošnega modula »Delo z Splošne spremenljivke”.

Takšne napake pa je mogoče popraviti, kot pravijo: »usedlina ostane«. Se pravi, da je v podsistemu UPP ZRDS dovolj »hrapavosti«.
Možnost sestave dokumenta ZRDS prek SPLETNEGA brskalnika je sicer koristna, a v praksi boste morali dobro premisliti o poenostavitvi in ergonomiji standardne oblike dokumenta. To bo še posebej pomembno za mobilne naprave.

Kar pa se tiče plačilnega koledarja, v načinu tankega odjemalca, na daljavo prek spletnega brskalnika itd. ne boste ga mogli uporabljati. Razlog je v tem, da podsistem Cash Management že dolgo ni bil posodobljen in še posebej poročilo Plačilni koledar ni zgrajeno na sistemu za sestavo podatkov. Zato tega poročila ni mogoče uporabiti v lahkih odjemalcih; zanj ni mogoče ustvariti nastavitev po meri.

Pri delu z ZRDS pomembno mesto zavzema pravilnik za usklajevanje in potrjevanje vlog. Odvisno od organizacijska struktura podjetniških in drugih značilnostih poslovanja, je interni postopek odobritve vlog (homologacijski pravilnik) lahko precej zapleten (večstopenjski, variabilen itd.). To torej ni lahka naloga za avtomatizacijo.

V UPP je implementiran podsistem usklajevanja in soglasja. Omogoča precej prilagodljive nastavitve.

Odobritev je potrditev potrebe po plačilu vloge. Običajno mora odobritev iti prek vodij oddelkov, menedžerjev in drugih odgovornih oseb podjetja.
Odobritev je končna potrditev (blagajnika), da bo vloga plačana. V tem primeru je treba določiti datum plačila in bančni račun/blagajno, s katerega bo izvedeno plačilo. Tako plačilo sodi v operativni plan (plačilni koledar).

Opozoriti je treba, da številni vidiki standardne funkcionalnosti mehkega zaganjalnika ne zagotavljajo tistega, kar je potrebno za dejansko izvedbo podsistema.
O teh "trenutkih" bom pisal pozneje, zdaj pa poglejmo, kakšne funkcije ponuja tipična konfiguracija.

Uporabo mehanizma za odobritev aplikacij lahko omogočite ločeno za vsako organizacijo.

Možno je konfigurirati zaporedje aplikacije skozi poti in hierarhijo poti.

Opozoriti je treba, da hierarhija v imeniku oddelkov ni upoštevana v mehanizmih usmerjanja aplikacij.
Prav tako je treba preklicati, da sta bila usklajevanje in odobritev tehnično izdelana brez uporabe mehanizma poslovnih procesov.

Na vsaki točki lahko določite enega/več uporabnikov, za katere bo na voljo odobritev aplikacije. Se pravi, da lahko vlogo odobri katerikoli od njih (tisti, ki to prej uspe).

Za vsak oddelek lahko dodelite ustrezno točko odobritvene poti. Bistvo tega je naslednje: pri izpolnjevanju vloge (ZRDS) je treba navesti osrednje zvezno okrožje (oddelek). In odvisno od navedenega oddelka UPP »poišče« ustrezno točko odobritve in na to točko »pošlje« vlogo za odobritev.

Možno je tudi, da pri nastavitvi poti odobritve ne določite oddelka. V tem primeru bo taka koordinacijska točka "uporabljena" za vse CFD-je, za katere ustrezna točka poti ni posebej navedena.

Sama odobritev se izvede s posebno obdelavo “Odobritev aplikacije”

Analiza načrtovane razpoložljivosti sredstev, plan plačil in sledenje denarnih vrzeli se izvaja v poročilu »Plačilni koledar«.

Poleg planirane porabe d/s (ZRDS) lahko upoštevate tudi načrtovani prejem d/s. Za te namene je predvideno, da se pripravi poseben dokument "Načrtovani prejem dohodka".

Treba je opozoriti, da čeprav ima dokument »Planirani prejem d/c« stanja (pripravljeno, dogovorjeno ipd.), ni možnosti usklajevanja tega dokumenta (kot tudi ZRDS). To pomeni, da je spreminjanje statusov dokumentov možno samo v » ročno upravljanje».

In v UPP je mogoče upoštevati načrtovani prejem gotovine od kupcev brez priprave dokumentov "Načrtovani prejem gotovine".

To pomeni, da če so za kupca izdana »Naročila strank«, potem je ta načrtovani prejem viden v ločenem poročilu »Plačilni koledar ob upoštevanju naročil«.

Poleg poročila Plačilni koledar je na voljo poročilo Analiza razpoložljivosti denarja.

Hkrati je možno rezervirati d/s (na podlagi vlog za stroške) ali vložiti vloge na načrtovane prihodke.

Na voljo je tudi funkcionalnost zapiranja ZRDS in planiranih prihodkov iz d/s. Za te namene so v načinu »navadna stranka« na voljo dokumenti »Zapiranje vlog za izdatke/prejemke«.

Vendar pa ta funkcija ni podprta tudi v načinu tankega/spletnega odjemalca.
Pri tem morate razumeti, da je tehnika »trde rezervacije« močno vezana na kronologijo vnosa dokumenta, kar otežuje prilagoditve in prerazporejanje.

Zato je funkcionalnost ostala v UPP bolj kot »dediščina preteklosti«, za analizo razpoložljivosti d/s pa je treba uporabiti plačilni koledar.

Tako smo razmislili o funkcionalnosti mehkega zaganjalnika in zdaj bom naštel tiste vidike standardne konfiguracije, ki jih je v praksi, na projektih, treba spremeniti:

Glede na dokument "Vloga za izdatke d/s":
1. V dokumentu lahko označite »Divizijo« (mimogrede, v konfiguraciji je označena kot Centralno zvezno okrožje - središče finančne odgovornosti). Povsem možno pa je, da je vloga oddana iz ene divizije (CFD) in v tem primeru bo treba stroške pripisati/razdeliti drugi diviziji (CFD - centri za finančno upravljanje).
  Sposobnost določanja digitalnih funkcij itd. - odsoten.
  Ni možnosti spreminjanja poti ali preusmeritve aplikacije na druge poti.

Ni možnosti načrtovanja prenosa gotovine med TRR, z računa na blagajno ipd.

Postopek dogovora:
1. Usklajevanje ZRDS je možno, ni pa možnosti usklajevanja planskega prejema d/s.
2. V praksi postane potrebno izvajati soglasja za druge zaposlene. Hkrati mora sistem beležiti tudi podatke o tem, »kdo je odobril in za koga«.
  Možnost namestitve več možnih izvajalcev na eno koordinacijsko točko pogosto ni primerna, zato se lahko ta izvajalec navede na drugih stopnjah koordinacije. Posledično bo vse to privedlo do dejstva, da bo imel zaposleni hkrati glavne in posredne naloge odobritve na seznamu zahtevkov za odobritev. Seveda to uporabnika zmede in ni priročno.
  Če povzamem, možnost koordinacije za drugega izvajalca, možnost navedbe, kdo ima za koga pravico koordinacije, odsotna.
3. V procesu odobritve vlog, ko se vloga posreduje v odobritev naslednjemu na poti, je povprašena funkcionalnost avtomatskega obveščanja (po e-pošti) naslednjega izvajalca, pa tudi avtorja vloge. .
4. Če je avtor aplikacije že odgovoren za usklajevanje/odobritev (na kateri koli stopnji poti!), potem je povsem logično, da program samodejno »skrajša« pot in aplikacijo preusmeri na najvišjo razpoložljivo raven. Tega pa UPP ne predvideva.
- Vse zgornje zahteve, čeprav niso vključene v standardno konfiguracijo, so vseeno.

Poročila, pravice dostopa.
1. Zahteva se možnost omejitve dostopa do prijav le razpoložljivim avtorjem/izvajalcem (koordinatorjem); po oddelkih, ki so na voljo uporabniku.
2. Ni poročanja o kontroli (po dnevih in intervalih) dejanskega in načrtovanega dolga. To velja tako za kupce kot za dobavitelje.
3. Poročanje in nekatere funkcionalnosti niso primerne za delo v načinu tankega/spletnega odjemalca.
Računovodstvo rednih dogovorov in pogodb.
1. Pogosto so situacije, ko je treba redno plačevati dobavitelje. Na primer plačilo najemnine itd.
  UPP tega ne odraža samodejno v plačilnem koledarju itd. te prihajajoče stroške. To pomeni, da je treba takim plačilom ročno slediti in izpolnjevati zahtevke za plačilo, kar je neprijetno in delovno intenzivno.
2. V dogovorih s kupci in dobavitelji se lahko določijo pogoji glede odstotka avansa, plačilnih pogojev itd.
  UPP ne beleži samodejno vseh teh informacij in jih (posledično) samodejno odraža v plačilnem koledarju.

3. Značilnosti UT 11.1

Z izdajo nove konfiguracije »Trade Management Rev.11« se je pojavilo veliko novih, uporabnih funkcij za naloge operativnega načrtovanja in finančnega nadzora.
Morda najbolj pomembna stvar v tem delu v UT11 (v primerjavi z UPP 1.3) je mehanizem obračunavanja plačilnega plana. Ta mehanizem »zapira« tisto, kar je zelo primanjkovalo – avtomatizacijo planiranja/računovodstva po rednih pogodbah in pogodbah.

Tako vam v UT11 sploh ni treba sestavljati dokumentov (če seveda ni potrebe) za načrtovanje stroškov in prejemkov, hkrati pa bo plačilni koledar oblikovan normalno.

Lahko prekličete, da »standardne nastavitve« poročila »Plačilni koledar« res ne izpolnjujejo pričakovanj (kot tak koledar ni prikazan), lahko pa v uporabniškem načinu dodate grupiranje po »datumu plačila« in poročilo bo ustvarjen v običajni obliki.

Funkcionalnost poročila se je močno razširila (v primerjavi s SCP 1.3) zaradi uporabe sistema za sestavljanje podatkov. Zdaj je mogoče poročilo ustvariti v tankem/spletnem odjemalcu, ga shraniti v bazo podatkov in različnim uporabnikom dodeliti nastavitve, ki jih potrebujejo.

Poleg načrtovanja porabe in prevzema gospodinjskih dobrin ima UT11 sedaj še funkcionalnost načrtovanja gibanja gospodinjskih dobrin. Za te namene lahko sestavite dokumente "Nalog za premestitev gospodinjstev."

V primerjavi z UPP 1.3 za dokument »Vloga za porabo blagajne« se je povečalo število obravnavanih vrst poslovnih transakcij:

Zdaj je mogoče odobriti tako dokumente "Vloga za porabo sredstev" kot druge naloge:

Za analizo dolga po intervalih/rokih je na voljo poročilo »Terjatve«. Po potrebi lahko ustvarite tudi koledar dolgov. Če želite to narediti, morate v načinu po meri dodati razvrščanje po datumih plačil.

Žal UT11 (kot prej) ne omogoča analize koledarja dolgov po dobaviteljih. Vendar je treba za to nalogo dokončati UT11.

Povzeti: nove metodološke rešitve »1C« skupaj z zmogljivostmi platforme 8.2 predstavljajo dobro osnovo za avtomatizacijo nalog operativnega načrtovanja in vodenja d/c.

Toda hkrati morate razumeti, da konfiguracija UT11 ni popolna, že pripravljena rešitev za avtomatizacijo zakladništva in finančnega planiranja.

Prvič, UT11 v zelo poenostavljeni obliki implementira mehanizem za usklajevanje/odobritev zahtevkov za izdatke in druge dokumente načrtovanja d/c. To pomeni, da ni mehanizmov usmerjanja, postopek odobritve vlog je zmanjšan na preprosto nastavitev statusov.
Drugič, UT11 nima proračunskega podsistema in (posledično) ni funkcionalnosti za spremljanje aplikacij za načrtovane proračune.

4. Lastnosti WA: Finančnik

V preteklosti je bila konfiguracija WA:Financier razvita na podlagi izdelka Treasury Management.

Hkrati pa nova rešitev "Financier" podjetja WiseAdvice vključuje tudi:

Podsistem za načrtovanje proračuna;
Podsistem za upravljanje pogodb;
Podsistem za oblikovanje in obračun dejanskih plačil;
Prilagodljiv, prilagodljiv mehanizem za generiranje/izpolnjevanje dokumentov na podlagi predlog;
Fleksibilen, prilagodljiv integracijski podsistem odjemalec-banka.

Razmislimo o glavni funkcionalnosti "WA: Finančnik" v smislu zakladnice - od upoštevanja pogojev pogodb do ustvarjanja plačilnega koledarja.

Med postopkom odobritve vloge ne morete le potrditi/zavrniti dokumenta (kot je to storjeno v UPP), ampak so na voljo tudi druge funkcije: na primer poslati dokument v revizijo ali zahtevati dodatne informacije. informacije.
Celoten proces je avtomatiziran, zato je zagotovljeno poročanje o statusu obdelave odobritve dokumentov.

5. Rezultati

Sklepi:

Za avtomatizacijo dela finančnih služb, zakladnic, organizacij s kompleksno organizacijsko strukturo. struktura je najprimernejša rešitev "WA: finančnik".
Ta rešitev se je razvijala in razvijala dolgo časa ter skladno s tem kopičila posebnosti in zahteve različnih finančnih institucij. oddelki in zakladnice. Skupni stroški dela za razvoj rešitve so znašali več kot 5000 oseb/ur.
Prednost rešitve WA:Financier je napredna funkcionalnost in veliko število mehanizmov programskih nastavitev. Tako je izvedba te rešitve mogoča v kratek čas(t.i. “out-of-the-box implementacija”), brez dodatnih. razvoj, programiranje itd.
Ker rešitev vsebuje mehanizme za dvosmerno izmenjavo z vsemi glavnimi standardnimi konfiguracijami, integracija v obstoječo strukturo (izmenjava podatkov z bazami podatkov UT, UPP, Kompleksnaya, Bukh) ne bo težavna.
Avtomatizirati finančno službo/zakladnico v okviru celovitega projekta avtomatizacije najboljša rešitev je na podlagi UPP.
Hkrati morate razumeti, da bo funkcionalnost mehkega zaganjalnika zahtevala izboljšave.
Posebnosti, finančne zahteve. oddelki in zakladnice niso vpeti v UPP tako globoko, kot je to storjeno v ločenih, specializiranih rešitvah.
Zato je treba implementacijo SCP za te naloge izvajati le kot del projekta avtomatizacije.
Za velike organizacije, za avtomatizacijo zakladniškega oddelka UT11 ne ustreza.
Prvič, v tej odločbi ni mehanizmov za usklajevanje/potrjevanje planskih dokumentov.
Drugič, ni proračunskega podsistema in nadzora nad izvajanjem proračunov med operativnim načrtovanjem.
Vendar UT11 kot nalašč za avtomatizacija (vključno z operativnim načrtovanjem d/c) majhne finančne oddelki podjetja.

Dokument »Zahtevek za porabo sredstev« je namenjen načrtovanju in usklajevanju izplačil.
Dokument »Zahtevek za porabo DS« lahko ustvarite tako, da greste v razdelek »Blagajna« - »Načrtovanje in nadzor sredstev« - »Zahtevki za porabo DS« - Ustvari.
Dokument »Zahtevek za izdatke DS« ima več tipov operacij, ki se izberejo med kreiranjem. Vsaka vrsta aplikacije je namenjena odražanju različnih poslovnih transakcij, od katerih bo vsaka opisana v tem navodilu.
Oblikovani dokumenti »Vloga za porabo DS« se zbirajo in usklajujejo z dokumentom »Register plačil«. Po odobritvi se na podlagi vlog samodejno kreirajo dokumenti »Odpis negotovinskega DS«, ki se naložijo v banko stranke za plačilo s strani banke.
Sledijo primeri izvedbe dokumentov "Vloga za izdatke DS" za vsako vrsto operacije.

Plačilo dobavitelju
Za obdelavo plačilnih transakcij dobavitelju je namenjen tip transakcije dokumenta »Zahtevek za izdatek DS« - »Plačilo dobavitelju«.
V novem dokumentu »Vloga za porabo DS« so z rdečo barvo označena polja, ki jih je treba izpolniti za obdelavo dokumenta. Dokument se ustvari v statusu »Neodobren«, status se samodejno spremeni med odobritvijo registra plačil. Prioriteta aplikacije ob ustvarjanju je samodejno nastavljena na »Srednja«.

Slika 1. Obrazec dokumenta »Vloga za izdatke DS«, vrsta operacije »Plačilo dobavitelju« (ne izpolnjeno)
Podatke dokumenta »Vloga za porabo DS« je treba izpolniti na naslednji način:
Osnovni zavihek
številka– se ustvari samodejno med izvajanjem, ni ga mogoče nastaviti ročno.
datum– ko je ustvarjen, je nastavljen trenutni datum.
Organizacija– s predlaganim seznamom organizacij morate izbrati z gumbom ali z vnosom imena v polje, se vam bo ponudila želena vrednost v izbor.
Podrazdelitev– v imeniku »Struktura podjetja« morate izbrati oddelek, za katerega naj se izvede plačilo.
Prijavitelj– privzeto je prikazan trenutni sistemski uporabnik, ki ustvarja aplikacijo.
Načrtovanje– privzeta nastavitev je »V valuti plačila« in je ni mogoče spremeniti.
vsota– označuje znesek zahtevanega plačila.
Valuta– navedite valuto zahtevanega plačila.
Delovanje– odraža se vrsta transakcije dokumenta »Vloga za izdatke DS«, ki je bila izbrana med ustvarjanjem
dan plačila– označuje datum, na katerega mora biti predvideno plačilo dobavitelju.
Način plačila– privzeta nastavitev je »V poljubni obliki« in je ni mogoče spremeniti.
Prejemnik– označuje dobavitelja iz imenika »Nasprotne stranke«, kateremu je treba izvršiti plačilo.
Račun prejemnika– pri izbiri »Prejemnik« se samodejno nastavi račun prejemnika, če je potrebno, če je na »Računu za plačilo« s strani dobavitelja naveden drug račun, morate želenega izbrati v imeniku »Bančni računi«.
Preko meje– če sistem vzdržuje sistem omejevanja denarnih izdatkov v okviru poslovalnic oziroma postavk denarnega toka, če znesek opravljenega plačila predhodno ni bil vključen v limit, bo ob knjiženju dokumenta uporabnik prejel sporočilo o napaki. in prijava ne bo obravnavana.

Slika 2. Primer napake pri oddaji naročila, za katerega ni bil predviden limit.
Če želite oddati naročilo nad omejitvijo, morate nastaviti zastavico »Over Limit«.
Prenos v proračun– ta zastavica je nastavljena, če je plačilo nakazilo v proračun. Nastavitev zastavice vam omogoča vnos vrednosti KBK, OKTMO itd., ki so potrebne za plačila v proračun.

Slika 3. Primer nastavitve oznake »Prenos v proračun«.
UIP– edinstven identifikator plačila, naveden le, če je to predvideno v pogodbi s prejemnikom plačila.
Namen plačila- program ponuja več možnosti za samodejno izpolnjevanje namena plačila s pomočjo gumba "Vstavi".

Slika 4. Možnosti za samodejno izpolnjevanje polja »Namen plačila«.
Seznam dokumentov, vklj. DDV- prikaže informacije o objektih poravnave iz zavihka »dešifriranje plačil«.

Vključuje DDV (18%) (za celoten znesek), vklj. DDV (10%) (za celoten znesek), Brez davka (DDV)- Podatki o DDV bodo dodani vnesenemu besedilu.

Besedilo z bančnega računa prejemnika- vstavi besedilo, ki je navedeno v polju "Besedilo namena plačila" iz kartice računa nasprotne stranke.

Slika 5. Primer izpolnjevanja zavihka »Osnovno«.

Zavihek Podrobnosti plačila
Zavihek »Dekodiranje plačila« vsebuje podrobne informacije o plačilu in medsebojnih obračunih s prejemnikom plačila.
Plačilo lahko vnesete kot seznam, t.j. porazdeliti na več objektov obračuna ali brez razdelitve, možno je izbrati le en objekt obračuna.
Plačilo iz državnih obrambnih sredstev– zastavica je nastavljena le, če se plačilo izvede v okviru naročila obrambne vlade, v drugih primerih zastavica ni nastavljena.
Predmet izračuna– kot objekt poravnave lahko določite »Pogodba z nasprotno stranko« (za ta tip operacije prijavnega dokumenta so ob izbiri na voljo pogodbe s tipom razmerja »Z dobaviteljem/izvajalcem«) ali dogovorjeni dokument »Naročilo« dobavitelju«.
Ponudnik
Znesek medsebojnih obračunov– se samodejno nastavi ob knjiženju dokumenta.
Valuta– se samodejno nastavi ob izbiri predmeta izračuna.
članek DDS– označite postavko denarnega toka, ki ustreza vrsti plačila.
Komentar– po potrebi navedite komentar k dešifriranju plačila.

Slika 6. Primer izpolnjevanja zavihka »Dekodiranje plačil«.
Zavihek Porazdelitev računa
Na zavihku »Razporeditev na račune« je naveden bančni račun organizacije, s katerega je treba bremeniti sredstva. Znesek in datum plačila se nastavita samodejno glede na podatke, navedene v zavihku »Osnovno«.

Slika 7. Primer izpolnjevanja zavihka »Razporeditev po kontih«.

Slika 8. Primer avtomatsko izdelanega dokumenta »Odpis negotovinskega DS« za aplikacijo s tipom posla »Plačilo dobavitelju«.

Vračilo plačila stranki
Za obdelavo transakcij vračil strankam je namenjena vrsta transakcije v dokumentu »Vloga za porabo DS« - »Vračilo plačila stranki«.
Sestava podrobnosti dokumenta »Vloga za izdatke DS« pri tej vrsti operacije je enaka sestavi podrobnosti pri plačilu dobavitelju, razlika je le v vrsti nasprotne stranke in predmetu poravnave.

Slika 9. Obrazec dokumenta »Vloga za porabo DS«, vrsta operacije »Vračilo plačila stranki«
Prejemnik– označuje stranko iz imenika »Nasprotne stranke«, ki mora izvesti plačilo.
Predmet izračuna– kot objekt poravnave lahko navedete »Pogodba z nasprotno stranko« (za to vrsto operacije prijavnega dokumenta so pri izbiri na voljo pogodbe s tipom razmerja »S kupcem/stranko«) ali dogovorjeni dokument » Naročilo stranke«.
Kupec– polje se avtomatsko izpolni ob izbiri predmeta izračuna. Nameščen je element imenika »Partnerji«, določen v ustreznem polju predmeta izračuna.

Slika 10. Primer izpolnjevanja zavihka »Dekodiranje plačil«.
Po opravljenih vseh fazah odobritve bo dokumentu »Vloga za porabo DS« dodeljen status »Za plačilo« in samodejno ustvarjen dokument »Odpis negotovinskega DS«.

Slika 11. Primer samodejno ustvarjenega dokumenta »Odpis negotovinskega DS« na podlagi aplikacije z vrsto operacije »Vračilo plačila stranki«.

Izdaja odgovornemu
Za registracijo transakcij za izdajo sredstev na bančni račun odgovorne osebe je namenjena vrsta transakcije dokumenta "Vloga za porabo DS" - "Izdaja odgovorni osebi".

Slika 12. Obrazec dokumenta »Vloga za porabo DS«, vrsta operacije »Izdaja odgovornemu«
Odgovorna oseba– zaposleni je naveden iz imenika “ Posamezniki”, komu je treba nakazati denar.
Poročilo– iz predlaganega seznama obdobij je treba navesti obdobje, do katerega mora računovodja poročati o prejetem znesku.

Slika 13. Primer izpolnjevanja zavihka »Dekodiranje plačil«.
Po opravljenih vseh fazah odobritve bo dokumentu »Vloga za porabo DS« dodeljen status »Za plačilo« in samodejno ustvarjen dokument »Odpis negotovinskega DS«.

Slika 14. Primer samodejno ustvarjenega dokumenta »Odpis negotovinskega DS« na podlagi aplikacije z vrsto operacije »Izdaja odgovornemu«.

Pomemben pogoj za učinkovit obstoj podjetja v sodobnem konkurenčnem okolju je oblikovanje učinkovitega mehanizma upravljanja denarni tokovi zagotavljanje generiranja ažurnih in zanesljivih informacij, ureditev medsebojnih obračunov, povečanje plačilne discipline in nenazadnje pospeševanje gotovinskega prometa.

Konfiguracija vsebuje orodja za avtomatizirano upravljanje gotovine podjetja, ki opravlja dve glavni funkciji:

operativno računovodstvo dejanskega gibanja sredstev podjetja na poravnalnih računih in blagajnah;
operativno načrtovanje denarnih prejemkov in izdatkov podjetja.

Splošno načrtovanje izdatkov in prejemkov sredstev podjetja se izvaja v okviru proračuna. Finančni načrt, ki je v pripravi - proračun, deluje kot niz smernic in omejitev za podsistem upravljanja z denarnimi sredstvi.

Toda v okviru funkcionalnosti upravljanja z gotovino se vzdržuje operativni finančni načrt - plačilni koledar. Plačilni koledar je smiselno narediti več dni vnaprej.

Plačilni koledar je zbirka zahtevkov za porabo sredstev in načrtovanih denarnih prejemkov. Plačilni koledar je sestavljen s podrobnostmi do krajev, kjer so shranjena sredstva - bančni računi in blagajne podjetja. Pri sestavljanju plačilnega koledarja se samodejno preveri njegova izvedljivost - zadostnost denarnih rezerv na mestih, kjer so shranjene.

Delitev funkcije finančnega načrtovanja na dva konfiguracijska podsistema - podsistem proračuna in podsistem upravljanja z gotovino - ustreza delitvi funkcij finančnega upravljanja med različnimi oddelki in zaposlenimi v podjetju. Če proračun sestavijo finančne službe, potem zahteve za porabo sredstev ustvarijo zaposleni in oddelki, ki neposredno sodelujejo z nasprotnimi strankami podjetja.

V konfiguraciji se generirajo denarni dokumenti (plačilni nalogi, blagajniški prejemki in bremenitveni nalogi itd.), zagotavlja interakcija s specializiranimi bančnimi programi, kot je »Banka Client«, nadzorujejo se finančni tokovi in razpoložljivost sredstev v skladiščih. spremljati. Zagotovljena je možnost gotovinskega plačila v tuji valuti.

Dokument »Zahtevek za porabo sredstev« je namenjen evidentiranju odločitve o gotovinskem ali negotovinskem plačilu (skupina plačil) ali premiku sredstev. Podatki o dokumentih in postopek njihove uporabe so v osnovi podobni dokumentom »Plačilni nalog (izhodni)« in »Blagajniški nalog«.

Parametri rezervacije in postavitve se lahko samodejno izpolnijo. V ta namen dokument določa zastavice in "Samodejna umestitev".

Če so te zastavice nastavljene, se lahko stolpec »Umestitev« samodejno izpolni, ko kliknete gumb "Izpolni in objavi".

Avtomatsko in ročno shemo postavitve je mogoče kombinirati. Ko so zastave postavljene "Samodejna rezervacija" in "Samodejna umestitev" Za del zneska vloge lahko ročno določite možnost umestitve. Potem, ko pritisnete gumb "Izpolni in objavi" Samo za preostali znesek bo izvedena samodejna postavitev.

Ko je vrsta operacije nastavljena na " Plačilo dobavitelju" ali " Vračilo kupcu" se spremenijo operativne poravnave z nasprotnimi strankami.

Na podlagi dokumenta »Vloga za porabo sredstev« se lahko vnesejo bančni in gotovinski plačilni dokumenti. Takšni dokumenti zagotavljajo zahtevano " aplikacija", ki se izpolni med tipkanjem na podlagi tega ali pa se izpolni ročno. Pri knjiženju plačilnih dokumentov z določeno vlogo za porabo sredstev se preverja skladnost zneska dokumenta s trenutnim stanjem neporavnanih plačil za to aplikacijo.

Pri nastavitvi dodatnih pravic je možno uporabniku prepovedati obdelavo plačilnih dokumentov brez navedbe vloge za porabo sredstev.

Dokument »Zahtevek za porabo sredstev« lahko služi tudi kot povezava med podsistemom za upravljanje blagajne in podsistemom za proračun. V ta namen aplikacija ponuja blok podrobnosti, podoben dokumentu »Proračunsko poslovanje« (scenarij načrtovanja, postavka prometa, centralno finančno okrožje, projekt itd.). Z navedenimi podatki se ob oddaji vloge spremlja skladnost skupnega obsega odobrenih sredstev za porabo s predhodno določenimi mejnimi vrednostmi.

Značilnosti dela z aplikacijami pri uporabi mehanizma za odobritev aplikacij

Mehanizem za odobritev vlog se uporablja izbirno: za seznam organizacij.

Pri uporabi mehanizma ujemanja aplikacij se pojavijo naslednje funkcije:

Če v vlogi ni navedena organizacija, ta vloga ne sodeluje pri odobritvi

Pot odobritve vloge se določi v skladu z nastavitvami glede na Divizijo, navedeno v vlogi.

Če vloga ni prestala odobritvene poti (status vloge ni »Odobrena«), na njeni podlagi ni mogoče izdati plačilnega dokumenta.

Če aplikacija začne iti skozi pot odobritve, jo je mogoče spremeniti

Uporabnik, katerega prijava je trenutno v odobritvi

Uporabniki, ki odobrijo aplikacijo na višjih stopnjah odobritve
Drugi uporabniki ne morejo spremeniti aplikacije.

Če je naročilo v stanju "Odobreno", ga ni mogoče spremeniti

Če aplikacija preide v stanje »Zavrnjeno«, je prijava preklicana

Trenutno stanje prijav je na seznamu prijav

stanje je prikazano v ločenem stolpcu

Uporablja se razvrščanje po statusu naročila

aplikacije so označene z barvo ozadja
- zavrnjen - roza

V drugem delu članka bomo obravnavali načelo ustvarjanja »Zahtevkov za porabo sredstev«, posredovanja po poti odobritve in izdaje sredstev glede na ustvarjeno aplikacijo.
Poglejmo primer:

Nabavni računovodja oblikuje zahtevek za porabo sredstev za predplačilo dobavitelju IP Dobronravov za dobavo materiala;
Finančni direktor mora vlogo pregledati in odobriti;
Na podlagi odobrene vloge računovodja nabave izdela blagajniški nalog (brez oznake »Plačano«, vendar z oznako »Odražaj v operativnem knjigovodstvu«);
Višji blagajnik po pregledu blagajniškega naloga izda sredstva (in dokument označi kot »Plačano«);
Računovodja blagajniškega prometa preveri blagajniški nalog (označi polje za odraz v računovodskih in davčnih knjigovodskih evidencah, da se ustvarijo računovodske in davčne knjigovodske knjižbe).

Za lažji prikaz transakcij preklopimo vmesnik na »Upravljanje gotovine«.
Preden začnete delati z vlogami za porabo sredstev, morate vnesti vse osnovne informacije. Prva stvar, ki jo morate izpolniti, je register informacij "Nastavitve za odobritev vlog za porabo sredstev." V razdelku »Nastavitev odobritve vlog« so navedene organizacije, za katere se uporablja ta mehanizem, in datum začetka uporabe mehanizma odobritve. Ta nastavitev je potrebna, da lahko program določi, da bo organizacija StroyTorg LLC uporabljala mehanizem za odobritev zahtevkov za porabo sredstev od 01.01.2013.

Prav tako je treba konfigurirati koordinacijske poti (slika 2). Ta nastavitev je navedena v registru informacij "Nastavitve za začetek odobritvenih poti": določena je ujemanje odobritvenih poti z oddelki. Pot odobritve (imenik »Poti odobritve«) označuje stopnjo in seznam odobritvenih oseb na tej stopnji. V našem primeru bo morala izdelana aplikacija najprej skozi eno fazo potrditve finančnega direktorja.

Vzpostaviti morate tudi informacijski register »Vzpostavitev odobritve vlog za porabo sredstev« (slika 1) in določiti faze (traso) odobritve vlog (slika 2).

riž. 1

riž. 2

Koordinacijska pot Aplikacija se določi v skladu z nastavitvami in glede na oddelek, ki je naveden v aplikaciji.

Opomba da mora ena divizija ustrezati le eni koordinacijski poti. Za vsak oddelek je treba določiti pot odobritve, sicer postopek odobritve za vse aplikacije, ustvarjene za ta oddelek, ne bo veljal.

1. Nabavni računovodja oblikuje dokument »Zahtevek za porabo sredstev«.

V vmesniku »Upravljanje gotovine«, ki smo ga izbrali, pojdite na točko menija »Načrtovanje« - »Zahteve« - »Zahteva za porabo sredstev« (slika 3). Izdelajmo “Vlogo za porabo sredstev” s statusom tipa “Pripravljeno” (slika 5)

Aplikacija ima več tipov operacij, ki ponavljajo tipe operacij “Gotovinski nalog” in “Izhodni nalog” (slika 4).

V "Zahtevku za porabo sredstev" na zavihku "Poravnave z nasprotnimi strankami" so navedeni osnovni podatki: nasprotna stranka za plačilo, ki ji je treba izdati sredstva, ter pogodba, znesek, organizacija, delitev in status.

Na zavihku »Opis« lahko določite Dodatne informacije v katerikoli obliki.

Zavihek »Dodelitev« omogoča možnost rezervacije in polaganja sredstev (slika 6). To pomeni, da lahko v našem primeru nabavni računovodja rezervira sredstva za plačilo avansa dobavitelju in navede, iz katere blagajne bodo sredstva izdana. Parametri rezervacije in postavitve se lahko samodejno izpolnijo. Za ta namen v dokumentu obstajajo oznake. "Samodejna rezervacija" in "Samodejna umestitev". Če so te zastavice nastavljene, se lahko stolpec »Umestitev« samodejno izpolni, ko kliknete gumb "Izpolni in objavi". Avtomatsko in ročno shemo postavitve je mogoče kombinirati.

Podatke na zavihku »Predračun« lahko uporabimo kot povezavo med podsistemom za proračun in podsistemom za upravljanje gotovine. Podatki, prikazani na tem zavihku, služijo za kontrolo višine sredstev, ki so predvidena za črpanje v skladu z načrtovanim proračunom (slika 7).

Ker ima nabavnik omejene pravice dostopa, lahko v dokumentu »Zahtevek za porabo sredstev« nastavi samo status »Pripravljen«, statusi kot so: »Odobren«, »Odloženo«, »Dogovorjeno«, »Zavrnjen« nastavijo uporabniki, odgovorni za odobritev aplikacije.

2. Finančni direktor pregleda in odobri vlogo za porabo sredstev v višini 120.000 rubljev.

Finančni direktor lahko analizira seznam vlog, ki zahtevajo obravnavo, s pomočjo obdelave »Status odobritve vloge« (slika 8).

Ko začnete obdelovati »Status odobritve vloge«, prikaže seznam vseh vlog, razvrščenih po določenih statusih (stanjih), kot so: »Pripravljeno«, »Odobreno«, »Odloženo«, »Dogovorjeno«, »Zavrnjeno«. Za udobje lahko z gumbom izberete »Nastavitev obdobja«, na primer za dan, teden, mesec, desetletje, četrtletje, pol leta, leto itd., Nato pa od vseh vlog bodo ostale le tiste, ki sodijo v dano obdobje.

Če želite spremeniti status vlog za porabo sredstev, na primer iz »Pripravljeno« v »Odobreno«, morate uporabiti drugo obdelavo (»Status vloge«).

Pri tej obdelavi lahko izbirate med splošni seznam aplikacije, na primer aplikacije s statusom »Čakanje na odobritev«, »Odloženo«, »Čakanje na odobritev v prejšnjih fazah«, »Obdelava« (slika 9).

Obdelava prikaže seznam neusklajenih aplikacij in lahko spremenite status aplikacije (slika 10). Do te obdelave lahko greste prek menijske postavke »Načrtovanje« - »Zahteve« - »Usklajevanje aplikacij«.

Finančni direktor lahko Zahtevo za porabo sredstev »Odobri«, »Odloži« ali »Zavrne«. Ko izberete »Spremeni status« - »Strinjam se«, potrditvena polja označijo tiste aplikacije, ki jih je treba odobriti. Preostale vloge, ki so bile v čakalni vrsti, si lahko ogledate v dnevniku dokumentov “Odobritev vlog”.

Če vloga ni prestala odobritvene poti (status vloge ni »Odobrena«), na njeni podlagi ni mogoče izdati plačilnega dokumenta.

Če aplikacija začne iti skozi pot odobritve, jo je mogoče spremeniti:

Uporabnik, čigar prijava je trenutno v odobritvi;

Uporabniki, ki odobrijo aplikacijo na višjih stopnjah odobritve.

Drugi uporabniki ne morejo spremeniti aplikacije.

Če je aplikacija v stanju “Odobreno”, potem ni na voljo za spreminjanje (postane neaktivna za urejanje), zato polja v aplikaciji za nabavnika postanejo siva in jih ni mogoče spreminjati.

3. Na podlagi odobrene vloge nabavni računovodja sestavi blagajniški prejemek z vrsto transakcije "Plačilo dobavitelju" brez oznake "Plačano" za izdajo predujma dobavitelju IP Dobronravov (slika 11)

Opomba, da sta v blagajniškem nalogu, ki ga je izdelal nabavnik, obkljukani le potrditveni polji »Odražaj v poslovodnem knjigovodstvu« in »Odražaj v obratovalnem knjigovodstvu«. Potrditveno polje »Plačano« mora potrditi višji blagajnik, potem ko je preveril pravilnost oblikovanja blagajniškega naloga. V blagajniškem nalogu tudi označimo, na podlagi katere vloge ga generiramo.

Če so v blagajniškem nalogu potrditvena polja samo za poslovodno računovodstvo, potem tak dokument ne ustvarja knjižb (knjigovodskih evidenc). Toda vpisuje v akumulacijske registre: »Denar za odpis« in »Poravnave z nasprotnimi strankami« (slika 12). Ti podatki gredo v poročilo »Plačilni koledar« v razdelku »Neplačani izhodni dokumenti« (slika 13).

4. Višji blagajnik preveri blagajniški nalog, potrdi polje »Plačano« in izda gotovino.

Po plačilu blagajniškega naloga postanejo polja v dokumentu siva in jih nabavnik in drugi udeleženci v našem primeru ne morejo urejati. Odvisno od tega, katere pravice dostopa so konfigurirane za določenega uporabnika, so lahko določeni dokumenti, polja v dokumentih itd. na voljo za urejanje.

Opomba:Če je blagajn veliko in morate pri vsaki označiti polje »Plačano«, lahko uporabite skupinsko obdelavo imenikov in dokumentov (točka menija »Storitev«). Do te obdelave lahko greste tako, da odprete celoten vmesnik, točko menija »Storitev« (slika 14).

Če želite spremeniti podrobnosti, kliknite gumb »Nastavitve« in izberite zastavico »Dovoli spreminjanje podrobnosti predmeta«. Za lažjo analizo nastavimo zastavico »Prikaži vse stolpce« (slika 15).

S skupinsko obdelavo želimo na blagajniškem nalogu postaviti oznako »Plačano«. Če želite to narediti, v razdelku »Izbira« skupinske obdelave navedemo organizacijo StroyTorg LLC; Izberemo samo obdelane dokumente za obdobje od 01.01.2013 do 21.01.2013 z možnostjo “Plačano” - “Ne”.

Ko na zavihku »Obdelava« kliknete gumb »Izberi«, se prikažejo dokumenti, v katerih morate označiti »Plačano« (slika 16). V vrstici »Dejanje« izberite »Spremeni podrobnosti [Link.Paid] - Namestitev. In "Beži".

Po spremembi vrednosti podrobnosti morate ponovno knjižiti spremenjene dokumente: v polju »Dejanje« izberite »Spremeni: [Objavi dokumente] – Nastavi - »Zaženi« (glej sliko 17).

5. Računovodja blagajne preveri blagajniški nalog (označi polje za odraz v računovodskih in davčnih knjigovodskih evidencah, da se ustvarijo računovodske in davčne knjigovodske knjižbe).

Nadalje, na primer računovodja blagajniškega prometa ob koncu delovnega dne preveri vse gotovinske izdajne naloge, ki imajo oznako »Plačano«, in v dokumentu odkljuka polja BU in NU, tako da dokument ustvari računovodske in davčne knjigovodske knjižbe. (slika 18)

Opomba:če je veliko blagajniških nalogov, v katerih morate potrditi polja BU in NU, potem lahko uporabite »Skupinska obdelava referenčnih knjig in dokumentov« (slika 19).

V skupinski obdelavi imenikov in dokumentov izberemo dokumente »Blagajniški nalog [TC: Dekodiranje plačil]«, v tabelarnem delu katerega morate označiti potrditveno polje »Odražaj v knjigovodstvu«.

V polju “Izbira” navedemo, za katero organizacijo moramo izbrati dokumente, navedemo, da nas zanimajo le dokumenti, obdelani za interval od 01.01.2013 do 21.01.2013 (ter tudi blagajniške prejemke, v katerih potrditveno polje »Odražaj v računovodstvu« ni potrjeno) računovodstvo«). Ko izpolnite vse parametre, kliknite gumb »Izberi«: izbrani bodo dokumenti, ki izpolnjujejo navedene pogoje. V spodnjem delu okna za obdelavo izberite »Spremeni atribute« - »Odražaj v računovodstvo" - "Namesti" in kliknite gumb "Zaženi". Ko so dokumenti obdelani, jih je potrebno ponovno knjižiti (slika 16). Nato morate ponoviti isto stvar, vendar potrdite polje »Odražaj v davčnem računovodstvu«

Pri knjiženju dokumenta »Izdatni nalog« se ne ustvarjajo samo premiki na računovodskih kontih, temveč tudi v registrih (sl. 20, 21)