Transferi novca 

1c odobrenje zahtjeva i utrošak sredstava. Dokument "zahtjev za plaćanje". Učitavanje i istovar platnih dokumenata u banku klijenta

“Morate pokrenuti milionski posao s primjetnim nedostatkom novčanica.”

I. Ilf i E. Petrov

Operativno planiranje saobraćaja Novac ili kako izgraditi sistem za kontrolu trošenja sredstava

Uvod

Ovaj članak je posvećen operativnom planiranju novčanih tokova (u daljem tekstu „DC“), a bit će otkriveni sljedeći aspekti ove aktivnosti:

  1. uloga operativnog planiranja DS-a u životu kompanije;
  2. podsistem operativnog planiranja DS u standardnoj konfiguraciji “1C:Management” proizvodno preduzeće ed. 1.3 (izdanje 1.3.32.1)" (u daljem tekstu UPP);
  3. karakteristike i greške tipičnog podsistema mekog pokretača;
  4. praktično iskustvo implementacija podsistema operativnog planiranja DS;
  5. Moguće opcije za poboljšanja i ispravke grešaka u standardnom SCP podsistemu.

1 Uloga operativnog planiranja DS u životu kompanije

San svakog finansijskog direktora (Chief Financial Officer) je odsustvo "cash gap-a" (cash gap je nedostatak sredstava za ispunjavanje trenutnih obaveza kompanije u određenom trenutku) u njegovoj kompaniji, i ovaj san je postao izjednačen. nametljiviji tokom krize. Novac je pokretačka snaga kompanije, a njegovo odsustvo, čak i na kratak period, može dovesti do “ozbiljne bolesti” ili čak “smrti” kompanije. Razlog za „cash gap“ je nesklad između vremena prijema sredstava i njihovog trošenja, što može biti uzrokovano nizom objektivnih razloga, na primjer: sezonskim karakteristikama područja djelatnosti kompanije. Primjer su poljoprivredne (biljne) kompanije koje snose glavne troškove zimi i proljeća, a najveći dio prihoda ostvaruju u jesen. Kada dođe do „cash gap-a“, kompanija mora da pribegne različitim merama da ih eliminiše, na primer: privlačenje bankarski krediti, krediti, hitna prodaja likvidnih sredstava itd. Uprkos poduzetim mjerama, ova situacija će se na ovaj ili onaj način štetno odraziti na dobrobit kompanije. Stoga je razvoj sistema za planiranje, izvršenje i kontrolu tokova gotovine jedan od glavnih zadataka. finansijski direktor kompanije.

2 Podsistem operativnog planiranja DS u standardnoj konfiguraciji „1C: Manufacturing Enterprise Management rev. 1,3" (u daljem tekstu UPP)

UPP ima niz dokumenata i izvještaja koji vam omogućavaju da unesete planove prijema i utroška sredstava i na osnovu tih podataka izgradite kalendar plaćanja. Pogledajmo bliže ove konfiguracijske objekte:

  1. dokument " Planirani novčani tok": ovaj dokument odražava planirani prijem DS. Dokument označava konkretnu drugu stranu, ugovor, stavku novčanog toka itd. Dokument ima posebnu funkciju „Uključi u kalendar plaćanja“; ako nije postavljena, podaci neće biti uključeni u registar „Poravnanja sa drugim ugovornim stranama“ i kao rezultat toga u izvještaj „Kalendar plaćanja“ i druge izvještaje .

Značajka 1: Ako nakon objavljivanja ovog dokumenta pogledamo izvještaj „Izvještaj o namirenjima sa drugim ugovornim stranama“, tada ćemo u njemu vidjeti potvrdu o iznosu dokumenta, što bi trebao biti rezultat. I u ovom slučaju, važno je prilikom unosa dokumenta plaćanja (p/p ili PKO) da povežete dokument planiranja prijema DS, inače ćemo videti udvostručenje iznosa računa u izveštaju. Takođe, ako dokumenti nisu povezani, u kalendaru plaćanja će biti prikazani netačni podaci. Lako je pogriješiti, na primjer, ako u planskom dokumentu navedete oblik plaćanja „Gotovina“ i izvršite plaćanje bezgotovinskim putem, tada u ovom slučaju neće biti moguće naznačiti povezanost dokumenata i , kao rezultat, pojavit će se duplikat. Čak i ako koristite mehanizam „Unesi na osnovu“ da odrazite činjenicu plaćanja, a veza između dva dokumenta će biti vidljiva u strukturi subordinacije, to ne znači da će sve ispravno proći kroz registre.

  1. dokument " Prijava za trošenje DS“: ovaj dokument je neophodan da bi se odrazili planirani troškovi DS. Istovremeno, ovaj dokument se može koristiti za rezervisanje DS-a za određeno plaćanje. Dokument označava konkretnu drugu stranu, ugovor, stavku novčanog toka itd. Dokument ima posebnu funkciju „Uključi u kalendar plaćanja“, ako nije postavljena, podaci neće biti uvršteni u registar „Poravnanja sa drugim ugovornim stranama“ i kao rezultat toga u izvještaj „Kalendar plaćanja“ i druge izvještaje. Takođe u ovaj dokument Za praćenje usklađenosti prethodno unesenog budžeta i planirane isplate postoji posebna kartica „Budžetiranje“ koja ukazuje na scenario planiranja i stavku budžeta.

Značajka 2: Ako aplikacija nije odobrena, ona i dalje završava u izvještaju „Kalendar plaćanja“ ako je odabrana zastavica „Uključi u kalendar plaćanja“. Ostavićemo raspravu na temu „Da li je to opravdano ili ne“ van okvira članka. Prilikom unosa plaćanja, lako je napraviti greške opisane u odeljku „Funkcija 1“.

  1. dokument " Zatvaranje planiranih prihoda": navedeni dokument je namenjen za zatvaranje dokumenata "Planirani prijem DS", tj. planirani iznos (deo iznosa) DS računa se „skida“.

Značajka 3: Nažalost, ovaj dokument vam ne dozvoljava ručno podešavanje iznosa na zatvaranju, tj. program gleda na bilans ovog plana i sve ostatak je pokriven, što nije uvijek zgodno. Na primjer, ako smo djelimično prilagodili plan implementacije, onda bi se plan za prijem DS trebao promijeniti. U tom slučaju, moraćete da izvršite izmene u dokumentu „Planirani prijem DS“, ali podešavanja „ backdating“, kao što znate, ne vodi dobrim stvarima. Pored toga, ako se usklađivanje planiranog prijema DS unese u dokument „Zatvaranje planiranih primanja“, tada će biti moguće pratiti istoriju promena planova.

  1. dokument " Zatvaranje zahtjeva za trošenje sredstava» je namijenjena za zatvaranje dokumenata „Zahtjev za rashode DS“, tj. „skida se“ planirani iznos (deo iznosa) za trošenje DS.

Značajka 4: slične nijanse su opisane u “Fakcija 3”.

  1. Prijavi " Raspored plaćanja": ovaj izvještaj prikazuje predstojeće troškove i račune DS-a, što vam omogućava da vidite "kašne praznine."

Funkcija 4 : Standardni certifikat za izvještaj kaže: „Izvještaj je namijenjen za prikaz informacija o planiranim uplatama, primicima i stanja za odabrani vremenski period" Ako je neko mislio da je reč o stanju DS na tekućim računima, duboko se vara. Riječ je o stanju na zahtjevima/planiranim računima (ovaj primjer ćemo pogledati kasnije).

  1. Prijavi " Analiza dostupnosti DS-a“: ovaj izveštaj prikazuje stanje DS u preduzeću, DS rezervisan po prijavama DS, kao i DS za otpis i prijem.
  2. Prijavi " Prijave za trošenje sredstava" Prema UPP certifikatu, ovaj izvještaj se zove “Nenaplaćene dolazne uplate” i “namijenjene za dobijanje informacija o pristiglim uplatama koje su registrovane u sistemu, a za koje nijedna uplata nije izvršena neophodne radnje: odraz u operativnom računovodstvu ili stvarni novčani tok (plaćanje).“ J To je smiješno! Za „pravu“ pomoć idite u konfigurator i pogledajte opis: „namijenjen je analizi izvršenja zahtjeva za trošenje sredstava u određenom vremenskom periodu. U koloni “Dolazni” ispisuju se iznosi za popunjene zahtjeve, a u koloni “Trošak” o izvršenju zahtjeva za period (izdavanje platnih dokumenata na osnovu zahtjeva ili njihovo zatvaranje). Stanja na početku i na kraju perioda pokazuju nepodmirene iznose za prijave.”
  3. Prijavi " Planirani prijem DS" Ako vjerujete certifikatu, onda je ovo još uvijek isti izvještaj" Neplaćene dolazne uplate"J. U konfiguratoru: „dizajniran za analizu realizacije planova za prijem sredstava, dokumentovanih relevantnim dokumentima za određeni vremenski period. U koloni „Ulazni“ ispisuju se iznosi planiranih primanja, a u koloni „Rashodi“ izvršenje planova prijema sredstava za određeni period (registracija ulaznih uplatnih dokumenata na osnovu dokumenata za planiranje prijema sredstava). ”
  4. Registar informacija « Postavke za odobravanje zahtjeva za trošenje DS»: Registar je namijenjen da „omogući” korištenje mehanizma za usklađivanje zahtjeva za određenu organizaciju i period.
  5. Imenik « Koordinacioni putevi aplikacije": ovaj direktorij opisuje rute za odobravanje aplikacija za trošenje DS.
  6. Registar informacija" Postavke rute za odobrenje narudžbe» propisuje rutu za odobravanje aplikacije, a u standardnoj funkcionalnosti zavisi samo od odjela (CFD - centar finansijske odgovornosti) aplikacije.
  7. Tretman "Koordinacija aplikacija": U ovoj obradi, zahtjevi su koordinirani.
  8. Dodatno pravo" Dozvolite plaćanje bez aplikacije» omogućava plaćanje bez odobrene aplikacije.

Značajka 5:Ograničenje prava ne radi (lako se zaobilazi) ako:

A) isprava o uplati se ne sprovodi ažurno;

B) polje za potvrdu ne uključuje atribut “Odrazi u operativnom računovodstvu”;

C) nalog za plaćanje i gotovinsko poravnanje sa vrstom operacije „Plaćanje plate" Ovo je UPP greška: kod se provjerava u odnosu na netačan tabelarni dio dokumenta.

  1. Dodatno pravo" Dozvoli prekoračenje kontrolisane vrednosti prema budžetima» - omogućava izradu prijave za utrošak sredstava u slučaju da iznosi na zahtjevima premašuju planirani iznos za kontrolisanu budžetsku stavku.

3 Karakteristike i greške tipičnog podsistema mekog pokretača

Pogledajmo karakteristike i greške tipičnog podsistema koristeći poseban primjer.

Početni podaci (uslovi problema):

A) uđite nova organizacija"TRG" u UPP demo bazu podataka;

B) unesite početna stanja DS ( od 11.01.2012): 1 milion radnika na tekući račun i 50 hiljada rubalja. u registar;

C) kreiramo nove korisnike “Upravitelj nabave” ( Ne instaliramo dodatno pravo "Dozvoli plaćanje bez aplikacije") i "Menadžer prodaje".

  1. Menadžer prodaje planira prodati “proizvod 1” ovog mjeseca (isplata je planirana za bezgotovinsko plaćanje) u iznosu od 600.000 rubalja i unosi dokument „Planirani prijem DS“.

Bitan: Ako ne postavite atribut „Uključi u kalendar plaćanja“, tada planirani prijem DS neće biti uključen u izveštaj „Kalendar plaćanja“ ili „Izvod o obračunu sa drugim ugovornim stranama“. U našem primjeru ćemo ga instalirati.

Pogledajmo izvještaj "Kalendar plaćanja":

Obratite pažnju na podatke koje će izveštaj prikazati ako je period postavljen od 01.11.12 (od momenta unosa stanja):

Važno je zapamtiti ovu funkciju!

Također imajte na umu da izvještaj ne prikazuje (ovo je greška u izvještaju) stanja gotovine u posebnom odjeljku:

  1. Kako je planirano, prodaja je prošla, ali kupac Prvu dostavu sam platio bankovnim transferom, A drugu isporuku platio gotovinom. Unosimo prodajne dokumente u iznosu od 400.000 i 200.000 rubalja, zatim putem mehanizma „Unesi na osnovu“ unosimo nalog za plaćanje u iznosu od 400.000 i PKO u iznosu od 200.000 rubalja. Analizirajmo izvještaje:
    1. Generisaćemo izveštaj „Kalendar plaćanja“ od 02.11.2012 do 31.12.2012, dobićemo sledeći rezultat:

Planirani iznos od 200.000 je ostao, iako je uplata prošla. To se dogodilo zbog činjenice da smo sve isplate planirali bankovnim transferom, ali smo dobili 200 hiljada u gotovini i, shodno tome, nismo mogli da "povučemo" aplikaciju gotovinski dokument, pa čak ni činjenica da smo sve dokumente unijeli pomoću mehanizma „unesi na osnovu“ „nije pomoglo“, a u strukturi subordinacije vidimo lanac:

Izbrisaćemo PKO i napraviti nalog za plaćanje od 200 hiljada, ali nećemo postaviti znak “Plaćeno”. Tako ćemo u kalendaru plaćanja vidjeti sljedeću sliku:

  1. Planiramo da potrošimo DS u iznosu od 500.000 za plaćanje dobavljača. Unesimo aplikaciju za trošenje DS:

Kalendar plaćanja će izgledati ovako:

Napominjemo da je trošak zakazan za 09.12.12., iako je datum prijave 08.12.2012., to je tačno, jer u polju „datum potrošnje“ naznačili smo 09.

  1. Mi ćemo odobriti aplikaciju. Odobrenje nastaje procesom „Odobravanje aplikacije“, a mehanizam odobravanja je takođe dostupan preko Web interfejsa. Postoji vrlo zgodan i korisna funkcija postavke izvještaja:

Izvještaj se prvo razvija i pohranjuje u odjeljku „Prilagođeni izvještaji“ (Usluga->Prilagođeni izvještaji), a zatim se koristi za prikaz potrebnih informacija prilikom odobravanja aplikacija. Koristeći ovu funkcionalnost, možete konfigurirati prikaz stanja na tekućim računima uzimajući u obzir uplate za odobrene aplikacije, također možete prikazati usklađenost aplikacije sa budžetom itd. Mogućnost odobravanja preko web interfejsa omogućava menadžeru da kontroliše plaćanja bez da bude na radnom mestu.

  1. Sada ćemo na osnovu odobrene aplikacije unositi plaćanje odlaznim nalogom za plaćanje, a pokušaćemo i da zaobiđemo mehanizam zabrane plaćanja više od iznosa odobrene aplikacije:

Kao što vidite, kada se nalog za plaćanje promptno obradi, pojavljuje se poruka da je prekoračen dozvoljeni iznos na aplikaciji, ali kada se ne obradi promptno, kontrola ne radi, a menadžer nabavke uspijeva uplatiti dobavljač više nego što je menadžer odobrio:

Zbog ove greške, kao u izvještaju "Kalendar plaćanja", pojavljuju se "čuda":

Također ne dešava se kontrolu u RKO sa skinutom zastavom" Odrazite se u operativnom računovodstvu."

Nema kontrole takođe u Nalog za plaćanje, u i RKO sa tipom operacije “Isplata zarada”, što je greška u standardnom UPP.

4 Praktično iskustvo u implementaciji podsistema za operativno planiranje saobraćaja vozila

Pogledajmo sada praktična iskustva implementacije ovog podsistema u velikom poljoprivrednom gazdinstvu (nazovimo ga „Agro“), dok ćemo pažnju obratiti samo na troškovni dio operativnog planiranja, jer to je najinteresantnije i najhitnije, jer možemo uticati na rashode, ali nije tako lako uticati na prihode.

Započela je implementacija podsistema operativnog planiranja kretanja DS u Agro uz sveobuhvatnu automatizaciju računovodstva na osnovu UPP 1.3. Ranije je holding vodio evidenciju u 8 različitih konfiguracija (više od 5 udaljenih kancelarija u 4 regiona naše zemlje), a operativno planiranje saobraćajnih tokova vršeno je u Excel-u. Krajem mjeseca poslana su podružnica društvo za upravljanje(u daljem tekstu Krivični zakonik) i planove utroška DS i planove prijema DS. Zaposleni u rukovodstvu trezora su dostavljene planove proveravali sa budžetom, zatim ih poslali načelnicima oblasti na saglasnost, načelnici oblasti su korigovali i usaglašavali planove kretanja DS. Zatim je Uprava za trezor konsolidovala planove dobijene od menadžera u oblastima i poslala konačni plan generalnom direktoru na odobrenje. Odobreni plan je vraćen zavisnim preduzećima, a u roku od mesec dana zaposleni u menadžmentu trezora su proverili kretanje DS sa odobrenim planom, tj. kontrolisao njegovu implementaciju.

U toku pripreme sistema za puštanje u komercijalni rad izvršena je analiza i izgradnja „kao što jeste“ modela poslovnog procesa „Operativno planiranje saobraćaja vozila“. Nakon reinženjeringa poslovnog procesa i izgradnje modela „kako treba“, razvijena je nova regulativa za poslovni proces „Operativno planiranje kretanja vozila“. Urađene su neophodne modifikacije na SCP demonstracionoj bazi i razvijen je testni slučaj. Testni primjer su testirali svi učesnici u poslovnom procesu, uočeni su nedostaci i izražene su dodatne želje za unapređenje funkcionalnosti SCP-a. Nakon otklanjanja grešaka i potrebnih prilagođavanja, naredbom je odobrena i dovršena nova regulativa za poslovni proces „Operativno planiranje kretanja vozila“. generalni direktor zaposlenima u holdingu. U donjem dijagramu daću primjer kako obraditi zahtjev za utrošku DS nakon uvođenja novih propisa:

Rezultat dobijen implementacijom ovog podsistema:

  1. pojačana kontrola trošenja DS u holding kompanijama;
  2. povećana je brzina izrade saobraćajnih planova za motorna vozila;
  3. izvršenje plana pokreta DS postalo je „transparentnije“;
  4. “cash gaps” su izbjegnuti.

Napominjem da je nakon implementacije UPP-a u holding kompanijama (više od 120 korisnika radi on-line koristeći Web klijent ili udaljenu vezu preko RemoteAPP) i podsistema operativnog planiranja DS, posebno, tema bila: “ da li je prijava za trošenje DS dogovorena ili nije?” postao jedno od najhitnijih pitanja u kompaniji. Na površinu su isplivale činjenice da su holding kompanije ponekad isplaćivale dobavljače, uprkos zabrani kompanije za upravljanje i neskladu između troškova i odobrenog budžeta. Naravno, nakon što je dobio tako moćan kontrolni alat kao što je ujedinjeni ERP sistem, to je odmah dalo pozitivan rezultat.

5 Poboljšanja napravljena tokom implementacije podsistema

U ovom paragrafu ću opisati samo mali dio poboljšanja urađenih tokom implementacije podsistema u holdingu.

  1. Ispravljene su greške u standardnoj konfiguraciji soft startera 1.3.
  2. Iznosi zasnovani na prijavama za izdatke DS i planove prijema DS počeli su da se pojavljuju u kalendaru plaćanja tek nakon odobrenja.
  3. Šema za odabir rute za odobravanje prijave za trošenje DS je promijenjena. Ruta za odobravanje aplikacije počela je ovisiti o:
    1. DS članci;
    2. iznos aplikacije.
    3. Samo odobreno platni nalozi se mogu učitati u banku klijenta. U standardnom UPP-u se istovaraju i neodobreni artikli.
    4. Ukinuta je mogućnost zaobilaženja zabrane plaćanja bez aplikacije.
    5. Historija odobrenja aplikacija je pohranjena. U svakom trenutku korisnik može vidjeti ko ima zahtjev za odobrenje i ko je (kada) odobrio aplikaciju.
    6. Razvijen je mehanizam za „korespondenciju“ o aplikacijama, koji se koristi kada aplikacija prolazi kroz put odobrenja.
    7. Unaprijeđena je obrada odobravanja prijava. Zahtjev koji se koristi u dinamičkoj listi nije bio optimalan, kao rezultat toga, sa velikim brojem zahtjeva, u trenutku odobravanja, obrada je zamrznuta 2-3 minute. Prepiska sa programerima u vezi ove greške nije dala nikakve rezultate, pa je greška samostalno ispravljena.
    8. Obrada je razvijena za uključivanje aplikacije u kalendar plaćanja, tj. nakon odobrenja prijave dodatno je određen postupak plaćanja, odnosno određen je postupak uvrštavanja prijave u kalendar plaćanja
    9. Razvijen je paket izvještaja (Kalendar plaćanja, Novčani tok, status odobrenja naloga itd.) koji se koristi u holdingu.

U prilogu ovog člana nalazi se izvještaj SKD-a za obradu odobrenja zahtjeva.

6 Zaključak

Ako želite da se riješite gotovinskih praznina, planirajte tok novca mora biti kontinuiran proces. Što je preduzeće veće, složenija je njegova struktura, to više više tipova aktivnosti, to je teže upravljati novčanim tokovima. Stoga je jedinstveni ERP sistem moćan alat u planiranju i kontroli novčanog toka.

Kalendar plaćanja u 1C:ERP Enterprise Management 2 prikazuje informacije o:

  • raspoloživo stanje gotovine na gotovinskim i bezgotovinskim računima kompanije;
  • planiranih primanja i utroška sredstava.

Pristup Kalendaru plaćanja je omogućen preko sekcije „Trezor“ u grupi „Planiranje i kontrola gotovine“. Kalendar plaćanja se generiše za proizvoljan period naveden u danima.

Na vrhu obrade "Kalendar plaćanja" dostupne su sljedeće opcije:

  • period formiranja;
  • organizacije;
  • valuta;
  • izbor za specifične račune organizacije.

Obrazac kalendara plaćanja u 1C:ERP Enterprise Management 2 prikazan je na Sl. 1.

Slika 1 - Kalendar plaćanja u 1C:ERP Enterprise Management 2

Osnovni dokumenti za popunjavanje Kalendara plaćanja su:

  • "Narudžba kupca";
  • “Narudžba dobavljaču”;
  • “Nalog za premještanje sredstava”;
  • “Prijava za trošenje DS.”

Postavke kalendara plaćanja u “1C:ERP Enterprise Management 2”

Kalendar plaćanja možete podesiti putem dugmeta „Više“ u gornjem desnom uglu.


Slika 2 – Postavke kalendara plaćanja

Kalendar plaćanja prikazuje aplikacije koje imaju status „Odobreno“ ili „Nije odobreno“, ako je ova opcija navedena u podešavanjima (Sl. 2). Prijave sa statusima “Plaćivo” i “Odbijeno” nisu vidljive u kalendaru plaćanja.

Vrste kalendara plaćanja

Kalendar plaćanja može se kreirati u 3 vrste (slika 3).


Slika 3 – Odabir vrste kalendara plaćanja

Aplikacije - Kalendar (Sl. 4)

Lijeva strana obrasca prikazuje informacije o zahtjevima za trošenje sredstava.

Desna strana obrasca prikazuje informacije o:


Slika 4 - Kalendar plaćanja tipa „Nalozi – Kalendar“.

Kalendar – Uplate (Sl. 5)

Na vrhu obrasca Kalendar plaćanja, informacije o:

  • stanje gotovine na računima organizacije;
  • očekivani novčani tokovi;
  • planirani utrošak sredstava.

U donjem dijelu obrasca Kalendar plaćanja ispisuju se podaci o dokumentima koji su osnova za popunjavanje gornjeg dijela Kalendara plaćanja.


Slika 5 - Kalendar plaćanja tipa „Kalendar – Uplate“.

Lista aplikacija (slika 6)

Lista aplikacija prikazuje aplikacije koje imaju status „Odobreno“ ili „Nije odobreno“, ako je ova opcija navedena u podešavanjima (Sl. 2).


Slika 6 - Kalendar plaćanja tipa „Lista prijava“.

Odjeljak "Kalendar"

U rubrici „Dospjelo“ možete vidjeti dug naše organizacije za:

  • obračuni sa dobavljačima i kupcima;
  • isplata plata, poreza i taksi;
  • izdavanje kredita i zajmova;
  • plaćanje kamata;
  • primljene kredite i pozajmice.

Pažnja!!! Prilikom unosa početnih stanja za gotovinu i tekuće račune, ona će se također prikazati u Kalendaru plaćanja u koloni „Kasnjenja“.

Kolone za odgovarajući datum prikazuju podatke o planiranim obračunima sa dobavljačima, kupcima, zaposlenima, regulatornim tijelima i drugim ugovornim stranama. Datum i iznos uplate određuje se prema pratećoj dokumentaciji.

Sredstva na putu su prikazana u kalendaru plaćanja u obliku 2 iznosa:

  • sa znakom “-” za račun sa kojeg će biti poslata sredstva;
  • sa znakom “+” za račun na koji treba stići sredstva (slika 7).

Operacija se reflektuje na osnovu dokumenta „Nalog za kretanje sredstava“ sa vrstom operacije „Naplata sredstava u banku“ od planiranog datuma slanja sredstava (datum uplate) (Sl. 9). Narudžba mora imati status “Dogovoreno” ili “Za plaćanje”.


Slika 7 - Prikaz u PC-u operacije naplate DS nakon knjiženja dokumenta “Nalog za kretanje sredstava” sa tipom operacije “DS naplata u banku”

Prilikom generiranja dokumenta „Potrošni materijal gotovinski nalog» kod tipa operacije „Naplata u banku“, sredstva u tranzitu se mogu videti u kalendaru plaćanja u koloni računa na procenjeni datum prijema (Sl. 8).


Slika 8 - Prikaz u PC-u operacije naplate DS nakon knjiženja dokumenta „Izlazni nalog“ sa tipom operacije „Naplata u banku“

Datum planiranog prijema određuje se zbrajanjem datuma planiranog otpremanja DS (Sl. 9) i perioda prikupljanja (Sl. 10).


Slika 9 – Indikacija datuma planirane uplate u dokumentu „Nalog za kretanje sredstava“


Slika 10 - Podešavanje perioda naplate u direktorijumu „Blagajna organizacije“

Prilikom sastavljanja Kalendara plaćanja automatski se provjerava njegova izvodljivost – tj. dovoljnost novčanih rezervi za plaćanje u mjestima njihovog skladištenja.

Planirani iznosi primitaka i uplata prikazuju se u obliku dnevnog sažetka. Za detaljnije informacije koristite odjeljak "Plaćanja".

Odjeljak "Plaćanja"

Ovaj odjeljak sadrži informacije o dokumentima koji su osnova za planiranje plaćanja i računa.

Podaci o plaćanju ukazuju na planirani datum plaćanja, ali ne označavaju "kasnilo".

Blok plaćanja vam omogućava da:

Odjeljak "Prijava"

U izdanju 2.2.3.190 “1C: ERP Enterprise Management 2” moguće je omogućiti ili onemogućiti izvršavanje “Zahtjeva za utroškom DS-a”.

Ova postavka je dostupna u odeljku „Glavni podaci i administracija“, grupi „Podešavanje glavnih podataka i sekcija“, stavci „Trezor“ (Sl. 11).


Slika 11 - Postavke za korištenje u 1C programu: ERP Enterprise Management 2 “Zahtjevi za trošenje sredstava”

U direktorijumu „Blagajna preduzeća“ možete označiti polja koja regulišu izvršavanje zahteva za plaćanje posebno za izabranu kasu preduzeća (slika 12):

  • dozvoliti izdavanje sredstava bez „zahtjeva za plaćanje“;
  • omogućavaju prijem i prenos sredstava na druge kase bez „naloga za kretanje“.


Slika 12 - Podešavanje korišćenja „Zahtevi za utrošak sredstava“ i „Nalozi za prenos sredstava“ u priručniku „Gotovina organizacije“

Slični potvrdni okviri se mogu označiti u imeniku „Organizacioni bankovni račun“ (Slika 13).


Slika 13 - Podešavanje korišćenja „Zahtevi za trošenje DS“ u direktorijumu „Bank račun organizacije“

Pažnja!!! Ova podešavanja ne utiču na proceduru generisanja kalendara plaćanja.

U “1C: ERP Enterprise Management 2” dokument “Zahtjev za utroškom DS” namijenjen je za prikaz planiranog utroška sredstava sledeće vrste:

  • izdavanje sredstava odgovornom licu;
  • transfer sredstava dobavljaču;
  • vraćanje sredstava klijentu;
  • plaćanje kredita;
  • carina;
  • plaćanje drugoj organizaciji;
  • ostali gotovinski troškovi itd.

Korištenje aplikacija za trošenje DS-a omogućava vam da izvršite sljedeće zadatke:

  • odražavaju potrebe za sredstvima odjeljenja preduzeća;
  • planirati utrošak sredstava;
  • spriječiti nedosljedne isplate novca;
  • kontrolišu iznos sredstava dozvoljenih za rashode.

Prijave se prikazuju u kalendaru plaćanja u zavisnosti od statusa i popunjenosti polja „Objekat poravnanja“ (Tabela 1, Tabela 2)

Tabela 1. Opcije za uticaj zahtjeva na formiranje kalendara plaćanja, ako u postavkama nije navedeno „Prikaži neusklađene zahtjeve za trošenje sredstava u kalendaru“

Status prijave za trošenje DS Polje "Objekat obračuna" Prikaz u kalendaru plaćanja Uticaj na formiranje kalendara plaćanja Ispravnost prikaza
"nije dogovoreno" Nije popunjeno Ne utiče Tačno
"nije dogovoreno" Završeno Utiče na promjene u iznosima planiranih plaćanja (poništava primarne dokumente „Nalog dobavljaču“, „Nalog kupca“ itd.) Netačno
"Dogovoreno" Nije popunjeno Dovodi do udvostručavanja očekivanih plaćanja Netačno
"Dogovoreno" Završeno Ne mijenja iznos očekivanih primanja Tačno

Tabela 2. Opcije uticaja zahtjeva na formiranje kalendara plaćanja, ako je u postavkama naznačeno “Prikaži neusklađene zahtjeve za trošenje sredstava u kalendaru”

Za analizu informacija iz gornjih tabela, razmotrite primjer.

Organizacija LLC Confetprom planira isplatiti dobavljaču LLC Nevsky Bereg 74.998,44 za robu 22. maja 2017. (Sl. 20). U program su uneti dokumenti „Nalog dobavljaču” i „Zahtev za utrošak DS”. Na sl. 15-20 prikazana je promena u kalendaru plaćanja u zavisnosti od popunjavanja polja „Zahtevi za utrošak DS“.


Slika 20 – Prikaz dokumenta „Narudžbina dobavljaču“ u kalendaru plaćanja, bez knjiženja dokumenta „Zahtev za DS rashode“.

Pošaljite ovaj članak na moj e-mail

U računovodstvu, faktura za plaćanje u 1C je dokument koji organizacija predstavlja kupcu za isporučenu robu ili pružene usluge kako bi obavijestila o potrebi deponovanja sredstava.

1C nudi dvije opcije za rad sa fakturama za plaćanje u 1C:

Kao dokument koji se čuva u bazi podataka i odgovarajuća štampana forma. Dizajniran je da kontroliše međusobna obračuna sa kupcima u sistemu i prikazuje relevantne informacije na papiru.

Štampani obrazac računa za plaćanje koji se generiše iz narudžbe ili prodajnog dokumenta i potreban je za slanje kupcu. Možete ga odštampati u bilo kom trenutku, a možete i sačuvati obrazac prikazan na ekranu na računaru u bilo kom formatu.

Koja od gore navedenih opcija će biti primenjena zavisi od vrednosti konstante Koristi fakture za plaćanje klijenata i postavlja se u odeljku Glavni podaci i administracija → Prodaja → Veleprodaja→ Račun za plaćanje.

Dokument Račun za plaćanje 1C 8.3

Otvaranje računa u 1s 8.3 moguće je upisom novog iz Registra trgovačke dokumentacije, kao i upisom na osnovu, pod određenim uslovima

Prema nalogu kupca, ako:

U njemu se bira sporazum sa redosledom interakcije Po nalozima;

Ne zahtijeva dogovor, ali ugovor precizira postupak plaćanja za narudžbe.

Račun za plaćanje u 1C kreira se na osnovu prodaje robe i usluga ako:

Koristi se sporazum koji definiše proceduru za fakture;

Dogovor nije potreban, ali se sporazumom preciziraju pravila plaćanja faktura.

Račun u 1C 8.3 može se kreirati na osnovu bilo kojeg od gore navedenih dokumenata, pod uslovom da su pravila za međusobna poravnanja sa klijentom u skladu sa ugovorima.

Prilikom kreiranja računa za plaćanje 1C 8.3 prema podacima bilo kojeg od navedenih objekata, namjerava se radno mjesto„Kreiranje računa za plaćanje“, otvara se u listi pomoću komande Kreiraj na osnovu.

Ovdje postoje dvije radne kartice: Faze i plaćanja i Računi za plaćanje. Svaki ima svoje detalje i obavlja određene funkcije.

Prvi prikazuje sva planirana plaćanja predviđena prema planu plaćanja.

Hajde da objasnimo o kakvom rasporedu je reč. U dogovoru sa klijentom, bilo individualnim ili standardnim, možete uspostaviti raspored plaćanja, u skladu sa kojim je potrebno evidentirati informacioni sistem priliv gotovine.

Za raspored plaćanja navedite naziv i popunite listu faza. Za svaku fazu plana plaćanja, opcija plaćanja (akontacija, plaćanje unaprijed ili kredit), plaćanje (bezgotovinsko ili gotovinsko), postotak ukupan iznos(zbir svih redova treba da bude jednak 100%), odlaganje (pomeranje u danima od datuma prodaje).

Dajemo primjer. Uslovi interakcije su utvrđeni za klijenta: za isporuku proizvoda prema zahtjevu kupac mora uplatiti akontaciju u iznosu od 50% od iznosa ove prijave, ostatak mora platiti u roku od 5 dana nakon otpreme. Sva plaćanja se vrše preko kase.

Popunjavanje podataka izgleda ovako:

Detalji: Po narudžbi;

Način plaćanja: Gotovina;

Mogućnosti plaćanja: avansno plaćanje (prije isporuke) 50% i kredit (nakon otpreme) 5 dana 50%

Prema rasporedu utvrđenom u ugovoru, faze plaćanja se automatski obračunavaju u samom dokumentu (Narudžba kupca ili Prodaja robe i usluga). Po potrebi se mogu ručno podesiti pomoću linka u polju Plaćanje i prenijeti u dokument bez promjene podataka u imeniku.

Oznake u prvoj koloni oznake se automatski postavljaju za one redove za koje je potrebno izdati račun za plaćanje. Ako je uplata za liniju već izvršena (platni dokumenti su uneseni u bazu podataka), tada linija postaje neaktivna i već primljeni iznos se prikazuje u koloni „Uplaćeno“. Račun se kreira pritiskom na istoimeno dugme. U tom slučaju će se kreirati nova knjižena faktura u kojoj će se podaci popunjavati u skladu sa podacima iz osnovnog dokumenta i iznosom za plaćanje. Pojavit će se na listi faktura na sljedećoj kartici „Računi za plaćanje“ u stanju Izdato.

Novi 1C račun sadrži sljedeće informacije:

U zaglavlju: na osnovu čega je izdato, kada, kome i od koga;

Koraci plaćanja prikazuju način plaćanja, bankovni račun i/ili kasu i raspored plaćanja;

Pored toga, menadžer, supervizor, Glavni računovođa, popuniti svrhu plaćanja i po potrebi uneti dodatni tekst za ispis na štampanom obrascu;

U Komentar možete unijeti i drugi slobodni tekst za udobnost korisnika.

Svi kreirani računi za plaćanje za 1C 8.3 dostupni su na listi faktura u odjeljku „Prodaja“. Sve izdate fakture za objekat poravnanja možete pogledati pomoću izvještaja „Povezani dokumenti“ i otvoriti ih direktno iz izvještaja klikom na odgovarajuće redove izvještaja.

Odštampani obrazac za knjiženi račun u 1C možete u bilo kojem trenutku prikazati pomoću naredbe „Ispiši“; moguće je prikazati i grupu od nekoliko odabranih računa.

Štampani obrazac Račun za plaćanje 1C 8.3

Samo formiranje štampanom obliku Račun na 1C 8.3 bez pohranjivanja u bazu podataka, dostupan iz sljedećih sistemskih objekata:

Iz prodajnog naloga, pod sljedećim uvjetima:

Koristi ugovor sa detaljnim proračunima za narudžbe;

Dogovor nije potreban, ali ugovor sadrži mogućnost plaćanja Po narudžbi.

Od prodaje roba i usluga u slučaju da:

Koristi se sporazum u kojem se međusobna poravnanja vrše korišćenjem faktura;

Dogovor nije potreban, ali sporazum navodi detalje za fakture.

Račun u 1s 8.3 može se generisati prema podacima bilo kog od gore navedenih dokumenata, ako se primenjuje procedura za obračun po ugovorima.

Takođe za 1C račune implementirana je mogućnost prikaza fakture sa faksa. Da biste to učinili, otisak faksa mora se dodati na karticu organizacije u postavkama ispisa (metod dodavanja dostupan je na linku „Kako napraviti faks?“). Štampanje takve fakture za plaćanje u 1C vrši se pomoću naredbe Ispis odabirom odgovarajuće stavke menija.

Dokument „Zahtjev za utroškom sredstava“ namijenjen je planiranju i koordinaciji plaćanja.
Dokument “Zahtjev za utroškom DS” možete kreirati tako što ćete otići u odjeljak “Trezor” – “Planiranje i kontrola sredstava” – “Zahtjevi za utroškom DS” – Kreirati.
Dokument „Zahtev za utrošak DS“ ima nekoliko tipova operacija koje se biraju prilikom kreiranja. Svaki tip aplikacije je dizajniran da odražava različite poslovne transakcije, od kojih će svaki biti opisan u ovom priručniku.
Kreirani dokumenti „Zahtjev za utrošak DS“ prikupljaju se i dogovaraju pomoću dokumenta „Registar plaćanja“. Nakon odobrenja, na osnovu prijava, automatski se kreiraju dokumenti „Otpis bezgotovinskih DS“ koji se šalju u banku klijenta na plaćanje od strane banke.
Slede primeri izvršenja dokumenata „Zahtev za izdatak DS“ za svaku vrstu operacije.

Plaćanje dobavljaču
Za obradu platnih transakcija dobavljaču predviđena je vrsta transakcije dokumenta „Zahtev za utrošak DS-a“ – „Plaćanje dobavljaču“.
U novom dokumentu „Zahtjev za utrošak DS“ crvenom bojom su označena polja koja je potrebno popuniti za obradu dokumenta. Dokument se kreira u statusu „Nije odobreno“, status se automatski menja prilikom odobravanja registra plaćanja. Prioritet aplikacije pri kreiranju se automatski postavlja na “Srednji”.

Slika 1. Obrazac dokumenta „Zahtjev za izdatak DS“, vrsta operacije „Plaćanje dobavljaču“ (nije popunjeno)
Detalji dokumenta „Zahtjev za trošenje DS“ moraju se popuniti na sljedeći način:
Osnovna kartica
Broj– se generiše automatski tokom izvršavanja, ne može se podesiti ručno.
datum– kada se kreira, postavlja se trenutni datum.
Organizacija– morate izabrati sa predložene liste organizacija koristeći dugme, ili unosom naziva u polje biće ponuđena tražena vrednost za izbor.
Subdivision– iz imenika „Struktura preduzeća“ morate odabrati odjel za koji treba izvršiti plaćanje.
Podnosilac prijave– podrazumevano je prikazan trenutni korisnik sistema koji kreira aplikaciju.
Planiranje– zadana postavka je “U valuti plaćanja” i ne može se promijeniti.
Suma– označava iznos potrebne uplate.
Valuta– naznačite valutu tražene uplate.
Operacija– prikazana je vrsta transakcije dokumenta „Zahtjev za rashode DS-a” odabranog prilikom kreiranja
datum plaćanja– označava datum na koji se mora zakazati plaćanje dobavljaču.
Način plaćanja– zadana postavka je “U bilo kojem obliku” i ne može se promijeniti.
Primalac– označava dobavljača iz imenika “Counterparts” kome se mora izvršiti plaćanje.
Račun primaoca– prilikom odabira „Primalac“ automatski se postavlja račun primaoca; ako je potrebno, ako je na „Računu za plaćanje“ koji je isporučio dobavljač naveden drugi račun, potrebno je odabrati traženi iz imenika „Bankovni računi“.
Preko limita– ako sistem održava sistem za ograničavanje izdataka gotovine u kontekstu filijala odnosno stavki novčanog toka, ako iznos uplate nije prethodno bio uključen u limit, prilikom knjiženja dokumenta korisnik će dobiti poruku o grešci i prijava neće biti obrađena.


Slika 2. Primjer greške prilikom davanja naloga za koji nije planiran limit.
Da biste postavili nalog preko limita, morate postaviti oznaku “Over Limit”.
Transfer u budžet– ova oznaka se postavlja ako je uplata transfer u budžet. Postavljanje zastavice vam omogućava da unesete vrijednosti KBK, OKTMO itd. potrebne za uplate u budžet.

Slika 3. Primjer postavljanja zastavice „Transfer u budžet“.
UIP– jedinstveni identifikator plaćanja, naznačen samo ako je to predviđeno ugovorom sa primaocem plaćanja.
Svrha plaćanja- program nudi nekoliko opcija za automatsko popunjavanje svrhe plaćanja pomoću dugmeta "Ubaci".

Slika 4. Opcije za automatsko popunjavanje polja „Svrha plaćanja“.
Spisak dokumenata, uklj. PDV- će prikazati informacije o objektima poravnanja sa kartice „dešifriranje plaćanja“.

PDV (18%) (za cjelokupan iznos), uklj. PDV (10%) (za cijeli iznos), bez poreza (PDV)- Podaci o PDV-u će biti dodati unesenom tekstu.

Tekst od bankovni račun primalac- unosi tekst naveden u polju "Tekst svrhe plaćanja" sa kartice računa druge strane.

Slika 5. Primjer popunjavanja kartice „Osnovno“.

Kartica Detalji plaćanja
Na kartici "Dekodiranje plaćanja" je naznačeno detaljne informacije o plaćanju i međusobnim obračunima sa primaocem plaćanja.
Plaćanje se može uneti kao lista, tj. raspodijeliti na više proračunskih objekata, ili bez podjele moguće je odabrati samo jedan proračunski objekt.
Plaćanje iz sredstava državne odbrane– zastava se postavlja samo ako se plaćanje vrši u okviru naloga vlade za odbranu, u ostalim slučajevima zastava se ne postavlja.
Objekat kalkulacije– kao objekt poravnanja možete navesti „Ugovor sa drugom stranom” (za ovu vrstu rada aplikacionog dokumenta, kada je odabrano, dostupni su ugovori tipa odnosa „Sa dobavljačem/izvođačem”) ili ugovoreni dokument „Nalog dobavljaču”.
Provajder
Iznos međusobnih obračuna– se automatski postavlja prilikom objavljivanja dokumenta.
Valuta– se automatski postavlja prilikom odabira objekta proračuna.
DDS članak– naznačiti stavku novčanog toka koja odgovara vrsti plaćanja.
Komentar– ako je potrebno, navedite komentar na dešifriranje plaćanja.

Slika 6. Primjer popunjavanja kartice “Dekodiranje plaćanja”.
Kartica Distribucija naloga
Na kartici „Distribucija na račune“ naznačen je bankovni račun organizacije sa kojeg treba naplatiti sredstva. Iznos i datum plaćanja se postavljaju automatski prema podacima navedenim na kartici „Osnovno“.

Slika 7. Primjer popunjavanja kartice „Distribucija po računima“.

Slika 8. Primer automatski kreiranog dokumenta „Otpis bezgotovinskog DS” za aplikaciju sa vrstom transakcije „Plaćanje dobavljaču”.

Vraćanje uplate klijentu
Za obradu transakcija povraćaja sredstava klijentima predviđena je vrsta transakcije u dokumentu „Zahtjev za trošenje DS“ – „Vraćanje uplate klijentu“.
Sastav detalja dokumenta „Zahtjev za izdatak DS-a” kod ove vrste poslovanja je identičan sastavu podataka kod plaćanja dobavljaču, razlika je samo u vrsti druge ugovorne strane i predmetu poravnanja.

Slika 9. Obrazac dokumenta „Zahtjev za utrošak DS“, vrsta operacije „Povrat uplate klijentu“
Primalac– označava klijenta iz imenika „Counterparts“ koji treba da izvrši plaćanje.
Objekat kalkulacije– kao objekt poravnanja možete navesti „Ugovor sa drugom stranom“ (za ovu vrstu rada aplikacionog dokumenta, pri odabiru su dostupni ugovori tipa odnosa „Sa kupcem/kupcem“) ili ugovoreni dokument „ Narudžba kupaca”.
Kupac– polje se automatski popunjava prilikom odabira objekta obračuna. Instalira se element direktorija “Partneri” koji je naveden u odgovarajućem polju objekta obračuna.

Slika 10. Primjer popunjavanja kartice “Dekodiranje plaćanja”.
Nakon prolaska svih faza odobravanja, dokumentu „Zahtjev za utrošak DS“ će biti dodijeljen status „Za plaćanje“ i automatski će se kreirati dokument „Otpis bezgotovinskog DS“.



Slika 11. Primjer automatski kreiranog dokumenta “Otpis bezgotovinskog DS” na osnovu aplikacije sa tipom operacije “Povrat uplate klijentu”.

Izdavanje odgovornom
Za formalizaciju transakcija izdavanja sredstava na bankovni račun odgovornog lica predviđena je vrsta transakcije dokumenta „Zahtjev za trošenje DS” - „Izdavanje odgovornom licu”.

Slika 12. Obrazac dokumenta „Zahtjev za utrošak DS“, vrsta operacije „Izdavanje odgovornom“
Odgovorna osoba– zaposlenik je naveden iz imenika “ Pojedinci“, kome je potrebno prenijeti novac.
Izvještaj– iz predložene liste perioda potrebno je navesti period do kojeg računovođa treba da izvještava o primljenom iznosu.

Slika 13. Primjer popunjavanja kartice “Dekodiranje plaćanja”.
Nakon prolaska svih faza odobravanja, dokumentu „Zahtjev za utrošak DS“ će biti dodijeljen status „Za plaćanje“ i automatski će se kreirati dokument „Otpis bezgotovinskog DS“.


Slika 14. Primer automatski kreiranog dokumenta „Otpis bezgotovinskog DS” na osnovu aplikacije sa tipom operacije „Izdavanje odgovornom”.


1. Uvod

Planiranje gotovine jedan je od glavnih zadataka upravljačko računovodstvo za razliku od računovodstva.

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

  • Izvršiti reprogramiranje;
  • Ažuriranje planova, prenošenje prilagođavanja u naredne periode;
  • Izvršite plan – činjeničnu analizu.
Treba imati na umu da se u većini preduzeća (koja koriste 1C za automatizaciju) planiranje ne provodi u programu.
“Trebalo bi da uspostavimo računovodstvo...” – tako se mnogi raspravljaju.

Računovodstvo treba poboljšati, da, ali ne nauštrb planiranja.
Naravno, oni 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 (budžetiranje);
  • (2) Operativno.
A ako se budžetiranje (naravno, sa pristupom planiranju odozgo prema dolje) može izvršiti korištenjem XLS-a, onda se operativno planiranje ne može izvršiti.
Suština je da najčešće minimalan broj korisnika (1-2 osobe) radi sa proračunskim tablicama. Za većinu preduzeća broj budžetskih stavki i drugih analitičkih podataka nije tako velik. Odnosno, sve se može obraditi ručno 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 redovnih plaćanja, očekivanih plaćanja za narudžbine kupaca itd.

A osim toga, sve se to može "vezati" za veliki broj primarnih dokumenata, s kojim rade razni korisnici programa, prilagođavaju se dokumenti, mijenja se situacija itd.

Još jedna važna razlika između operativnog planiranja i budžetiranja je ta što ono često dolazi odozdo prema gore. Odnosno iz “Zahtjeva za d/s troškove”, koje uvijek popunjavaju službenici odjeljenja.

I ove prijave, shodno tome, treba na vrijeme obraditi, prihvatiti/odbiti, „zakazati“ i platiti.

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

I kao rezultat planiranja, finansijsko odjeljenje / trezor treba da "vidi" u sistemu:

  • Kada, kome, sa kog bankovnog računa/gotovina, za koji iznos se mora platiti;
  • Kakvo će biti stanje gotovine na „takav i takav“ datum, uzimajući u obzir tekuća stanja, planirane troškove i novčane primitke. Mora se izbjegavati tzv. "cash gaps"

    Odnosno, postoji potreba za radom sa kalendarom plaćanja.

  • Koliki će dug prema drugim ugovornim stranama biti na navedene datume, uzimajući u obzir planirana plaćanja, primitke i trenutni saldo međusobnih obračuna.

    Odnosno, postoji potreba za radom sa kalendarom obračuna.

Svrha ovog članka – govoriti o mogućnostima automatizacije operativnog planiranja za d/c. Istovremeno će se to i realizovati komparativna analiza 3 različite cirkulacijske konfiguracije (dvije su standardne iz 1C, jedna je specijalizirana iz savjeta kompanije).

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

2. Karakteristike soft startera 1.3

On ovog trenutka 1C još nije objavio dugo očekivani novo izdanje UPP (rev. 2). I iz tog razloga, fokusiraćemo se na ono što je dostupno - odgovarajuće podsisteme SCP 1.3:

Mora se napomenuti da je podsistem „Zahtjevi za utrošak gotovine“ ažuriran u konfiguraciji relativno nedavno (2011). I kao rezultat toga, u režimu upravljanog interfejsa, stavka „Zahtjevi za trošenje d/s/” pojavila se na panelu odjeljka.


Ako pokušate u standardnoj konfiguraciji, u načinu datoteke, otvoriti obrazac dokumenta “Zahtjev za troškove D/s” (aka, ZRDS), tada se odmah pojavljuje greška za varijablu “Globalne vrijednosti” iz opšteg modula “Rad sa Opšte varijable”.

Takve greške se, međutim, mogu ispraviti, kako kažu: „talog ostaje“. Odnosno, u podsistemu UPP ZRDS ima dovoljno „hrapavosti“.
Mogućnost izrade ZRDS dokumenta putem WEB pretraživača je korisna, ali u praksi ćete morati dobro razmisliti o pojednostavljenju i ergonomiji standardni obrazac dokument. Ovo će biti posebno važno za mobilne uređaje.

Ali što se tiče kalendara plaćanja, u načinu rada tankog klijenta, daljinski preko WEB pretraživača itd. nećete ga moći koristiti. Razlog je taj što podsistem Upravljanje gotovinom već duže vrijeme nije ažuriran, a posebno izvještaj Kalendar plaćanja nije izgrađen na sistemu sastavljanja podataka. Stoga se ovaj izvještaj ne može koristiti u tankim klijentima, ne postoji mogućnost kreiranja prilagođenih postavki za njega.

U radu sa ZRDS-om značajno mjesto zauzimaju propisi za koordinaciju i odobravanje prijava. U zavisnosti od organizacijske strukture preduzeća i drugih poslovnih karakteristika, interna procedura za odobravanje prijava (propisi o odobrenju) može biti prilično složena (višestepena, varijabilna, itd.). Dakle, ovo nije lak zadatak za automatizaciju.

U UPP-u je implementiran podsistem koordinacije i odobravanja. Pruža prilično fleksibilna podešavanja.

  • Odobrenje je potvrda o potrebi plaćanja aplikacije. Obično odobrenje mora ići preko šefova odjela, menadžera i drugih odgovorna lica kompanije.
  • Odobrenje je konačna potvrda (od strane blagajnika) da će prijava biti plaćena. U tom slučaju potrebno je odrediti datum plaćanja i bankovni račun/blagajnu sa koje će se izvršiti uplata. Dakle, plaćanje spada u operativni plan (kalendar plaćanja).
Mora se napomenuti da brojni aspekti standardne funkcionalnosti soft startera ne pružaju ono što je potrebno za stvarnu implementaciju podsistema.
O ovim "trenucima" ću pisati kasnije, ali za sada pogledajmo koju funkcionalnost tipična konfiguracija pruža.
  1. Možete omogućiti korištenje mehanizma odobravanja aplikacije zasebno za svaku organizaciju.

  • Moguće je konfigurirati slijed aplikacije kroz rute i hijerarhiju ruta.
  1. Treba napomenuti da se hijerarhija u direktoriju odjela ne uzima u obzir u mehanizmima usmjeravanja aplikacija.
  2. Također je potrebno poništiti da su koordinacija i odobrenje tehnički konstruirani bez korištenja mehanizma poslovnog procesa.

  • U svakom trenutku možete odrediti jednog/više korisnika kojima će biti dostupno odobrenje aplikacije. Odnosno, aplikaciju može odobriti bilo koji od njih (ko to prvi uspije).

  • Za svako odjeljenje možete dodijeliti odgovarajuću točku rute odobrenja. Suština ovoga je sljedeća: prilikom popunjavanja prijave (ZRDS) mora se navesti Centralni federalni okrug (podjela). I ovisno o navedenoj podjeli, UPP „pronađe“ odgovarajuću tačku odobrenja i „šalje“ zahtjev na odobrenje do ove točke.

Također je moguće ne specificirati odjel prilikom postavljanja puta za odobrenje. U ovom slučaju, takva koordinaciona točka će se „primijeniti“ na sve CFD-ove za koje odgovarajuća točka rute nije posebno naznačena.

  1. Samo odobrenje se vrši posebnom obradom "Odobrenje prijave"

  1. Analiza planirane raspoloživosti sredstava, rasporeda plaćanja i praćenje gotovinskih praznina vrši se u izvještaju „Kalendar plaćanja“.

Pored planirane potrošnje d/s (ZRDS), možete uzeti u obzir i planirani prijem d/s. U ove svrhe je omogućena registracija poseban dokument“Planirani prijem d/s.”


Treba napomenuti da iako dokument „Planirani prijem d/c“ ima stanja (pripremljeno, usaglašeno i sl.), ne postoji mogućnost usaglašavanja ovog dokumenta (kao ni ZRDS). Odnosno, promena statusa dokumenta je moguća samo u režimu „ručne kontrole“.

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

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

  1. Pored izvještaja Kalendar plaćanja, postoji izvještaj Analiza raspoloživosti gotovine.

Istovremeno, moguće je rezervisati d/s (na osnovu zahtjeva za rashode) ili postaviti prijave prema planiranim prihodima.

Tu je i funkcionalnost za zatvaranje ZRDS-a i planiranih prihoda od d/s. U ove svrhe, u režimu „redovnog klijenta“ daju se dokumenti „Zatvaranje zahteva za izdatke/priznake“.

Međutim, ova funkcionalnost također nije podržana u načinu rada tankog/web klijenta.
Ovdje morate shvatiti da je tehnika “tvrde rezervacije” snažno vezana za hronologiju unosa dokumenta, a to otežava prilagođavanja i reprogramiranje.

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


Dakle, razmotrili smo funkcionalnost soft startera i sada ću navesti one aspekte standardne konfiguracije koji se u praksi, na projektima, moraju mijenjati:

  1. Prema dokumentu “Zahtjev za izdatke d/s”:
    1. U dokumentu možete navesti „Odjel“ (usput, u konfiguraciji je označen kao Centralni federalni okrug - centar finansijske odgovornosti). Ali sasvim je moguće da se prijava podnosi iz jednog odjeljenja (CFD), iu ovom slučaju će se troškovi morati dalje pripisati/raspodijeliti na drugi odjel(e) (CFD – centri za financijsko upravljanje).

      Mogućnost specificiranja digitalnih funkcija itd. - odsutan.

      Ne postoji mogućnost promjene rute ili preusmjeravanja aplikacije na druge rute.

    1. Ne postoji mogućnost planiranja prenosa gotovine između tekućih računa, sa računa na blagajnu i sl.
  1. Proces dogovora:
    1. Moguće je koordinirati ZRDS, ali ne postoji mogućnost koordinacije planiranog prijema d/s.
    2. U praksi postaje neophodno izvršiti odobrenja za druge zaposlene. Istovremeno, sistem takođe treba da evidentira informacije o tome „ko je izvršio odobrenje i za koga“.

      Opcija instaliranja više mogućih izvršitelja na jednoj tački koordinacije često nije prikladna, pa se ovaj izvršilac može naznačiti u drugim fazama koordinacije. Kao rezultat, sve to će dovesti do činjenice da će zaposleni istovremeno imati i glavne i indirektne zadatke odobravanja na listi zahtjeva za odobrenje. Naravno, ovo zbunjuje korisnika i nije zgodno.

      Da rezimiramo, sposobnost koordinacije za drugog izvođača, sposobnost da se naznači ko ima pravo da koordinira za koga je odsutan.

    3. U procesu odobravanja prijava, kada se aplikacija prosljeđuje na odobrenje sljedećem duž rute, traži se funkcionalnost automatskog obavještavanja (e-mailom) sljedećeg izvršitelja, kao i autora aplikacije. .
    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ši mogući nivo. Međutim, to nije predviđeno UPP-om.
    • Svi gore navedeni zahtjevi, iako nisu uključeni u standardnu ​​konfiguraciju, ipak su .
  1. Izvještaji, prava pristupa.
    1. Traži se mogućnost ograničavanja pristupa aplikacijama samo dostupnim autorima/izvođačima (koordinatorima); po odjelima dostupnim korisniku.
    2. Ne postoji izvještavanje o praćenju (po danima i intervalima) stvarnog i planiranog duga. Ovo važi i za kupce i za dobavljače.
    3. Izvještavanje i neke od funkcionalnosti nisu prikladne za rad u načinu rada tankog/web klijenta.
  2. Računovodstvo redovnih ugovora i ugovora.
    1. Često se dešavaju situacije kada je potrebno redovno plaćati dobavljače. Na primjer, plaćanja najma itd.

      UPP to ne odražava automatski u kalendaru plaćanja itd. ove predstojeće troškove. Odnosno, potrebno je ručno pratiti takva plaćanja i popunjavati zahtjeve za plaćanje, što je nezgodno i dugotrajno.

    2. Ugovorima sa kupcima i dobavljačima mogu se predvideti uslovi za procenat avansa, rokove plaćanja itd.

      UPP ne bilježi automatski sve ove informacije i (kao rezultat toga) ih automatski odražava u kalendaru plaćanja.

3. Karakteristike UT 11.1

Sa izdavanjem nove konfiguracije „Upravljanje trgovinom Rev.11“, pojavile su se mnoge nove, korisne karakteristike za zadatke operativnog planiranja i finansijske kontrole.
Možda najznačajnija stvar u ovom dijelu u UT11 (u poređenju sa UPP 1.3) je mehanizam za obračun rasporeda plaćanja. Ovaj mehanizam „zatvara“ ono što je jako 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 računa, a pritom će se kalendar plaćanja normalno formirati.

Možete poništiti da “standardna podešavanja” izvještaja “Kalendar plaćanja” ne ispunjavaju očekivanja (kao takav, kalendar se ne prikazuje), ali u korisničkom modu možete dodati grupisanje po “datumu plaćanja” i izvještaju će se generirati u uobičajenom obliku.



Funkcionalnost izvještaja je znatno proširena (u poređenju sa SCP 1.3) zbog upotrebe sistema za sastavljanje podataka. Sada se izvještaj može generirati u tankom/web klijentu, pohraniti u bazu podataka i dodijeliti različitim korisnicima potrebne postavke.

Pored planiranja potrošnje i prijema robe za domaćinstvo, UT11 sada ima i funkcionalnost planiranja kretanja robe za domaćinstvo. U ove svrhe možete sastaviti dokumente „Nalog za preseljenje domaćinstava“.

U poređenju sa UPP 1.3 za dokument „Zahtjev za utrošak 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, dostavlja se izvještaj “ Potraživanja" Ako je potrebno, možete kreirati i kalendar dugova. Da biste to učinili, u prilagođenom načinu rada trebate dodati grupiranje po datumima plaćanja.


Nažalost, UT11 (kao i ranije) ne pruža mogućnost analize kalendara dugova po dobavljačima. Međutim, UT11 treba biti finaliziran za ovaj zadatak.

Da rezimiramo: nova metodološka rješenja "1C", zajedno sa mogućnostima platforme 8.2, daju dobru osnovu za automatizaciju zadataka operativnog planiranja i upravljanja d/s.

Ali u isto vrijeme, morate razumjeti da konfiguracija UT11 nije potpuna, gotovo rešenje za automatizaciju trezora i finansijskog planiranja.

  • Prvo, UT11 implementira u vrlo pojednostavljenom obliku mehanizam za koordinaciju/odobravanje zahtjeva za troškove i drugih planskih dokumenata d/s. Odnosno, ne postoje mehanizmi rutiranja, proces odobravanja aplikacija je sveden na jednostavno postavljanje statusa.
  • Drugo, UT11 nema podsistem budžetiranja i (kao rezultat toga) ne postoji funkcionalnost za praćenje aplikacija za planirane budžete.
4. WA karakteristike: Financier

Istorijski gledano, konfiguracija WA:Financier je razvijena na osnovu proizvoda Treasury Management.

U isto vrijeme, novo “Financier” rješenje kompanije WiseAdvice također uključuje:

  • podsistem planiranja budžeta;
  • Podsistem upravljanja ugovorima;
  • Podsistem za formiranje i računovodstvo stvarnih plaćanja;
  • Fleksibilan, prilagodljiv mehanizam za generisanje/popunjavanje dokumenata na osnovu šablona;
  • Fleksibilan, prilagodljiv integracijski podsistem klijent-banka.
Razmotrimo glavnu funkcionalnost "WA: Financier" u smislu riznice - od uzimanja u obzir uslova ugovora do kreiranja kalendara plaćanja.









  1. Tokom procesa odobravanja aplikacije, ne možete samo odobriti/odbiti dokument (kao što je učinjeno u UPP), već su dostupne i druge funkcije: na primjer, poslati dokument na reviziju ili zatražiti dodatne informacije. informacije.

    Cijeli ovaj proces je automatiziran, te se shodno tome obezbjeđuje izvještavanje o statusu obrade dokumenta.




5. Rezultati


Zaključci:

  1. Automatizovati rad finansijskih odeljenja, trezora, organizacija sa složenim organizacionim strukturama. strukture je najpogodnije rješenje "WA: Finansijer".

    Ovo rješenje se dugo razvijalo i razvijalo, akumulirajući specifičnosti i zahtjeve različitih finansijskih institucija. odeljenja i trezora. Ukupni troškovi rada za razvoj rješenja iznosili su više od 5.000 osoba/sati.

    Prednost WA: Financier rješenja je njegova napredna funkcionalnost i veliki broj mehanizama podešavanja programa. 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 tipične konfiguracije, tada integracija u postojeću strukturu (razmjena podataka sa bazama podataka UT, UPP, Kompleksnaya, Bukh) neće biti teška.

  2. Za automatizaciju finansijskog odjela/trezora u okviru sveobuhvatnog projekta automatizacije najbolje rešenje je na osnovu UPP.

    Istovremeno, morate shvatiti da će funkcionalnost soft startera zahtijevati poboljšanja.

    Specifičnosti, finansijski zahtjevi. odjeli i trezori nisu toliko duboko ugrađeni u UPP kao što je to učinjeno u zasebnim, specijalizovanim rješenjima.

    Stoga bi implementacija SCP-a za ove zadatke trebala biti izvedena samo kao dio projekta automatizacije.

  3. Za velike organizacije, za automatizaciju odjela trezora UT11 ne odgovara.

    IN ovu odluku Prvo, ne postoje mehanizmi za koordinaciju/odobravanje planskih dokumenata.

    Drugo, ne postoji budžetski podsistem i kontrola izvršenja budžeta tokom operativnog planiranja.

    Međutim, UT11 savršeno za automatizacija (uključujući operativno planiranje d/c) mali finansijski odeljenja kompanije.