Pianificazione operativa del flusso di cassa o come costruire un sistema di controllo del flusso di cassa. Sottosistema “applicazioni elettroniche” dei fondi di spesa Domanda dei fondi di spesa 1c upp


1. Introduzione

La pianificazione della liquidità è uno dei compiti principali della contabilità di gestione, a differenza della contabilità finanziaria.

Naturalmente, ci sono altre differenze significative tra gestione e contabilità (diversi requisiti per l’analisi, per la valutazione e rivalutazione di attività/passività, la necessità di creare riserve, ecc.), ma la necessità di risolvere problemi di pianificazione è la più difficile da affrontare. loro.
La complessità della pianificazione non sta solo nel preparare il piano (calcolandolo, formandolo secondo diversi scenari), ma è anche necessario:

  • Eseguire la riprogrammazione;
  • Aggiornare i piani, trasferire le rettifiche ai periodi successivi;
  • Effettuare un piano: un'analisi fattuale.
Va riconosciuto che nella maggior parte delle imprese (che utilizzano 1C per l'automazione) la pianificazione non viene eseguita nel programma.
"Dovremmo organizzare la contabilità..." - così sostengono in molti.

La contabilità deve essere migliorata, sì, ma non a scapito della pianificazione.
Naturalmente, pianificano ancora (ma non in 1C, ma in XLS). E il primo compito principale (che stanno cercando di risolvere) è la pianificazione della liquidità.

  • (1) Strategico (budget);
  • (2) Operativo.
E se il budget (ovviamente con un approccio top-down alla pianificazione) può essere effettuato utilizzando XLS, allora la pianificazione operativa non può essere eseguita.
La conclusione è che molto spesso un minimo di utenti (1-2 persone) lavora con le tabelle di budget. Per la maggior parte delle aziende, il numero di voci di budget e di altre analisi non è così elevato. Cioè, tutto può essere elaborato manualmente in XLS.

Ma per quanto riguarda la pianificazione operativa del d/s, qui la situazione è diversa. Ciò significa che spesso ci sono molte fatture da pagare, molti pagamenti regolari, pagamenti previsti per gli ordini dei clienti, ecc.

Inoltre, tutto ciò può essere "legato" a un gran numero di documenti primari con cui lavorano vari utenti del programma, i documenti vengono adattati, la situazione cambia, ecc.

Un'altra importante differenza tra la pianificazione operativa e il budget è che spesso viene dal basso verso l'alto. Cioè dalle “Richieste spese d/s”, che vengono sempre compilate dai dipendenti del dipartimento.

E queste richieste, di conseguenza, devono essere elaborate in tempo, accettate/rifiutate, “programmate” e pagate.

Totale: la pianificazione operativa per d/s è il primo compito di pianificazione, che dovrebbe essere automatizzato in 1C per qualsiasi azienda.

E come risultato della pianificazione, il dipartimento finanziario/tesoreria dovrebbe “vedere” nel sistema:

  • Quando, a chi, da quale conto bancario/contanti, per quale importo deve essere pagato;
  • Quale sarà il saldo di cassa alla data “tale e tale”, tenendo conto dei saldi correnti, delle spese pianificate e degli incassi. Il cosiddetto deve essere evitato. "lacune di liquidità"

    Cioè, è necessario lavorare con il calendario dei pagamenti.

  • Quale sarà il debito con le controparti date specificate, tenendo conto dei pagamenti previsti, delle entrate e del saldo corrente degli accordi reciproci.

    Cioè, è necessario lavorare con il calendario di calcolo.

Scopo di questo articolo – parlare delle possibilità di automatizzare la pianificazione operativa per il d/c. Allo stesso tempo, verrà effettuata un'analisi comparativa di 3 diverse configurazioni di circolazione (due sono standard da 1C, una è specializzata dalla società Wiseadvice).

Ciascuna configurazione può essere utilizzata per risolvere problemi di pianificazione operativa, ma è necessario fare una scelta equilibrata in base all'ambito e alla portata del progetto.

2. Caratteristiche dell'avviatore statico 1.3

Al momento, 1C non ha ancora rilasciato la tanto attesa nuova edizione dell'UPP (revisione 2). E per questo motivo ci concentreremo su ciò che è disponibile: i sottosistemi corrispondenti di SCP 1.3:

Si segnala che il sottosistema “Richieste di Spesa di Contanti” è stato aggiornato nella configurazione in tempi relativamente recenti (2011). E di conseguenza, nella modalità interfaccia gestita, nel pannello della sezione è apparsa la voce “Richieste di spesa d/s/”.


Se provi in ​​una configurazione standard, in modalità file, ad aprire il modulo documento “Richiesta di spese D/s” (noto anche come ZRDS), apparirà immediatamente un errore per la variabile “Valori globali” dal modulo generale “Lavorare con Variabili generali”.

Tali errori possono però essere corretti, come si suol dire: “il sedimento rimane”. Cioè, ci sono abbastanza "rugosità" nel sottosistema UPP ZRDS.
La possibilità di redigere un documento ZRDS tramite un browser WEB è utile, ma in pratica dovrai riflettere attentamente sulla semplificazione e sull'ergonomia del modulo standard del documento. Ciò sarà particolarmente importante per i dispositivi mobili.

Ma per quanto riguarda il calendario dei pagamenti, in modalità thin client, da remoto tramite browser WEB, ecc. non potrai usarlo. Il motivo è che il sottosistema Gestione cassa non è stato aggiornato da molto tempo e, in particolare, il report Calendario pagamenti non è costruito su un sistema di composizione dei dati. Pertanto, questo rapporto non può essere utilizzato nei thin client; non è possibile creare impostazioni personalizzate per esso.

Quando si lavora con ZRDS, un posto importante è occupato dalle norme per il coordinamento e l'approvazione delle domande. Dipende da struttura organizzativa impresa e altre caratteristiche aziendali, la procedura interna per l'approvazione delle domande (regolamenti di approvazione) può essere piuttosto complessa (a più fasi, variabile, ecc.). Quindi questo non è un compito facile per l’automazione.

In UPP viene implementato il sottosistema di coordinamento e approvazione. Fornisce impostazioni abbastanza flessibili.

  • L'approvazione è la conferma della necessità di pagare la domanda. In genere, l'approvazione deve passare attraverso i capi dipartimento, i dirigenti e le altre persone responsabili dell'azienda.
  • L'approvazione è la conferma finale (da parte del Tesoriere) che la domanda sarà pagata. In questo caso dovrà essere determinata la data del pagamento e il conto bancario/cassa da cui verrà effettuato il pagamento. Pertanto, il pagamento rientra nel piano operativo (calendario dei pagamenti).
Va notato che numerosi aspetti della funzionalità standard del soft starter non forniscono quanto richiesto per l'effettiva implementazione del sottosistema.
Scriverò di questi "momenti" più tardi, ma per ora diamo un'occhiata alle funzionalità fornite da una configurazione tipica.
  1. È possibile abilitare l'uso del meccanismo di approvazione della domanda separatamente per ciascuna organizzazione.

  • È possibile configurare la sequenza dell'applicazione tramite percorsi e la gerarchia dei percorsi.
  1. Va notato che la gerarchia nella directory del dipartimento non viene presa in considerazione nei meccanismi di routing dell'applicazione.
  2. È inoltre necessario cancellare il fatto che il coordinamento e l'approvazione sono stati tecnicamente costruiti senza l'utilizzo di un meccanismo di processo aziendale.

  • In ogni punto è possibile specificare uno/più utenti per i quali sarà disponibile l'approvazione della domanda. Cioè, la domanda può essere approvata da chiunque di loro (chi riesce a farlo per primo).

  • Per ciascun reparto è possibile assegnare un punto del percorso di approvazione corrispondente. L'essenza di ciò è questa: quando si compila una domanda (ZRDS), è necessario indicare il Distretto Federale Centrale (divisione). E a seconda della divisione specificata, l'UPP “trova” il punto di approvazione corrispondente e “invia” la domanda di approvazione a questo punto.

È anche possibile non specificare un reparto durante l'impostazione del percorso di approvazione. In questo caso tale punto di coordinamento verrà “applicato” a tutti i CFD per i quali non è specificatamente indicato il punto di percorso corrispondente.

  1. L'approvazione stessa viene eseguita utilizzando un'elaborazione speciale "Approvazione della domanda"

  1. L'analisi della disponibilità pianificata dei fondi, del calendario dei pagamenti e del monitoraggio delle lacune di cassa viene eseguita nel rapporto "Calendario dei pagamenti".

Oltre al consumo pianificato di d/s (ZRDS) è possibile tenere conto anche dell'incasso pianificato di d/s. A tali fini è prevista la redazione di un apposito documento “Ricezione prevista dei redditi”.


È opportuno notare che sebbene il documento “Ricezione prevista del d/c” riporti (preparato, concordato, ecc.), non vi è alcuna possibilità di coordinare questo documento (così come lo ZRDS). Cioè, la modifica degli stati dei documenti è possibile solo nella sezione " controllo manuale».

E nell'UPP è possibile tenere conto della prevista ricezione di contanti dagli acquirenti senza preparare i documenti “Ricevuta pianificata di contanti”.

Cioè, se vengono emessi "Ordini cliente" per un acquirente, in un rapporto separato "Calendario dei pagamenti tenendo conto degli ordini" è possibile visualizzare questa ricevuta pianificata.

  1. Oltre al report Calendario pagamenti, è disponibile un report Analisi disponibilità cassa.

Allo stesso tempo è possibile riservare d/s (in base alle richieste di spese) o effettuare richieste a fronte delle entrate previste.

Esiste anche la funzionalità per la chiusura di ZRDS e le entrate pianificate da d/c. A tal fine, nella modalità “cliente abituale”, vengono forniti i documenti “Chiusura domande di uscite/entrate”.

Tuttavia, anche questa funzionalità non è supportata in modalità thin/web client.
Qui è necessario comprendere che la tecnica della “prenotazione definitiva” è fortemente legata alla cronologia di inserimento dei documenti e ciò rende difficili aggiustamenti e riprogrammazioni.

Pertanto, la funzionalità viene lasciata nell’UPP piuttosto come “eredità del passato” e il calendario dei pagamenti dovrebbe essere utilizzato per analizzare la disponibilità dei d/s.


Abbiamo quindi considerato la funzionalità del soft starter ed ora elencherò quegli aspetti della configurazione standard che nella pratica, sui progetti, devono essere modificati:

  1. Secondo il documento “Domanda di spesa d/s”:
    1. Nel documento puoi indicare "Divisione" (a proposito, nella configurazione è designato come Distretto Federale Centrale - centro di responsabilità finanziaria). Ma è del tutto possibile che una domanda venga presentata da una divisione (CFD), e in questo caso i costi dovranno essere ulteriormente attribuiti/distribuiti ad un'altra divisione(i) (CFD - centri di gestione finanziaria).

      Possibilità di specificare funzioni digitali, ecc. - assente.

      Non è possibile modificare il percorso o reindirizzare l'applicazione su altri percorsi.

    1. Non è possibile programmare il trasferimento del contante tra conti correnti, dal conto alla cassa, ecc.
  1. Processo di accordo:
    1. È possibile coordinare lo ZRDS, ma non esiste la possibilità di coordinare la ricezione prevista dei d/s.
    2. In pratica diventa necessario effettuare approvazioni per gli altri dipendenti. Allo stesso tempo, il sistema deve anche registrare informazioni su “chi ha eseguito l’approvazione e per chi”.

      La possibilità di installare più possibili esecutori in un punto di coordinamento spesso non è adatta, per cui questo esecutore può essere indicato in altre fasi del coordinamento. Di conseguenza, tutto ciò porterà al fatto che il dipendente avrà contemporaneamente compiti di approvazione sia principali che indiretti nell'elenco delle richieste di approvazione. Naturalmente questo confonde l’utente e non è conveniente.

      In sintesi, la capacità di coordinare per un altro esecutore, la capacità di indicare chi ha il diritto di coordinare per chi è assente.

    3. Nel processo di approvazione delle domande, quando una domanda viene trasmessa per l'approvazione a quella successiva lungo il percorso, è richiesta la funzionalità di informare automaticamente (via e-mail) il successivo esecutore, nonché l'autore della domanda .
    4. Se l'autore della domanda è già responsabile del coordinamento/approvazione (in qualsiasi fase del percorso!), allora è abbastanza logico che il programma “accorci” automaticamente il percorso, reindirizzando la domanda al livello più alto disponibile. Ciò però non è previsto dall’UPP.
    • Tutti i requisiti sopra indicati, pur non essendo compresi nella configurazione standard, lo sono comunque.
  1. Rapporti, diritti di accesso.
    1. Si richiede la possibilità di limitare l'accesso alle candidature solo agli autori/esecutori disponibili (coordinatori); per dipartimenti a disposizione dell'utente.
    2. Non esiste alcuna rendicontazione sul monitoraggio (per giorni e intervalli) del debito effettivo e pianificato. Questo vale sia per gli acquirenti che per i fornitori.
    3. I report e alcune funzionalità non sono adatti per lavorare in modalità thin/web client.
  2. Contabilità di accordi e contratti regolari.
    1. Ci sono spesso situazioni in cui è necessario pagare regolarmente i fornitori. Ad esempio, canoni di locazione, ecc.

      UPP non lo riflette automaticamente nel calendario dei pagamenti, ecc. queste spese imminenti. Cioè, è necessario tenere traccia manualmente di tali pagamenti e compilare le richieste di pagamento, il che è scomodo e richiede molto tempo.

    2. Gli accordi con acquirenti e fornitori possono stabilire condizioni relative alla percentuale di pagamento anticipato, ai termini di pagamento, ecc.

      L'UPP non registra automaticamente tutte queste informazioni e (di conseguenza) le riflette automaticamente nel calendario dei pagamenti.

3. Caratteristiche di UT 11.1

Con il rilascio della nuova configurazione “Trade Management Rev.11”, sono apparse molte nuove funzionalità utili per le attività di pianificazione operativa e controllo finanziario.
Forse la cosa più significativa in questa parte di UT11 (rispetto a UPP 1.3) è il meccanismo per tenere conto del programma di pagamento. Questo meccanismo “chiude” ciò che era gravemente carente: l’automazione della pianificazione/contabilità nell’ambito di accordi e contratti regolari.

Pertanto, in UT11 non è necessario redigere documenti (se non ce n'è bisogno, ovviamente) per pianificare spese e entrate e, allo stesso tempo, il calendario dei pagamenti verrà formato normalmente.

Puoi annullare il fatto che le “impostazioni standard” del report “Calendario dei pagamenti” non soddisfano realmente le aspettative (pertanto il calendario non viene visualizzato), ma in modalità utente puoi aggiungere un raggruppamento per “data di pagamento” e il report verrà generato nel formato consueto.



La funzionalità del report è stata notevolmente ampliata (rispetto a SCP 1.3) grazie all'utilizzo di un sistema di composizione dei dati. Ora il report può essere generato in un thin/web client, salvato nel database e assegnato a diversi utenti le impostazioni di cui hanno bisogno.

Oltre a pianificare il consumo e l'entrata delle masserizie, UT11 ora ha la funzionalità di pianificare lo spostamento delle masserizie. A tal fine è possibile redigere i documenti “Ordinanza per il trasferimento delle famiglie”.

Rispetto all’UPP 1.3 per il documento “Richiesta di spesa di contanti”, il numero delle tipologie di transazioni commerciali considerate è aumentato:

Ora è possibile approvare sia i documenti “Richiesta di spesa di fondi” che altri ordini:

Per analizzare il debito per intervalli/scadenze, viene fornito il report “Contabilità clienti”. Se necessario, puoi anche creare un calendario dei debiti. Per fare ciò, in modalità personalizzata dovresti aggiungere un raggruppamento per data di pagamento.


Sfortunatamente, UT11 (come prima) non fornisce la possibilità di analizzare il calendario dei debiti da parte dei fornitori. Tuttavia, UT11 deve essere finalizzato per questo compito.

Riassumere: le nuove soluzioni metodologiche "1C", insieme alle funzionalità della piattaforma 8.2, forniscono una buona base per automatizzare i compiti di pianificazione operativa e controllo del d/c.

Ma allo stesso tempo devi capire che la configurazione di UT11 non è completa, soluzione già pronta per l’automazione della tesoreria e della pianificazione finanziaria.

  • In primo luogo, UT11 implementa in forma molto semplificata un meccanismo di coordinamento/approvazione delle richieste di spesa e degli altri documenti di pianificazione del d/s. Cioè, non esistono meccanismi di instradamento, il processo di approvazione delle domande si riduce alla semplice impostazione degli stati.
  • In secondo luogo, UT11 non dispone di un sottosistema di budgeting e (di conseguenza) non esiste alcuna funzionalità per monitorare le richieste di budget pianificati.
4. Caratteristiche WA: Finanziatore

Storicamente, la configurazione WA:Financier è stata sviluppata sulla base del prodotto Treasury Management.

E allo stesso tempo la nuova soluzione “Financier” di WiseAdvice comprende anche:

  • Sottosistema di pianificazione del budget;
  • Sottosistema di gestione dei contratti;
  • Sottosistema per la formazione e la contabilizzazione dei pagamenti effettivi;
  • Meccanismo flessibile e personalizzabile per generare/compilare documenti basati su modelli;
  • Sottosistema di integrazione cliente-banca flessibile e personalizzabile.
Consideriamo la funzionalità principale di "WA: Financier" in termini di tesoreria: dalla presa in considerazione dei termini dei contratti alla creazione di un calendario di pagamento.









  1. Durante il processo di approvazione della domanda, non solo è possibile approvare/rifiutare il documento (come avviene in UPP), ma sono disponibili anche altre funzionalità: ad esempio inviare un documento per la revisione o richiedere informazioni aggiuntive. informazione.

    L'intero processo è automatizzato; di conseguenza, viene fornita una reportistica sullo stato del processo di approvazione del documento.




5. Risultati




Conclusioni:

  1. Automatizzare il lavoro di dipartimenti finanziari, tesorerie, organizzazioni con strutture organizzative complesse. struttura è la soluzione più adatta "WA: Finanziere".

    Questa soluzione si è sviluppata ed evoluta per molto tempo, accumulando di conseguenza le specificità e i requisiti di diversi istituti finanziari. dipartimenti e tesorerie. Il costo totale della manodopera per lo sviluppo della soluzione è stato di oltre 5.000 ore/persona.

    Il vantaggio della soluzione WA: Financier è la sua funzionalità avanzata e un gran numero di meccanismi di impostazione del programma. Pertanto, l'implementazione di questa soluzione è possibile in poco tempo(la cosiddetta “implementazione out-of-the-box”), senza ulteriori. sviluppo, programmazione, ecc.

    Poiché la soluzione contiene meccanismi per lo scambio bidirezionale con tutte le principali configurazioni standard, l'integrazione nella struttura esistente (scambio dati con database UT, UPP, Kompleksnaya, Bukh) non sarà difficile.

  2. Automatizzare il dipartimento finanziario/tesoreria nell’ambito di un progetto di automazione globale la soluzione migliore è basato sull'UPP.

    Allo stesso tempo, è necessario comprendere che la funzionalità dell'avviatore statico richiederà miglioramenti.

    Specifiche, requisiti finanziari. i dipartimenti e le tesorerie non sono integrati nell’UPP così profondamente come avviene in soluzioni separate e specializzate.

    Pertanto, l'implementazione di SCP per questi compiti dovrebbe essere eseguita solo come parte di un progetto di automazione.

  3. Per grandi organizzazioni, per l'automazione del dipartimento di tesoreria UT11 non si adatta.

    In questa decisione, in primo luogo, non sono previsti meccanismi di coordinamento/approvazione dei documenti programmatici.

    In secondo luogo, non esiste un sottosistema di budget e nessun controllo sull'attuazione dei budget durante la pianificazione operativa.

    Tuttavia, UT11 perfetto per automazione (compresa la pianificazione operativa d/c) piccola finanziaria dipartimenti aziendali.

Il documento “Richiesta di spesa di fondi” è destinato alla pianificazione e al coordinamento dei pagamenti.
Il documento “Richiesta di spesa DS” può essere creato accedendo alla sezione “Tesoreria” - “Pianificazione e controllo dei fondi” - “Richieste di spesa DS” - Crea.
Il documento “Richiesta di spesa del DS” prevede diverse tipologie di operazioni che vengono selezionate in fase di creazione. Ciascun tipo di applicazione è destinato a riflettere una varietà di transazioni commerciali, ciascuna delle quali sarà descritta in queste istruzioni.
I documenti creati “Richiesta di spesa DS” vengono raccolti e concordati utilizzando il documento “Registro dei pagamenti”. Dopo l'approvazione, in base alle richieste, vengono creati automaticamente i documenti “Storno DS non contanti”, che vengono caricati sulla banca cliente per il pagamento da parte della banca.
Di seguito sono riportati esempi di redazione dei documenti “Domanda di spesa del DS” per ciascuna tipologia di operazione.

Pagamento al fornitore
Per elaborare le transazioni di pagamento a un fornitore, è previsto il tipo di transazione del documento "Richiesta di spesa di DS" - "Pagamento al fornitore".
Nel nuovo documento “Domanda di spesa DS” sono evidenziati in rosso i campi obbligatori da compilare per l'elaborazione del documento. Il documento viene creato nello stato “Non approvato”; lo stato cambia automaticamente durante l'approvazione del registro dei pagamenti. La priorità dell'applicazione al momento della creazione viene impostata automaticamente su "Media".

Figura 1. Modulo documento “Richiesta di spesa del DS”, tipologia di operazione “Pagamento al fornitore” (non compilato)
I dettagli del documento “Domanda di spesa DS” dovranno essere compilati come segue:
Scheda Base
Numero– viene generato automaticamente durante l'esecuzione, non può essere impostato manualmente.
data– al momento della creazione viene impostata la data corrente.
Organizzazione– è necessario selezionare dall'elenco proposto di organizzazioni utilizzando il pulsante oppure inserendo il nome nel campo, verrà offerto per la selezione il valore richiesto.
Suddivisione– dalla directory “Struttura aziendale”, è necessario selezionare la divisione per la quale dovrà avvenire il pagamento.
Richiedente– per impostazione predefinita viene indicato l'utente del sistema che sta creando l'applicazione.
Pianificazione– l'impostazione predefinita è "Nella valuta del pagamento" e non può essere modificata.
Somma– indica l’importo del pagamento richiesto.
Valuta– indicare la valuta del pagamento richiesto.
Operazione– si riflette il tipo di transazione del documento “Richiesta di spesa di DS” selezionato durante la creazione
data di pagamento– indica la data in cui deve essere programmato il pagamento al fornitore.
Forma di pagamento– l'impostazione predefinita è “In qualsiasi forma” e non può essere modificata.
Destinatario– indica il fornitore della directory “Controparti” a cui effettuare il pagamento.
Conto del destinatario– selezionando “Destinatario” viene automaticamente impostato il conto del destinatario; eventualmente, se sulla “Fattura di pagamento” fornita dal fornitore è indicato un conto diverso, è necessario selezionare quello richiesto dalla directory “Conti Bancari”.
Oltre il limite– se il sistema mantiene un sistema per limitare le spese di cassa rispettivamente nell'ambito delle filiali e delle voci dei flussi di cassa, se l'importo del pagamento effettuato non era precedentemente compreso nel limite, al momento della registrazione del documento l'utente riceverà un messaggio di errore e la domanda non verrà elaborata.


Figura 2. Un esempio di errore durante l'immissione di un ordine per il quale non era previsto un limite.
Per effettuare un ordine oltre il limite, è necessario impostare il flag "Oltre limite".
Trasferimento al bilancio– questo flag è impostato se il pagamento è un trasferimento al budget. L'impostazione del flag consente di inserire i valori di KBK, OKTMO, ecc. richiesti per i pagamenti al budget.

Figura 3. Esempio di impostazione del flag “Trasferimento al budget”.
UIP– un identificativo univoco del pagamento, indicato solo se previsto nel contratto con il beneficiario.
Scopo del pagamento- il programma fornisce diverse opzioni per compilare automaticamente la causale del pagamento utilizzando il pulsante "Inserisci".

Figura 4. Opzioni per la compilazione automatica del campo "Scopo del pagamento".
Elenco dei documenti, incl. I.V.A.- visualizzerà le informazioni sugli oggetti di liquidazione dalla scheda "decrittografia dei pagamenti".

IVA inclusa (18%) (per l'intero importo), incl. IVA (10%) (per l'intero importo), IVA esclusa (IVA)- Le informazioni sull'IVA verranno aggiunte al testo inserito.

SMS dal conto bancario del destinatario- inserisce il testo specificato nel campo “Testo causale pagamento” dalla carta conto della controparte.

Figura 5. Esempio di compilazione della scheda “Base”.

Scheda Dettagli pagamento
La scheda "Decodifica pagamento" fornisce informazioni dettagliate sul pagamento e sui regolamenti reciproci con il beneficiario.
Il pagamento può essere inserito come elenco, ad es. distribuire su più oggetti di calcolo oppure, senza suddivisione, è possibile selezionare un solo oggetto di calcolo.
Pagamento dai fondi della difesa statale– il contrassegno viene apposto solo se il pagamento avviene nell’ambito di un ordine del governo della difesa, negli altri casi il contrassegno non viene apposto.
Oggetto di calcolo– come oggetto della transazione è possibile indicare “Accordo con la controparte” (per questo tipo di operazione del documento applicativo, quando selezionati, sono disponibili accordi con la tipologia di rapporto “Con fornitore/esecutore”) oppure il documento concordato “Ordine al fornitore”.
Fornitore
Importo degli accordi reciproci– viene impostato automaticamente quando si registra un documento.
Valuta– viene impostato automaticamente quando si seleziona un oggetto di calcolo.
Articolo DDS– indicare la voce del flusso di cassa corrispondente alla tipologia di pagamento.
Un commento– se necessario, indicare un commento sulla decrittazione del pagamento.

Figura 6. Esempio di compilazione della scheda “Decodifica Pagamento”.
Scheda Distribuzione conto
Nella scheda "Distribuzione sui conti" è indicato il conto bancario dell'organizzazione da cui devono essere addebitati i fondi. L'importo e la data del pagamento vengono impostati automaticamente in base ai dati specificati nella scheda "Base".

Figura 7. Esempio di compilazione della scheda “Distribuzione per conti”.

Figura 8. Un esempio di documento creato automaticamente “Storno di DS non in contanti” per un'applicazione con il tipo di transazione “Pagamento al fornitore”.

Restituzione del pagamento al cliente
Per l'elaborazione delle transazioni di rimborso ai clienti, è previsto il tipo di transazione nel documento "Richiesta di spesa DS" - "Restituzione del pagamento al cliente".
La composizione dei dettagli del documento “Richiesta di spesa di DS” con questo tipo di operazione è identica alla composizione dei dettagli in caso di pagamento al fornitore, l'unica differenza sta nella tipologia di controparte e nell'oggetto della liquidazione.

Figura 9. Forma del documento “Richiesta di spesa DS”, tipologia di operazione “Restituzione del pagamento al cliente”
Destinatario– indica il cliente della directory “Controparti” che deve effettuare il pagamento.
Oggetto di calcolo– come oggetto della transazione è possibile indicare “Accordo con la controparte” (per questo tipo di operazione del documento applicativo, in fase di selezione, sono disponibili accordi con la tipologia di rapporto “Con il compratore/cliente”) oppure il documento concordato “ Ordine del cliente".
Acquirente– il campo viene compilato automaticamente quando si seleziona un oggetto di calcolo. Viene installato l'elemento della directory "Partner" specificato nel campo corrispondente dell'oggetto di calcolo.

Figura 10. Esempio di compilazione della scheda “Decodifica Pagamento”.
Dopo aver superato tutte le fasi di approvazione, al documento "Richiesta di spesa DS" verrà assegnato lo stato "Per pagamento" e il documento "Storno DS non in contanti" verrà creato automaticamente.



Figura 11. Un esempio di un documento creato automaticamente "Storno di DS non in contanti" basato su un'applicazione con il tipo di operazione "Restituzione del pagamento al cliente".

Emissione al responsabile
Per formalizzare le transazioni per l'emissione di fondi su un conto bancario di una persona responsabile, è previsto il tipo di transazione del documento "Richiesta di spesa DS" - "Emissione alla persona responsabile".

Figura 12. Forma del documento “Richiesta di spesa DS”, tipologia di operazione “Emissione al responsabile”
Persona responsabile– il dipendente è indicato dall’elenco “ Individui”, al quale è necessario trasferire il denaro.
Rapporto– dall'elenco dei periodi proposto, è necessario indicare il periodo fino al quale il contabile deve riferire sull'importo ricevuto.

Figura 13. Esempio di compilazione della scheda “Decodifica Pagamento”.
Dopo aver superato tutte le fasi di approvazione, al documento "Richiesta di spesa DS" verrà assegnato lo stato "Per pagamento" e il documento "Storno DS non in contanti" verrà creato automaticamente.


Figura 14. Un esempio di un documento creato automaticamente "Storno di DS non in contanti" basato su un'applicazione con il tipo di operazione "Emissione al responsabile".

Una condizione essenziale per l'esistenza effettiva di un'impresa in un ambiente competitivo moderno è la creazione di un meccanismo di gestione efficace flussi di cassa garantendo la generazione di informazioni tempestive e affidabili, la regolamentazione degli accordi reciproci, l’aumento della disciplina dei pagamenti e, in ultima analisi, l’accelerazione del turnover del contante.

La configurazione contiene strumenti per la gestione automatizzata della liquidità aziendale, che svolge due funzioni principali:
  • contabilità operativa dell'effettivo movimento dei fondi dell'impresa sui conti di liquidazione e sulle casse;
  • pianificazione operativa delle entrate e delle spese dell'impresa.

La pianificazione generale delle spese e della ricezione dei fondi di un'impresa viene effettuata nell'ambito del bilancio. Il piano finanziario in corso di elaborazione – il budget – funge da insieme di linee guida e vincoli per il sottosistema di gestione della liquidità.

Ma nell'ambito della funzionalità di gestione della liquidità, viene mantenuto un piano finanziario operativo: un calendario dei pagamenti. È opportuno creare un calendario dei pagamenti con diversi giorni di anticipo.

Il calendario dei pagamenti è una raccolta di richieste di fondi di spesa e di incassi pianificati. Il calendario dei pagamenti è compilato con dettagli fino ai luoghi in cui sono depositati i fondi: conti bancari e casse dell'impresa. Quando si compila un calendario di pagamento, la sua fattibilità viene verificata automaticamente: l'adeguatezza delle riserve di liquidità nei luoghi in cui sono conservate.

La divisione della funzione di pianificazione finanziaria in due sottosistemi di configurazione - il sottosistema di budget e il sottosistema di gestione della liquidità - corrisponde alla divisione delle funzioni di gestione finanziaria tra vari dipartimenti e dipendenti dell'impresa. Se il budget viene redatto dai servizi finanziari, le richieste di fondi di spesa vengono generate da dipendenti e dipartimenti che interagiscono direttamente con le controparti dell’azienda.

Nella configurazione vengono generati documenti monetari (ordini di pagamento, ricevute di cassa e ordini di addebito, ecc.), viene assicurata l'interazione con programmi bancari specializzati come "Cliente bancario", vengono controllati i flussi finanziari e viene controllata la disponibilità dei fondi nelle aree di stoccaggio monitorato. È prevista la possibilità di pagamenti in contanti in valuta estera.

Il documento “Richiesta fondi di spesa” ha lo scopo di registrare la decisione di effettuare un pagamento in contanti o non in contanti (gruppo di pagamenti) o di spostare fondi. I dettagli del documento e la procedura per il suo utilizzo sono sostanzialmente simili ai documenti “Ordine di pagamento (in uscita)” e “Ordine di spesa in contanti”.


I parametri di prenotazione e posizionamento possono essere compilati automaticamente. A questo scopo, il documento fornisce flag e "Posizionamento automatico".


Se questi flag sono impostati, la colonna "Posizionamento" può essere compilata automaticamente quando si fa clic sul pulsante "Compila e pubblica".


Lo schema di posizionamento automatico e manuale può essere combinato. Quando le bandiere sono impostate "Prenotazione automatica" E "Posizionamento automatico"È possibile specificare manualmente l'opzione di posizionamento per una parte dell'importo della richiesta. Quindi quando premi il pulsante "Compila e pubblica" Ci sarà un collocamento automatico solo per l'importo residuo.


Quando il tipo di operazione è impostato su " Pagamento al fornitore" O " Rimborso all'acquirente" vengono apportate modifiche agli accordi operativi con le controparti.


Sulla base del documento “Richiesta fondi di spesa” possono essere inseriti i documenti bancari e di pagamento in contanti. Tali documenti forniscono i requisiti “ Applicazione", che viene compilato durante la digitazione in base ad esso oppure può essere compilato manualmente. Quando si registrano documenti di pagamento con una specifica richiesta di fondi di spesa, viene verificata la conformità dell'importo del documento con il saldo corrente dei pagamenti in sospeso per questa richiesta.


Quando si impostano diritti aggiuntivi, è possibile vietare all'utente di elaborare documenti di pagamento senza indicare una richiesta di fondi di spesa.


Il documento “Richiesta di spesa dei fondi” può fungere anche da collegamento tra il sottosistema di gestione della liquidità e il sottosistema di bilancio. A questo scopo l'applicazione fornisce un blocco di dettagli simile al documento “Operazione di Bilancio” (scenario di pianificazione, voce di fatturato, distretto finanziario centrale, progetto, ecc.). Utilizzando i dettagli specificati, al momento della presentazione della domanda, viene monitorata la conformità dell'importo totale dei fondi approvati per la spesa con i valori limite precedentemente stabiliti.


Funzionalità di lavorare con le applicazioni quando si utilizza il meccanismo di approvazione delle applicazioni

Il meccanismo di approvazione della domanda viene utilizzato facoltativamente: per un elenco di organizzazioni.


Quando si utilizza il meccanismo di corrispondenza delle applicazioni, si presentano le seguenti funzionalità:



    Se la domanda non indica un'organizzazione, tale domanda non partecipa all'approvazione


    Il percorso per l'approvazione della domanda è determinato in base alle impostazioni a seconda della Divisione specificata nella domanda.


    Se la domanda non ha superato il percorso di approvazione (lo stato della domanda non è “Approvata”), non è possibile emettere un documento di pagamento sulla base di essa


    Se la domanda inizia a seguire il percorso di approvazione, la domanda può essere modificata



    • L'utente la cui domanda è attualmente in fase di approvazione


      Utenti che approvano un'applicazione nelle fasi più elevate di approvazione
      Gli altri utenti non possono modificare l'applicazione.


    Se l'ordine è nello stato "Approvato", non può essere modificato


    Se la domanda entra nello stato "Rifiutato", la domanda viene annullata


    Lo stato attuale delle domande è nell'elenco delle domande



    • lo stato viene visualizzato in una colonna separata


      Viene utilizzato il raggruppamento per stato dell'ordine


      le applicazioni sono evidenziate con il colore di sfondo




      • rifiutato - rosa

Nella seconda parte dell'articolo considereremo il principio di creazione di “Richieste di fondi di spesa”, passandole lungo il percorso di approvazione ed emettendo fondi in base all'applicazione creata.
Diamo un'occhiata ad un esempio:

    1. Il contabile degli appalti presenta una richiesta di spesa di fondi al fine di effettuare un pagamento anticipato al fornitore di IP Dobronravov per la fornitura di materiali;
    2. Il CFO deve esaminare e approvare la domanda;
    3. Sulla base della domanda approvata, il contabile degli appalti genera un ordine di ricevuta di cassa (senza il contrassegno “Pagato”, ma con il contrassegno “Rifletti nella contabilità operativa”);
    4. Il cassiere senior, dopo aver controllato l'ordine di ricevuta, emette fondi (e contrassegna il documento come “Pagato”);
    5. Il contabile delle transazioni di cassa controlla l'ordine di incasso (seleziona la casella per la riflessione nei registri contabili e fiscali in modo che vengano generate le voci contabili e fiscali).

Per rendere più semplice riflettere le transazioni, cambiamo l'interfaccia in "Gestione cassa".
Prima di iniziare a lavorare con le richieste di spesa dei fondi, devi inserire tutto informazioni di base. La prima cosa che devi compilare è il registro delle informazioni "Impostazioni per l'approvazione delle domande di fondi di spesa". In “Impostazione dell'approvazione delle domande” sono indicate le organizzazioni per le quali viene utilizzato questo meccanismo e la data di inizio dell'utilizzo del meccanismo di approvazione. Questa impostazione è necessaria affinché il programma possa determinare che l'organizzazione StroyTorg LLC utilizzerà un meccanismo per approvare le richieste di spesa dei fondi a partire dal 01/01/2013.

È inoltre necessario configurare i percorsi di coordinamento (Fig. 2). Questa impostazione è indicata nel registro informativo “Impostazioni per l'avvio dei percorsi approvativi”: viene determinata la corrispondenza dei percorsi approvativi ai reparti. Il percorso di approvazione (la directory “Percorsi di approvazione”) indica la fase e l'elenco delle persone che approvano in questa fase. Nel nostro esempio, l'applicazione creata dovrà prima passare attraverso una fase di approvazione da parte del direttore finanziario.

È inoltre necessario impostare il registro delle informazioni “Impostazione dell'approvazione delle domande di fondi di spesa” (Fig. 1) e determinare le fasi (percorso) dell'approvazione delle domande (Fig. 2)

Riso. 1

Riso. 2

Percorso di coordinamento L'applicazione viene determinata in base alle impostazioni e in base al reparto specificato nell'applicazione.

Nota che una divisione deve corrispondere ad un solo percorso di coordinamento. È necessario specificare un percorso di approvazione per ciascuna divisione, altrimenti il ​​processo di approvazione per tutte le domande create per questa divisione non avrà effetto.

1. Il contabile acquisti crea il documento “Richiesta di spesa di fondi”.

Nell'interfaccia “Gestione Cassa” che abbiamo scelto, andiamo alla voce di menu “Pianificazione” - “Richieste” - “Richiesta fondi di spesa” (Fig. 3). Creiamo una “Richiesta di spesa fondi” con il tipo di stato “Preparato” (Fig. 5)

L'Applicazione dispone di diversi tipi di operazioni che ripetono i tipi di operazioni “Ordine di pagamento in uscita” e “Ordine di pagamento in uscita” (Fig. 4)

Nella "Richiesta di spesa di fondi" nella scheda "Regolamenti con controparti" sono indicate le informazioni di base: la controparte del pagamento a cui devono essere emessi i fondi, nonché l'accordo, l'importo, l'organizzazione, la divisione e lo stato.

Nella scheda "Descrizione" è possibile specificare Informazioni aggiuntive in qualsiasi forma.

La scheda “Assegnazione” offre la possibilità di riservare e collocare fondi (Fig. 6). Ciò significa che nel nostro esempio il contabile degli acquisti può riservare i fondi per pagare un anticipo al fornitore e indicare da quale cassa verranno emessi i fondi. I parametri di prenotazione e posizionamento possono essere compilati automaticamente. Nel documento sono presenti flag per questo scopo. "Prenotazione automatica" E "Posizionamento automatico". Se questi flag sono impostati, la colonna "Posizionamento" può essere compilata automaticamente quando si fa clic sul pulsante "Compila e pubblica". Lo schema di posizionamento automatico e manuale può essere combinato.

I dati nella scheda "Budget" possono essere utilizzati come collegamento tra il sottosistema di budget e il sottosistema di gestione della liquidità. Le informazioni visualizzate in questa scheda servono a controllare l'importo dei fondi pianificati per l'esborso in conformità con il budget pianificato (Fig. 7).

Poiché il contabile degli appalti ha diritti di accesso limitati, può impostare solo lo stato "Preparato" nel documento "Richiesta di spesa di fondi" e stati come: "Approvato", "Rimandato", "Concordato", "Rifiutato" sono impostato dagli utenti, responsabili dell'approvazione dell'applicazione.

2. Il direttore finanziario esamina e approva la richiesta per la spesa di fondi per un importo di 120.000 rubli.

Il direttore finanziario può analizzare l'elenco delle domande da prendere in considerazione utilizzando l'elaborazione "Stato di approvazione della domanda" (Fig. 8).

Quando si avvia l'elaborazione dello "Stato di approvazione della domanda", viene visualizzato un elenco di tutte le domande raggruppate per determinati stati (stati), ad esempio: "Preparato", "Approvato", "Rimandato", "Approvato", "Rifiutato". Per comodità è possibile effettuare la selezione “Impostazione del periodo” utilizzando il pulsante, ad esempio, per un giorno, una settimana, un mese, una decade, un trimestre, un semestre, un anno, ecc., e poi, di tutte le domande, rimarranno solo quelle che rientrano in un determinato periodo.

Per modificare lo stato delle richieste di spesa dei fondi, ad esempio, da "Preparato" ad "Approvato", è necessario utilizzare un'altra elaborazione ("Stato della richiesta").

In questa elaborazione è possibile selezionare da elenco generale domande, ad esempio, domande con lo stato "In attesa di approvazione", "Rimandato", "In attesa di approvazione nelle fasi precedenti", "Elaborazione" (Fig. 9).

In elaborazione viene visualizzato l'elenco delle domande non coordinate ed è possibile modificare lo stato della domanda (Fig. 10). A tale elaborazione si accede attraverso la voce di menù “Pianificazione” - “Richieste” - “Coordinamento delle istanze”.

Il Direttore Finanziario può “Approvare” la Richiesta di fondi di spesa, “Rinviarla” o “Rifiutarla”. Quando selezioni "Cambia stato" - "Accetto", le caselle di controllo contrassegnano le domande che devono essere approvate. Le restanti domande in coda possono essere visualizzate nel registro dei documenti “Approvazione delle domande”.

Se la domanda non ha superato il percorso di approvazione (lo stato della domanda non è "Approvato"), non è possibile emettere un documento di pagamento su questa base.

Se la domanda inizia a seguire il percorso di approvazione, è possibile modificarla:

    L'utente la cui domanda è attualmente in fase di approvazione;

    Utenti che approvano la domanda nelle fasi più elevate di approvazione.

Gli altri utenti non possono modificare l'applicazione.

Se l'applicazione è nello stato "Approvato", non è disponibile per la modifica (diventa inattiva per la modifica), quindi i campi nell'applicazione diventano grigi per il contabile acquisti e non possono essere modificati.

3. Sulla base della domanda approvata, il contabile acquisti redige una ricevuta di cassa con il tipo di transazione "Pagamento al fornitore" senza il contrassegno "Pagato" per l'emissione di un anticipo al fornitore di IP Dobronravov (Fig. 11)

Nota, che nell'ordine di incasso creato dal contabile acquisti, siano selezionate solo le caselle di controllo "Rifletti nella contabilità gestionale" e "Rifletti nella contabilità operativa". La casella “Pagato” deve essere spuntata dal cassiere senior dopo aver verificato la corretta formazione dell'ordine di scontrino. Indichiamo anche nell'ordine di ricevuta di cassa in base a quale applicazione lo stiamo generando.

Se nell'ordine di incasso sono presenti caselle di controllo solo per la contabilità di gestione, tale documento non genera registrazioni (registrazioni contabili). Ma inserisce nei registri di accumulazione: “Contanti per cancellazione” e “Accordi con controparti” (Fig. 12). Queste informazioni vanno nel report “Calendario dei pagamenti” nella sezione “Documenti in uscita non pagati” (Fig. 13).

4. Il cassiere senior controlla l'ordine di ricevuta di cassa, seleziona la casella di controllo "Pagato" ed emette contanti.

Dopo che l'ordine di ricevuta di cassa è stato pagato, i campi nel documento diventano grigi e non possono essere modificati dal contabile acquisti e dagli altri partecipanti nel nostro esempio. A seconda dei diritti di accesso configurati per un particolare utente, alcuni documenti, campi nei documenti, ecc. potrebbero essere disponibili per la modifica.

Nota: Se ci sono molti registratori di cassa e in ognuno è necessario selezionare la casella "Pagato", è possibile utilizzare l'elaborazione di gruppo di elenchi e documenti (voce di menu "Servizio"). Puoi accedere a questa elaborazione accedendo all'interfaccia completa, voce di menu "Servizio" (Fig. 14).

Per modificare i dettagli cliccare sul pulsante “Impostazioni” e selezionare il flag “Consenti modifica dettagli oggetto”. Per comodità di analisi impostiamo il flag “Mostra tutte le colonne” (Fig. 15).

Utilizzando l'elaborazione di gruppo, vogliamo inserire il flag "Pagato" nell'ordine di ricevuta di cassa. A tal fine, nella sezione “Selezione” del trattamento di gruppo, indichiamo l'organizzazione StroyTorg LLC; Selezioniamo solo i documenti elaborati per il periodo dal 01/01/2013 al 21/01/2013 con l'opzione "Pagato" - "No".

Quando si fa clic sul pulsante "Seleziona" nella scheda "Elaborazione", verranno visualizzati i documenti in cui è necessario contrassegnare "Pagato" (Fig. 16). Nella riga "Azione", seleziona "Modifica dettagli[Link.Paid] - Installa. E corri".

Dopo aver modificato il valore dei dettagli, è necessario ripubblicare i documenti modificati: nel campo “Azione”, selezionare “Modifica: [Pubblica documenti] – Imposta - “Esegui” (vedi Fig. 17).

5. Il contabile di cassa controlla l'ordine di incasso (seleziona la casella per la riflessione nei registri contabili e fiscali in modo che vengano generate le registrazioni contabili e fiscali).

Inoltre, ad esempio, alla fine della giornata lavorativa, un contabile delle transazioni in contanti controlla tutti gli ordini in uscita di contanti contrassegnati come "Pagati" e seleziona le caselle BU e NU nel documento in modo che il documento generi voci contabili e fiscali. (Fig.18)

Nota: se sono presenti molti ordini di incassi in cui è necessario selezionare le caselle BU e NU, è possibile utilizzare la "Elaborazione di gruppo di libri e documenti di consultazione" (Fig. 19).

Nell'elaborazione di gruppo di elenchi e documenti, selezioniamo i documenti "Ordine di spesa in contanti [TC: Decodifica dei pagamenti]", nella parte tabellare del quale è necessario selezionare la casella di controllo "Rifletti nella contabilità".

Nel campo “Selezione” indichiamo per quale organizzazione dobbiamo selezionare i documenti, indichiamo che siamo interessati solo ai documenti elaborati per il periodo dal 01/01/2013 al 21/01/2013 (così come le ricevute di cassa in cui la casella di controllo "Rifletti nella contabilità" non è selezionata) contabilità"). Dopo aver compilato tutti i parametri, fare clic sul pulsante “Seleziona”: verranno selezionati i documenti che soddisfano le condizioni specificate. Nella parte inferiore della finestra di elaborazione, seleziona "Cambia attributi" - "Rifletti contabilità" - "Installa" e fare clic sul pulsante "Esegui". Dopo che i documenti sono stati elaborati, devono essere ripubblicati (Fig. 16). Quindi è necessario ripetere la stessa cosa, ma selezionare la casella "Rifletti nella contabilità fiscale"

Quando si registra il documento "Ordine di spesa in contanti", non solo i movimenti vengono generati nei conti contabili, ma anche nei registri (Fig. 20, 21)