Plasarea cererilor de plată zilnică în 1s. Cereri pentru cheltuirea fondurilor. Cum se înregistrează faptul de a transfera fonduri din contul curent al companiei în contul curent al furnizorului

Posibilitatea de a menține un calendar de plăți în 1C 8.3 și 8.2 este disponibilă în mai multe configurații standard:

• 1C Enterprise Accounting 8.3 (3.0)
• 1C Managementul întreprinderii de producție
• 1C ERP Enterprise Management 2.0
• 1C Automatizare integrată
• 1C Managementul comerțului 11 și 10.3
• 1C Managementul unei companii mici

Calendarul de plată este implementat sub forma unui raport (Fig. 1).

Raportul afișează date despre încasările planificate, cheltuielile și soldurile DS. Informațiile pot fi detaliate până la documentele primare (Fig. 2).

Un exemplu de lucru cu un calendar de plăți în 1C Trade Management

Să ne uităm la un exemplu pentru configurația 1C Trade Management 11 și noile caracteristici care au apărut în cele mai recente versiuni.

În primul rând, trebuie să finalizați setările. Pentru a face acest lucru, în secțiunea „Administrare - Organizații și fonduri”, activați caseta de selectare „Solicitări de cheltuire a fondurilor” (Fig. 3). În alte versiuni, această casetă de selectare poate fi găsită în secțiunea „Trezorerie”.

În aceeași secțiune, puteți configura controlul limitelor pentru organizație în ansamblu sau pentru fiecare divizie.

După ce setările au fost finalizate, secțiunea „Planificare de numerar” apare în secțiunea „Finanțe” (Fig. 4). În alte versiuni, aceasta poate fi secțiunea „Trezorerie”.

Să introducem mai multe solicitări de cheltuieli. Acest document este cheie pentru organizarea controlului operațional al traficului de vehicule. Să-l privim mai detaliat (Fig. 5).

Obțineți 267 de lecții video pe 1C gratuit:

În primul rând, trebuie să selectați o operație de document. În exemplul nostru, acesta este „Transfer fiscal”. Depinde de operațiunea selectată. Programul va spune utilizatorului ce articol poate fi folosit într-un anumit caz (lista de articole va fi filtrată în funcție de operațiune).

Deoarece controlul limită este activat în setări, programul a blocat postarea documentelor. Pentru a aproba o astfel de cerere, trebuie fie să activați caseta de selectare „Depășire limită”, fie să măriți limita pentru acest articol.

Limitele sunt stabilite în documentul „Limite de cheltuieli în numerar” (Fig. 6). Perioada este stabilită nu în momentul generării cererii, ci în momentul plății planificate. În exemplul nostru, cererea este depusă în iulie, dar limita este stabilită pentru august.

Documentul „Cerere pentru consum DS” are mai multe stări:

• Nu a fost de acord
• De acord
• A plăti
• Respins.

Toate aplicațiile necoordonate pot fi văzute în jurnalul „Solicitări de cheltuire a DS pentru aprobare” (Fig. 7). Este convenabil să aprobi aplicațiile direct din această listă.

Acum să creăm un calendar de plăți și să evaluăm situația.

Figura 8 prezintă raportul pentru august 2016. Afișează diferențele de numerar în roșu. Conform cererii nr. TDTSU-000003 08/04/2016, este obligat să plătească pentru achiziționarea mijloacelor fixe, dar nu sunt suficienți bani pentru această dată.

Spre deosebire de calendarul de plăți al versiunilor anterioare (Fig. 1), acum este posibil să generați documente de transfer sau chitanțe planificate ale DS direct din raport.

În Fig. 9 vedem documentul „Chitanță așteptată DS”, generat de butonul „Chitanță” direct din calendarul de plăți. Pentru a închide decalajul de numerar, trebuie să selectați corect articolul DDS și data planificată de primire.

Puteți configura sistemul astfel încât toate (sau anumite) plăți să fie procesate numai sub rezerva creării și aprobării obligatorii a unei cereri de fonduri. Acest lucru este reglementat de opțiunea funcțională Cereri pentru cheltuirea fondurilor:

Dacă opțiunea este activată, atunci pentru fiecare este configurată obligația de a plasa comenzi contul bancar al organizației:

La crearea unei aplicații, funcționarea acesteia este indicată:

Și, de asemenea, forma de plată:

Cererile pentru cheltuirea DS pot fi create fie manual, fie pe baza de comenzi, standarde de formare profesională și alte documente. La rândul său, pe baza aplicațiilor, puteți crea ștergere de DS fără numerar, decontări în numerar și alte documente.

Întrebarea 1.14 a examenului 1C: ERP Professional Enterprise Management 2.0. Interdicția de anulare a fondurilor fără documentul „Cerere de plată”:

1. Definit în setările utilizatorului
2. Definit în drepturi suplimentare de utilizator
3. Determinat de rolul utilizatorului
4. Determinat pentru fiecare cont individual

Verificat. Răspunsul corect este al patrulea, vezi mai sus pentru analiză.

Întrebarea 8.5 a examenului 1C: ERP Professional Enterprise Management 2.0. Documentul „Cerere de cheltuire a fondurilor” poate fi întocmit în funcție de tipurile de tranzacții pentru cheltuirea fondurilor:

1. Transfer de fonduri pentru plata impozitelor
2. Transferul de fonduri între organizația-mamă și divizii separate
3. Înregistrarea unei tranzacții de conversie valutară
4. Transfer de fonduri pentru plata cheltuielilor vamale
5. Opțiunile 1 sau 4
6. Opțiunile 1 sau 2 sau 3 sau 4

Verificat. Răspunsul corect este numărul șase, vezi operațiunile disponibile mai sus.

Întrebarea 8.8 a examenului 1C: ERP Professional Enterprise Management 2.0. Documentul „Cerere de cheltuire a fondurilor” poate fi întocmit în funcție de tipurile de tranzacții pentru cheltuirea fondurilor:

1. Transfer la furnizor
2. Emiterea salariilor
3. Transferul de fonduri către bancă
4. Opțiunile 1 sau 2
5. Opțiunile 1 sau 2 sau 3

Verificat. Răspunsul corect este al patrulea. Livrarea fondurilor către bancă nu se formalizează printr-o cerere, dar Ordin de mutare a DS-ului.

Întrebarea 8.10 a examenului 1C: ERP Professional Enterprise Management 2.0.

1. Fără numerar
2. Numerar sau fără numerar
3. Card de plată
4. Opțiunile 1 sau 2
5. Opțiunile 1 sau 3
6. Opțiunile 1 sau 2 sau 3

1. Bani gheata
2. Card de plată
3. Document de bani
4. Opțiunile 1 sau 2
5. Opțiunile 1 sau 3
6. Opțiunile 1 sau 2 sau 3

Verificat. Răspunsul corect este al patrulea.

Întrebarea 8.14 a examenului 1C: ERP Professional Enterprise Management 2.0. Documentul „Cerere de cheltuire a fondurilor” poate fi introdus:

1. Pe baza documentului "Comandă către furnizor"
2. Pe baza documentului „Recepția de bunuri și servicii”
3. Opțiunile 1 și 2 în funcție de stadiul documentelor justificative
4. Din raportul „Calendarul plăților”.
5. Opțiunile 1 și 2 și 4
6. Opțiunile 3 și 4

Verificat. Răspunsul corect este numărul cinci. Sa luam in considerare. Pe baza Comenzii către furnizor, cererea este introdusă fără probleme, în ciuda statutului Neacordat și a plății după livrare (care nu a avut loc încă):

iată aplicația:

Școlile profesionale nu au deloc statut; Aplicația poate fi introdusă și fără probleme:

Din raportul Calendar de plăți, nu există o opțiune directă pentru crearea aplicațiilor, dar puteți deschide documentul de bază din raport și faceți o aplicație din acesta:

1. A plăti
2. De acord
3. Indiferent de statut

Documentul „Cererea de cheltuire a fondurilor” este destinat planificării și coordonării plăților.
Documentul „Solicitare de cheltuire DS” poate fi creat accesând secțiunea „Trezorerie” - „Planificare și control al fondurilor” - „Solicitari de cheltuire DS” - Creare.
Documentul „Cererea de cheltuieli a DS” are mai multe tipuri de operațiuni care sunt selectate în timpul creării. Fiecare tip de aplicație este destinat să reflecte o varietate de tranzacții comerciale, fiecare dintre acestea fiind descrisă în această instrucțiune.
Documentele create „Cerere de cheltuire DS” sunt colectate și agreate folosind documentul „Registrul plăților”. După aprobare, pe baza cererilor, sunt create automat documente „Stergere DS fără numerar”, care sunt încărcate la banca client pentru plata de către bancă.
Următoarele sunt exemple de execuție a documentelor „Cerere de cheltuială a DS” pentru fiecare tip de operațiune.

Plata catre furnizor
Pentru a procesa tranzacțiile de plată către un furnizor, este destinat tipului de tranzacție al documentului „Cerere de cheltuieli a DS” - „Plată către furnizor”.
În noul document „Cerere de cheltuială DS”, câmpurile care trebuie completate pentru procesarea documentului sunt marcate cu roșu. Documentul este creat în starea „Neaprobat”; starea se schimbă automat în timpul aprobării registrului de plăți. Prioritatea aplicației la creare este setată automat la „Mediu”.

Figura 1. Formular de document „Cerere de cheltuială a DS”, tipul operațiunii „Plată către furnizor” (necompletat)
Detaliile documentului „Cerere pentru DS de cheltuieli” trebuie completate după cum urmează:
Fila de bază
Număr– este generat automat în timpul execuției, nu poate fi setat manual.
Data– când este creat, data curentă este setată.
Organizare– trebuie să selectați din lista de organizații propusă folosind butonul, sau introducând numele în câmp, se va oferi spre selecție valoarea cerută.
Subdiviziune– din directorul „Structura Întreprinderii”, trebuie să selectați diviziunea pentru care trebuie să aibă loc plata.
Solicitant– implicit, este indicat utilizatorul curent al sistemului care creează aplicația.
Planificare– setarea implicită este „În moneda de plată” și nu poate fi modificată.
Sumă– indică suma plății solicitate.
Valută– indicați moneda plății solicitate.
Operațiune– se reflectă tipul de tranzacție al documentului „Cerere de cheltuieli a DS” selectat în timpul creării
Data de plată– indică data la care trebuie programată plata către furnizor.
Forma de plata– setarea implicită este „În orice formă” și nu poate fi modificată.
Destinatar– indică furnizorul din directorul „Contrepărți” căruia trebuie efectuată plata.
Contul destinatarului– la selectarea „Destinatar”, contul destinatarului este setat automat dacă este necesar, dacă pe „Factura de plată” furnizată de furnizor este indicat un alt cont, trebuie să îl selectați pe cel solicitat din directorul „Conturi bancare”.
Peste limită– în cazul în care sistemul menține un sistem de limitare a cheltuielilor de numerar în contextul sucursalelor și, respectiv, al elementelor de flux de numerar, dacă valoarea plății efectuate nu a fost inclusă anterior în limită, la postarea documentului utilizatorul va primi un mesaj de eroare iar cererea nu va fi procesată.

Figura 2. Un exemplu de eroare la plasarea unei comenzi pentru care nu a fost planificată o limită.
Pentru a plasa o comandă peste limită, trebuie să setați indicatorul „Depășire limită”.
Transfer la buget– acest steag este setat dacă plata este un transfer către buget. Setarea steagului vă permite să introduceți valorile KBK, OKTMO etc. necesare pentru plățile către buget.

Figura 3. Exemplu de setare a steagului „Transfer la buget”.
UIP– un identificator unic de plată, indicat numai dacă acest lucru este prevăzut în contractul cu beneficiarul plății.
Scopul plății- programul oferă mai multe opțiuni pentru completarea automată a scopului plății folosind butonul „Inserare”.

Figura 4. Opțiuni pentru completarea automată a câmpului „Scopul plății”.
Lista documentelor, incl. TVA- va afișa informații despre obiectele de decontare din fila „decriptare plăți”.

Incl. TVA (18%) (pentru intreaga suma), incl. TVA (10%) (pentru întreaga sumă), Fără taxe (TVA)- La textul introdus vor fi adăugate informații despre TVA.

Text din contul bancar al destinatarului- introduce textul specificat în câmpul „Text scop plată” din cardul de cont al contrapărții.

Figura 5. Exemplu de completare a filei „De bază”.

Fila Detalii de plată
Fila „Decodare plăți” oferă informații detaliate despre plată și decontările reciproce cu beneficiarul.
Plata poate fi introdusă ca listă, de ex. distribuiți peste mai multe obiecte de calcul, sau fără împărțire, este posibil să selectați un singur obiect de calcul.
Plata din fondurile de apărare ale statului– steagul este fixat numai dacă plata are loc în cadrul unui ordin al guvernului de apărare, în alte cazuri steagul nu este pus.
Obiect de calcul– ca obiect de decontare, se poate specifica „Acord cu contrapartea” (pentru acest tip de operațiune a documentului de aplicare, la selectare, sunt disponibile acorduri cu tipul de relație „Cu furnizorul/executantul”) sau documentul convenit „Comanda către furnizor”.
Furnizor
Valoarea decontărilor reciproce– este setat automat la postarea unui document.
Valută– este setat automat la selectarea unui obiect de calcul.
articol DDS– indicați elementul fluxului de numerar corespunzător tipului de plată.
Un comentariu– dacă este necesar, indicați un comentariu privind decriptarea plății.

Figura 6. Exemplu de completare a filei „Decodare plăți”.
Fila de distribuție a contului
În fila „Distribuire către conturi”, este indicat contul bancar al organizației din care ar trebui să fie debitate fondurile. Suma și data plății sunt setate automat în funcție de datele specificate în fila „De bază”.

Figura 7. Exemplu de completare a filei „Distribuire pe conturi”.

Figura 8. Un exemplu de document creat automat „Anularea DS fără numerar” pentru o aplicație cu tipul de tranzacție „Plată către furnizor”.

Returnarea plății către client
Pentru a procesa tranzacțiile de rambursare către clienți, este destinat tipului de tranzacție din documentul „Cerere de cheltuieli DS” - „Returul plății către client”.
Compoziția detaliilor documentului „Cerere de cheltuială DS” cu acest tip de operațiune este identică cu compoziția detaliilor la plata furnizorului, singura diferență este în tipul de contraparte și obiectul decontării.

Figura 9. Forma documentului „Cerere de cheltuială DS”, tipul operațiunii „Returul plății către client”
Destinatar– indică clientul din directorul „Contrepărți” care trebuie să efectueze plata.
Obiect de calcul– ca obiect de decontare, se poate specifica „Acord cu contrapartea” (pentru acest tip de operațiune a documentului de cerere, la selectare, sunt disponibile acorduri cu tipul de relație „Cu cumpărătorul/clientul”) sau documentul convenit „ Comanda clientului".
Cumpărător– câmpul este completat automat la selectarea unui obiect de calcul. Este instalat elementul de director „Parteneri” specificat în câmpul corespunzător al obiectului de calcul.

Figura 10. Exemplu de completare a filei „Decodare plăți”.
După parcurgerea tuturor etapelor de aprobare, documentului „Cerere de cheltuială DS” i se va atribui statutul „Pentru plată” și va fi creat automat documentul „Stergere DS fără numerar”.

Figura 11. Un exemplu de document creat automat „Anularea DS fără numerar” pe baza unei aplicații cu tipul de operațiune „Returul plății către client”.

Emiterea către responsabil
Pentru a înregistra tranzacții pentru emiterea de fonduri într-un cont bancar al unei persoane responsabile, este destinat tipului de tranzacție al documentului „Cerere de cheltuire DS” - „Emisiune către persoana responsabilă”.

Figura 12. Forma documentului „Cerere de cheltuială DS”, tipul operațiunii „Problemă către responsabil”
Persoana responsabila– indică angajatul din directorul „Persoane fizice” căruia îi trebuie transferați și raportați banii.
Raport– din lista de perioade propusă este necesar să se indice perioada până la care contabilul trebuie să raporteze asupra sumei primite.

Figura 13. Exemplu de completare a filei „Decodare plăți”.
După parcurgerea tuturor etapelor de aprobare, documentului „Cerere de cheltuială DS” i se va atribui statutul „Pentru plată” și va fi creat automat documentul „Stergere DS fără numerar”.

Figura 14. Un exemplu de document creat automat „Stergere DS non-cash” pe baza unei aplicații cu tipul de operațiune „Issue to the accountable”.

1. Introducere

Planificarea numerarului este una dintre sarcinile principale ale contabilității de gestiune, spre deosebire de contabilitatea financiară.

Desigur, există și alte diferențe semnificative între management și contabilitate (cerințe diferite pentru analiză, pentru evaluarea și reevaluarea activelor/pasivelor, necesitatea creării de rezerve etc.), dar nevoia de a rezolva problemele de planificare este cea mai dificilă dintre lor.
Complexitatea planificării constă nu numai în pregătirea planului (calcularea lui, formarea lui în funcție de diferite scenarii), dar este și necesar:

• Efectuează reprogramarea;
• Actualizarea planurilor, transferul ajustărilor la perioadele ulterioare;
• Efectuați un plan - o analiză faptică.

Contabilitatea trebuie îmbunătățită, da, dar nu în detrimentul planificării.
Desigur, ei încă fac planificare (dar nu în 1C, ci în XLS). Și prima sarcină principală (pe care încearcă să o rezolve) este planificarea numerarului.

• (1) Strategic (bugetare);
• (2) Operațional.

Dar în ceea ce privește planificarea operațională a d/c, situația aici este diferită. Adică există adesea un număr mare de facturi de plătit, multe plăți regulate, plăți așteptate pentru comenzile clienților etc.

Și, în plus, toate acestea pot fi „legate” de un număr mare de documente primare cu care lucrează diverși utilizatori ai programului, documentele sunt ajustate, situația se schimbă etc.

O altă diferență importantă între planificarea operațională și bugetare este că aceasta vine adesea de jos în sus. Adică din „Cereri de cheltuieli d/s”, care se completează întotdeauna de angajații departamentului.

Și aceste cereri, în consecință, trebuie să fie procesate la timp, acceptate/respinse, „programate” și plătite.

Total: planificarea operaţională pentru d/s este chiar prima sarcină de planificare, care ar trebui să fie automatizat în 1C pentru orice întreprindere.

Și ca urmare a planificării, departamentul financiar / trezoreria ar trebui să „vadă” în sistem:

• Când, cui, din ce cont bancar/numerar, pentru ce sumă trebuie plătită;
• Care va fi soldul de numerar la data „cutare și așa”, ținând cont de soldurile curente, cheltuielile planificate și încasările de numerar. Așa-numitele trebuie evitate. "dispoziții de numerar"

  Adică, este nevoie de a lucra cu calendarul de plăți.

• Ce datorie cu contrapartidele vor fi la datele specificate, luând în considerare plățile planificate, încasările și soldul curent al decontărilor reciproce.

  Adică, este nevoie de a lucra cu calendarul de calcul.

Fiecare dintre configurații poate fi utilizată pentru a rezolva problemele de planificare operațională, dar ar trebui făcută o alegere echilibrată pe baza domeniului și a dimensiunii proiectului dumneavoastră.

2. Caracteristici soft starter 1.3

Momentan, 1C nu a lansat încă noua ediție mult așteptată a UPP (reviziunea 2). Și din acest motiv, ne vom concentra pe ceea ce este disponibil - subsistemele corespunzătoare din SCP 1.3:

Trebuie remarcat faptul că subsistemul „Solicitări pentru Cheltuieli de numerar” a fost actualizat în configurație relativ recent (2011). Și ca urmare, în modul de interfață gestionată, în panoul de secțiuni a apărut elementul „Solicitări de cheltuieli d/s/”.

Dacă încercați într-o configurație standard, în modul fișier, să deschideți formularul de document „Solicitare cheltuieli D/s” (aka, ZRDS), atunci apare imediat o eroare pentru variabila „Valori globale” din modulul general „Se lucrează cu Variabile generale”.

Astfel de erori pot fi corectate, totuși, după cum se spune: „sedimentul rămâne”. Adică, există suficiente „rugozi” în subsistemul UPP ZRDS.
Posibilitatea de a întocmi un document ZRDS printr-un browser WEB este utilă, dar în practică va trebui să vă gândiți cu atenție la simplificarea și ergonomia formei standard a documentului. Acest lucru va fi deosebit de important pentru dispozitivele mobile.

Dar în ceea ce privește calendarul de plăți, în modul thin client, de la distanță prin intermediul unui browser WEB etc. nu o vei putea folosi. Motivul este că subsistemul Cash Management nu a fost actualizat de mult timp și, în special, raportul Calendar de plăți nu este construit pe un sistem de compunere a datelor. Prin urmare, acest raport nu poate fi utilizat în clienții subțiri, nu există nicio modalitate de a crea setări personalizate pentru el.

Când lucrați cu ZRDS, un loc important îl ocupă reglementările pentru coordonarea și aprobarea aplicațiilor. În funcție de structura organizatorică a întreprinderii și de alte caracteristici ale afacerii, procedura internă de aprobare a cererilor (regulamente de aprobare) poate fi destul de complexă (în mai multe etape, variabilă etc.). Deci, aceasta nu este o sarcină ușoară pentru automatizare.

În UPP este implementat subsistemul de coordonare și aprobare. Oferă setări destul de flexibile.

• Aprobarea este confirmarea necesității de a plăti cererea. De obicei, aprobarea trebuie să treacă prin șefii de departamente, managerii și alte persoane responsabile ale companiei.
• Aprobarea este confirmarea finală (de către Trezorier) că cererea va fi plătită. În acest caz, trebuie stabilită data plății și contul bancar/casierul de la care se va efectua plata. Astfel, plata se încadrează în planul operațional (calendarul de plăți).

1. Puteți activa utilizarea mecanismului de aprobare a aplicației separat pentru fiecare organizație.

• Este posibilă configurarea secvenței aplicației prin rute și ierarhia rutelor.

1. De menționat că ierarhia din directorul departamentului nu este luată în considerare în mecanismele de rutare a aplicațiilor.
2. De asemenea, este necesar să se anuleze că aprobarea și aprobarea au fost construite din punct de vedere tehnic fără utilizarea unui mecanism de proces de afaceri.

• La fiecare punct, puteți specifica unul/mai mulți utilizatori pentru care va fi disponibilă aprobarea aplicației. Adică aplicația poate fi aprobată de oricare dintre ei (oricine reușește să o facă primul).

• Pentru fiecare departament, puteți aloca un punct de rută de aprobare corespunzător. Esența acesteia este aceasta: la completarea unei cereri (ZRDS), trebuie să fie indicat Districtul Federal Central (diviziunea). Și în funcție de diviziunea specificată, UPP „găsește” punctul de aprobare corespunzător și „trimite” cererea de aprobare la acest punct.

De asemenea, este posibil să nu specificați un departament la configurarea rutei de aprobare. În acest caz, un astfel de punct de coordonare va fi „aplicat” tuturor CFD-urilor pentru care punctul de rută corespunzător nu este indicat în mod specific.

1. Aprobarea în sine se realizează folosind o procesare specială „Aprobarea cererii”

1. Analiza disponibilității planificate a fondurilor, programul de plată și urmărirea lipsurilor de numerar se realizează în raportul „Calendarul de plăți”.

Pe lângă consumul planificat de d/s (ZRDS), puteți lua în considerare și primirea planificată de d/s. În aceste scopuri, se are în vedere întocmirea unui document special „Încasare planificată a veniturilor”.

Trebuie remarcat faptul că, deși documentul „Primirea planificată a d/c” are stări (pregătit, convenit etc.), nu există posibilitatea de a coordona acest document (precum și ZRDS). Adică, modificarea stărilor documentelor este posibilă numai în modul „control manual”.

Și în UPP este posibil să se țină cont de primirea planificată de numerar de la cumpărători fără a pregăti documente „Primire planificată de numerar”.

Adică, dacă „Comenzile clienților” sunt emise pentru un cumpărător, atunci într-un raport separat „Calendarul de plăți ținând cont de comenzi” poate fi văzută această chitanță planificată.

1. Pe lângă raportul Calendar de plăți, există un raport de analiză a disponibilității numerarului.

În același timp, este posibil să se rezerve d/c (pe baza cererilor pentru cheltuieli) sau să plaseze cereri în raport cu veniturile planificate.

Există, de asemenea, funcționalitate pentru închiderea ZRDS și venitul planificat din d/s. În aceste scopuri, în modul „client obișnuit” sunt furnizate documentele „Închidere cereri de cheltuieli/încasări”.

Cu toate acestea, această funcționalitate nu este acceptată și în modul client subțire/web.
Aici trebuie să înțelegeți că tehnica „rezervării grele” este strâns legată de cronologia introducerii documentului, iar acest lucru îngreunează ajustările și reprogramarea.

Prin urmare, funcționalitatea este lăsată în UPP mai degrabă ca o „moștenire a trecutului”, iar calendarul de plăți ar trebui utilizat pentru a analiza disponibilitatea d/c.

Deci, am luat în considerare funcționalitatea soft starter-ului și acum voi enumera acele aspecte ale configurației standard care în practică, pe proiecte, trebuie modificate:

1. Conform documentului „Cerere pentru cheltuieli d/s”:
   1. În document, puteți indica „Divizia” (apropo, în configurație este desemnat District Federal Central - centru de responsabilitate financiară). Dar este foarte posibil ca o cerere să fie depusă de la o divizie (CFD), iar în acest caz costurile vor trebui să fie atribuite/distribuite în continuare către o altă divizie(e) (CFD - centre de management financiar).

      Abilitatea de a specifica funcții digitale etc. - absent.

      Nu există posibilitatea de a schimba ruta sau de a redirecționa aplicația către alte rute.

1. Nu există posibilitatea de a planifica transferul de numerar între conturile curente, din cont la casierie etc.
1. Procesul de acordare:
   1. Este posibil să se coordoneze ZRDS, dar nu există posibilitatea de a coordona primirea planificată de d/s.
   2. În practică, devine necesar să se efectueze aprobări pentru alți angajați. În același timp, sistemul trebuie să înregistreze și informații despre „cine a efectuat aprobarea și pentru cine”.

      Opțiunea instalării mai multor executori posibili la un punct de coordonare este adesea nepotrivită, astfel încât acest executant poate fi indicat în alte etape de coordonare. Ca urmare, toate acestea vor duce la faptul că angajatul va avea simultan sarcini de aprobare principale și indirecte în lista cererilor de aprobare. Desigur, acest lucru derutează utilizatorul și nu este convenabil.

      Pentru a rezuma, capacitatea de a coordona pentru un alt interpret, capacitatea de a indica cine are dreptul de a coordona pentru cine este absent.

   3. În procesul de aprobare a cererilor, atunci când o cerere este transmisă spre aprobare la următoarea de-a lungul traseului, este solicitată funcționalitatea de informare automată (prin e-mail) a următorului executant, precum și a autorului cererii. .
   4. Dacă autorul aplicației este deja responsabil de coordonare/aprobare (în orice etapă a traseului!), atunci este destul de logic ca programul să „scurteze” automat ruta, redirecționând aplicația la cel mai înalt nivel disponibil. Cu toate acestea, acest lucru nu este prevăzut în UPP.
   • Toate cerințele de mai sus, deși nu sunt incluse în configurația standard, sunt totuși .

1. Rapoarte, drepturi de acces.
   1. Există o cerere pentru posibilitatea limitării accesului la aplicații numai de către autorii/interpreții disponibili (coordonatori); pe departamentele disponibile utilizatorului.
   2. Nu există nicio raportare privind monitorizarea (pe zile și intervale) a datoriei reale și planificate. Acest lucru este valabil atât pentru cumpărători, cât și pentru furnizori.
   3. Raportarea și unele dintre funcționalități nu sunt potrivite pentru lucrul în modul client subțire/web.
2. Contabilitatea acordurilor și contractelor regulate.
   1. Există adesea situații în care este necesară plata regulată a furnizorilor. De exemplu, plăți de închiriere etc.

      UPP nu o reflectă automat în calendarul de plăți etc. aceste cheltuieli viitoare. Adică, este necesar să urmăriți manual astfel de plăți și să completați cererile de plată, ceea ce este incomod și necesită multă muncă.

   2. Acordurile cu cumpărătorii și furnizorii pot prevedea condiții pentru procentul de plată în avans, termenele de plată etc.

      UPP nu înregistrează automat toate aceste informații și (ca urmare) le reflectă automat în calendarul de plăți.

Odată cu lansarea noii configurații „Trade Management Rev.11”, au apărut multe oportunități noi, utile pentru sarcinile de planificare operațională și control financiar.
Poate cel mai semnificativ lucru din această parte din UT11 (comparativ cu UPP 1.3) este mecanismul de contabilizare a programului de plată. Acest mecanism „închide” ceea ce lipsea amarnic – automatizarea planificării/contabilității în baza acordurilor și contractelor obișnuite.

Astfel, în UT11 nu trebuie să întocmiți deloc documente (dacă nu este nevoie, bineînțeles) pentru planificarea cheltuielilor și a încasărilor și, în același timp, calendarul de plăți va fi format normal.

Puteți anula faptul că „setările standard” ale raportului „Calendarul de plată” nu corespund cu adevărat așteptărilor (ca atare, calendarul nu este afișat), dar în modul utilizator puteți adăuga o grupare după „data plății” și raportul va fi generat în forma obișnuită.

Funcționalitatea raportului s-a extins foarte mult (comparativ cu SCP 1.3) datorită utilizării unui sistem de compunere a datelor. Acum, raportul poate fi generat într-un client thin/web, salvat în baza de date și atribuit diferiților utilizatori setările de care au nevoie.

Pe lângă planificarea consumului și primirii bunurilor de uz casnic, UT11 are acum funcționalitatea de planificare a mișcării bunurilor de uz casnic. În aceste scopuri, puteți întocmi documentele „Ordin de circulație a gospodăriilor”.

Față de UPP 1.3 pentru documentul „Cerere pentru cheltuieli în numerar”, numărul de tipuri de tranzacții comerciale luate în considerare a crescut:

Acum este posibil să se aprobe atât documentele „Cerere de cheltuire a fondurilor”, cât și alte ordine:

Pentru a analiza datoria pe intervale/termene limită este furnizat raportul „Conturi de creanță”. Dacă este necesar, puteți crea și un calendar de datorii. Pentru a face acest lucru, în modul personalizat ar trebui să adăugați o grupare după datele de plată.

Din păcate, UT11 (ca și până acum) nu oferă posibilitatea de a analiza calendarul datoriilor de către furnizori. Cu toate acestea, UT11 trebuie să fie finalizat pentru această sarcină.

A rezuma: Noile soluții metodologice „1C”, împreună cu capacitățile platformei 8.2, oferă o bază bună pentru automatizarea sarcinilor de planificare operațională și control al d/s.

Dar, în același timp, trebuie să înțelegeți că configurația UT11 nu este o soluție completă, gata făcută, pentru automatizarea trezoreriei și planificarea financiară.

• În primul rând, UT11 implementează într-o formă foarte simplificată un mecanism de coordonare/aprobare a cererilor de cheltuieli și a altor documente de planificare d/c. Adică nu există mecanisme de rutare, procesul de aprobare a aplicațiilor se reduce la simpla setare a stărilor.
• În al doilea rând, UT11 nu are un subsistem de bugetare și (ca urmare) nu există nicio funcționalitate pentru monitorizarea aplicațiilor pentru bugetele planificate.

Din punct de vedere istoric, configurația WA:Financier a fost dezvoltată pe baza produsului Treasury Management.

Și, în același timp, noua soluție „Financier” de la WiseAdvice include și:

• Subsistemul planificare bugetară;
• Subsistemul de management al contractelor;
• Subsistemul de formare și contabilizare a plăților efective;
• Mecanism flexibil, personalizabil pentru generarea/completarea documentelor pe baza de șabloane;
• Subsistem flexibil, personalizabil de integrare client-bancă.

1. În timpul procesului de aprobare a aplicației, nu puteți doar să aprobați/respingeți documentul (cum se face în UPP), dar sunt disponibile și alte funcții: de exemplu, trimiteți un document pentru revizuire sau solicitați informații suplimentare. informație.

   Întregul proces este automatizat în consecință, raportarea este furnizată cu privire la stadiul procesării aprobării documentelor.

5. Rezultate

Concluzii:

1. Pentru a automatiza activitatea departamentelor financiare, trezorerielor, organizațiilor cu structuri organizaționale complexe. structura solutia cea mai potrivita este „WA: Finanțator”.

   Această soluție se dezvoltă și evoluează de mult timp, acumulând în consecință specificul și cerințele diferitelor instituții financiare. departamente și trezorerie. Costul total al forței de muncă pentru dezvoltarea soluției s-a ridicat la peste 5.000 persoane/ore.

   Avantajul soluției WA: Financier este funcționalitatea sa avansată și un număr mare de mecanisme de setări ale programului. Astfel, implementarea acestei soluții este posibilă într-un timp scurt (așa-numita „implementare out-of-the-box”), fără suplimentar. dezvoltare, programare etc.

   Deoarece soluția conține mecanisme pentru schimbul bidirecțional cu toate configurațiile standard principale, integrarea în structura existentă (schimbul de date cu bazele de date UT, UPP, Kompleksnaya, Bukh) nu va fi dificilă.

2. Pentru a automatiza departamentul financiar/trezoreria în cadrul unui proiect cuprinzător de automatizare cea mai buna solutie este bazat pe UPP.

   În același timp, trebuie să înțelegeți că funcționalitatea soft starter-ului va necesita îmbunătățiri.

   Specific, cerințe financiare. departamentele și trezoreriile nu sunt încorporate în UPP la fel de profund precum se face în soluții separate, specializate.

   Astfel, implementarea SCP pentru aceste sarcini ar trebui realizată doar ca parte a unui proiect de automatizare.

3. Pentru organizațiile mari, pentru automatizarea departamentului de trezorerie UT11 nu se potriveste.

   În această decizie, în primul rând, nu există mecanisme de coordonare/aprobare a documentelor de planificare.

   În al doilea rând, nu există un subsistem de bugetare și control asupra implementării bugetelor în timpul planificării operaționale.

   Cu toate acestea, UT11 perfect pentru automatizare (inclusiv planificarea operațională d/c) financiar mic departamentele companiei.