Data ultimo aggiornamento: 26/03/2020

Clicca per accedere al sito di NTS Informatica
Clicca per accedere all'argomentoClicca per accedere all'argomentoClicca per accedere all'argomentoClicca per accedere all'argomento
Clicca per accedere al sito di NTS Informatica

Impostazione e gestione della Tesoreria e flussi finanziari

Impostazione delle nuove tabelle

Note autorizzative Introduce il concetto di credito e/o debito pagabile/non pagabile. Questi codici possono poi essere assegnati alle varie righe dello scadenziario e dello scadenziario extracontabile. Le informazioni da inserire per creare i vari codici note autorizzative sono: il codice, la descrizione e l'attributo se è pagabile o no mentre il campo priorità non è gestito. Questo attributo permette di definire sui debiti se sono pagabili o non pagabili mentre sui crediti se sono incassabili o non incassabili. È quindi un'informazione ulteriore che si va ad aggiungere agli altri status di autorizzato e poi saldato. Si instaura così un livello in più nel work flow di incasso/pagamento. NB: non è obbligatorio inserire un codice nota autorizzativa sulle scadenze.

Gli step nel flusso pagamento/autorizzazione (flusso sui crediti) saranno quindi i seguenti:

· scadenza passiva app. inserita (non pagata, non autorizzata, cod. autorizzazione a zero)

· indicazione nota autorizzativa da pagare/non pagare (se cod. autorizz. a zero, è come 'da pagare') con la possibilità di indicare note relative

· se da pagare si può usare l'autorizzazione (classica) (sc_fldis su scaden)

· pagata (sc_flsaldato su scaden)

Sottotipi pagamento È un livello intermedio tra tipo pagamento e codice pagamento. La tabella dei sottotipi pag. memorizza e gestisce i GG medi di ritardo di incasso e di pagamento. L'indicazione di questi giorni è legata alla forma di pagamento usata di volta in volta per il cliente o per il fornitore

In fase di installazione/conversione ad ogni tipo di pagamento viene creato un sottotipo corrispondente e poi assegnato alla tabella delle forme di pagamento nel campo del sottotipo (codici 1, 2, 3, 4, 5). È obbligatorio indicare il codice sottotipo pagamento nelle varie forme di pagamento.

Rating finanziario (o 'rating', da non confondere con il campo 'affidabilità') ha dei valori fissi: 1=inderogabile, 2=certo, 3=incerto, 4=inattendibile. Questa non è configurabile ed è fissa in Business viene mostrato nel programma di "stampa analisi finanziaria"

Voci Finanziarie sono distinte in gruppi e dettagli e sono da collegare ai sottoconti, clienti e fornitori, che rappresentano debiti e crediti verso gli enne soggetti con cui l'azienda ha a che fare (erario, mutui, ecc...) per analisi di breve termine, quindi per conti che rappresentano debiti e crediti a breve termine.

Le voci finanziarie sono disposte su due livelli e permettono di strutturare le stampe di tesoreria, senza adottarne la stessa nomenclatura di descrizione che c'è nel PDC, definendo quali sono le entrate e le uscite (una sorta di stampa di workflow) e come voglio che siano raggruppate, per esempio un raggruppamento può essere:

  • gruppo: debiti verso erario
  • dettaglio: debiti per iva, debiti previdenziali, debiti per imposte dirette, ecc...

Il tempo medio di ritardo per incasso/pagamento viene selezionato come da 'escalation' dalla più generica alla più specifica. Il tempo medio di ritardo di inc./pag. viene preso con questa priorità:

  1. (meno specifico e quindi meno prioritario) nella tabella sottotipi pagamento posso battezzare con una informazione dedotta a livello statistico, se ad esempio per le rimesse dirette indipendentemente dal rating o dal cliente io incasso mediamente con 3 GG di ritardo, il tempo medio ritardo sui pagamenti invece indica come io pago mediamente i miei debiti con questo sottotipo di pagamento.


  2. tempi ritardo per rating/sottotipi pagamento che riportano il tempo medio di ritardo per rating, ad esempio mi permette di dire che per i clienti/fornitori inderogabili di tipo rimessa diretta io incasso e pago puntualmente con 0 giorni di ritardo. Per pagamenti quali ad esempio le ri.ba. dati i meccanismi attuali i giorni di inc./pag7.sono 0. È un meccanismo utile per stabilire la data di incasso prevista/pagamento.


  3. (più specifico e quindi più prioritario) sottotipi pagamenti cli.\for. (si deve accedere all'anagrafica clienti dall'apposita voce del menu strumenti), tale tabella con la tesoreria extended può essere alimentata dall'utente e/o da un'elaborazione statistica.
    Questa tabella viene alimentata automaticamente da un'elaborazione statistica se c'è la tesoreria extended.



    Questa tabella riporta il livello più specifico sui tempi medi che ho per ogni sottotipo pagamento per cliente fornitore. Ad esempio per un cliente posso stabilire:
    • quando paga con ri.ba. i giorni di inc.\pag. sono 0
    • quando paga con bonifico i GG di ritardo sono 10
    • quando paga con rimessa diretta i GG di ritardo sono 20

Campi aggiunti su tabelle esistenti

Nella tabella pagamenti è stato inserito il campo cod. sottotipo da impostare su tutti i cod. pagamento obbligatoriamente (le procedure di conversione archivi operano già in tal senso).

Nella tabella delle banche sono stati inseriti due campi in più per realizzare il collegamento alla tabella rapporti bancari di DocFinance (codice banca e tipo rapporto, quando è richiesta integrazione con DocFinance, i codici da specificare sono quelli di DocFinance non quelli di Business), più conto per anticipi su conti di tipo SBF e il 'Saldo anticipazioni su C/C da conto portafoglio' da indicare se parto da un dato che non è l'inizio e devo dare la quota di sbf che ho anticipato (che ho finanziato).

Un altro campo aggiunto nella tabella banche è il tipo rapporto, che in presenza di stessi codici di ABI e CAB permette di specificare più record dove varierà il tipo rapporto, ovvero quando codifico codici banca accomunati codici ABI e CAB, inserirò due codici banca che sono riferiti a tipi di rapporto diversi, quindi la presenza di stesso ABI e CAB significa che è la stessa banca.

Per esempio se noi abbiamo del portafoglio su Unicredit avremo:

  • Unicredit c\c
  • Unicredit sbf (dove presento le distinte)
  • Unicredit c\anticipi sbf (se anticipo una parte delle ri.ba.)
  • Unicredit anticipo fatture (se ho una linea di credito sull'anticipo delle fatture)

Nell'anagrafica clienti/fornitori (e per sottoconti) è stato inserito il combo rating finanziario e il cod. voce finanziaria dettaglio.

Campi aggiuntivi sullo scadenzario (SCADEN):

  • codice sottotipo pagamento, non obbligatorio se non si usa la nuova tesoreria (NB: le procedure di conversione provvedono già ad aggiornare il campo sui record esistenti)
  • nota autorizzativa, per default è zero, ma la posso inserire per riqualificare quel credito; questa informazione compare nel reporting esteso clienti/fornitori in modo che chi la consulta possa verificare se ci sono delle situazioni incagliate
  • data prevista incasso pagamento è la data che rientra in maniera più significativa nelle mie analisi a breve termine, è più significativa rispetto alla data di scadenza che è solo teorica
  • data prevista bloccata flag da usarsi dove ci sono situazioni in cui magari a fronte di un credito si concorda con il debitore una data prossima di rientro e quindi il cliente forza la data, quindi per evitare che il sistema la vada a sovrascrivere allora si mette questa spunta per avvertire che non deve essere ricalcolata dal sistema (pilotata dall'utente)
  • insoluto rata originaria viene messo quando dichiaro un insoluto e apro una nuova scadenza, questo perché mancava il collegamento con la rata originaria. Non consentiva di calcolare conto dei giorni di ritardo incasso/pagamento. NB: non è gestita l'informazione sui record antecedente al passaggio a .NET 2012!
  • Colonna insoluto è un combo a tre valori e non più un check. Quando registro un insoluto il programma oltre a mettere insoluto sulla nuova rata il programma marca come Insoluto anche la rata originaria. NB: non è gestita l'informazione sui record antecedente al passaggio a .NET 2012!


Nella gestione insoluti è utile l'informazione relativa alla scadenza originaria nel caso in cui ci sia un raggruppamento effetti e per il calcolo dei giorni di ritardi si ragiona sulla scadenza originaria e si 'annulla virtualmente' la registrazione di raggruppamento effetti, cioè si considera come se non fosse mai stata fatta.

  • data scadenza originaria (non gestita al momento)
  • numero ABDP contiene il codice di collegamento all'archivio degli incassi differiti
  • NB: il campo data documento è obbligatorio se c'è il nuovo modulo della tesoreria attivo, poiché certi calcoli sono eseguiti sulla data documento

Nuovo archivio delle scadenze extra contabili

Tale archivio è gestito dalla nuova tabella SCADENEC, che non è legata però a registrazioni contabili e non contiene il concetto di numero rata, ma ha un progressivo numerico, in parte gestito a mano tramite scadenze inserite manualmente dall'operatore ed in parte generate da Business prelevando i dati da ordini, ddt da fatturare, proposte d'ordine, ...

Come struttura è simile alla tabella SCADEN, ma non impone registrazioni contabili, quindi da un punto di vista tecnico la chiave non è più individuata da conto\anno\serie\num. doc.\num. rata ma è un progressivo numerico.

La struttura di SCADENEC (differenze rispetto a scaden):

  • ha un progressivo (come chiave)
  • l'origine

Gestione scadenziario extracontabile

Qui possono essere registrate entrate e uscite future anche su conti non gestiti a partite e scadenze che io voglio siano compresi nelle mie analisi future. L'utente quindi inserirà manualmente le entrate e uscite quali pag. stipendi, pagamento tasse, pag. contributi, ... Non vengono estratti movimenti da elaborazioni quali liquidazione IVA o elaborazioni delle provvigioni. Lo scadenzario extracontabile è composto da:

  • scadenze inserite manualmente
  • scadenze estratte in automatico dal programma di estrazione dati extracontabili (impostabile attraverso opzioni di registro) aventi come origine gli ordini, le proposte d'ordine, le bolle da fatturare e le fatture non contabilizzate

Invece la data prevista inc.\pag. viene calcolata applicando i giorni medi di ritardo incasso\pagamento in base alle priorità indicate precedentemente.

Attualmente per escludere rate di scadenziario che sono già scadute non c'è un automatismo che da gestione prima nota me le vada 'a saldare', l'unico modo per escluderle è quindi CANCELLARLE. L'archivio delle scadenze extra-contabili almeno per le scadenze manuali sono costretto a eliminarle. Per cui prima di fare un'analisi finanziaria l'operatore deve entrare nell'archivio delle scadenze extra contabili e cancella la riga di scadenza.

Ci sono le stesse informazioni che abbiamo nello scadenziario per avere una vista complessiva, in questo modo nel datawarehouse posso avere una visione globale sia di informazioni che sono in contabilità che di informazioni che non sono in contabilità.

C'è un aspetto da considerare riguardo lo scadenzario extra-contabile: la generazione automatica cancella tutto e rigenera le scadenze (a parte quelle manuali). Per cui se nello scad. extracontabile avessi modificato con delle note autorizzative alcune delle scadenze generate da Business queste verrebbero perse (interventi manuali). Per evitare che le scadenze vengano rielaborate va messa la spunta su 'Data prevista bloccata.'

Per l'inserimento di scadenze multiple manuale, è possibile inserire più righe in modo massivo tramite la funzione calcola scadenze, basta inserire una nuova riga e specificare il conto e poi richiamare la voce 'calcola scadenze' dal menu strumenti.

A questo punto posso scegliere due modi di esplosione o da calcolo da codice di pagamento (specificando un codice di pagamento, la data di riferimento e l'importo complessivo del finanziamento) o tramite l'impostazione di parametri (inserendo una data di riferimento, l'importo della rata singola, il numero di rate, in quale giorno del mese si paga la rate). Scelto il modo e configurato occorre poi fare calcola per avere una anteprima delle rate generate (mi consente di modificare a video le rate).

A questo punto confermando le rate vengono inserite nella gestione scadenze extracontabili.

Tramite la colonna selezione è possibile eventualmente eliminare contemporaneamente più righe.

Estrazione dati extracontabili

Viene estratto con il programma di estrazione dati extracontabili, con opzioni di registro (estrai scadenze extracontabili), che applica i tempi medi di ritardo nel calcolo data prev. inc./pagamento (con la tecnica di escalation ).

Questo programma può anche essere schedulato e ci sono due date in maschera e due opzioni di registro:

  • la data di 'Elabora dalla data doc./cons.' serve per partire da un punto nel passato senza rielaborare tutto, in generale dovrei elaborare tutto ma probabilmente in una situazione più verosimile non vorrò elaborare dei dati troppo vecchi
  • la data 'Nuova data scadenza/consegna' serve per assegnare questa data piuttosto che impostare la data scadenza antecedente che verrebbe assegnata da DDT e ordini con consegne scadute, in pratica invece di mettere come data scadenza una data antecedente alla data elaborazione questo programma mette la data qua presente
  • BNTFESEC\OPZIONI\ControlloCommesse = N (default) prende la commessa dalla testata dell'ordine/bolla; S = dalle righe (quindi mi indica se il cod. commessa debba essere preso dalla testata o dalla bolla)
  • BNTFESEC\OPZIONI\UsaContoFattDoc = N (default) non gestire il conto fatt. ; S = tieni conto del valore del campo conto fatturazione

Estrazione dati extracontabili (cosa tratta):

  • DDT emessi da fatturare (sempre)
  • DDT ricevuti da fatturare (sempre)
  • Carichi prod . da terz da fatturare (sempre)
  • Resi fornit da fatturare (sempre)
  • Resi clienti da fatt. (sempre)
  • Ordini fornitori (parte inevasa) -> opzione , T=tutti N=non conf S=solo conf.
  • Ordini prod. Terzisti -> opzione, T=tutti N=non conf S=solo conf.
  • Impegni clienti -> opzione, T=tutti N=non conf S=solo conf.
  • Impegni cli aperti -> opzione, T=tutti N=non conf S=solo conf.
  • Ordini forn aperti -> opzione, T=tutti N=non conf S=solo conf.
  • Prop ordini fornitori -> Opzione: N=no default, S=si
  • Prop ordini produzione -> Opzione: N=no default, S=si
  • Documenti clienti non contabilizzati (*)-> opzione : N=no, default , S=si
  • Documenti fornitori non contabilizzati (*)-> opzione : N=no, default , S=si

(*)= fatture e note accredito, di vario tipo

Funzionalità BATCH sottostanti al nuovo modulo sono:

  • ricalcolo data prevista incasso/pagamento sullo scadenziario (serve per le analisi finanziarie), utilizzato dentro i due programmi per le stampe (tramite apposito check) e sempre nell'estrazione dati scadenze extracontabili
  • aggiorna tempo medio ritardo su clienti fornitori/sottotipo pagamento, che determina tempo di inc./pag. e ritardo, inglobato nelle stampa del reporting cliente
  • estrazione scadenze extracontabili

Query di avviamento sistema (conversione)

  • inserita una tabella standard di sottotipi, equivalente a tipo pagamento
  • inserito sottotipo pag. sulle forme di pagamento
  • aggiornato su scadenze esistenti il sottotipo pag., la data documento (uguale alla data registrazione), data prev. incasso pag., e data originaria
  • NB: non è possibile settare il numero rata riferimento sulle scadenze per gli insoluti

Le logiche contabili sottostanti ai mov. finanz.

La tesoreria si innesta su operazioni che l'utente fa abitualmente (incassi, emissioni ri.ba., distinte, ...), quindi per generare dei report significati (senza vincoli o meno rispetto alla vecchia tesoreria) occorre adottare una metodica specifica nelle registrazioni del flusso contabile, cioè delle regole, in base allo scenario che volgiamo gestire. Business deve sapere come sono fatte le registrazioni per fare delle interrogazioni sulla tesoreria, quindi occorre imporre flussi contabili ben definiti; se non ci sono tali presupposti (verificare con il cliente i flussi contabili di Business) la nuova tesoreria non può essere applicata.

Tre scenari applicativi:

  • Con chiusura cliente (classico), senza DocFinance
  • Senza chiudere il cliente (senza DocFinance)
  • In presenza di collegamento a DocFinance (il cliente si chiude)

NB : Obbligatoria l'adozione di tali logiche. Una metodica della gestione del flusso contabile è essenziale e dobbiamo dare delle regole per sapere come sono fatte le registrazioni e quindi dobbiamo imporre un flusso contabile bene definito.

Riepilogo dei conti usati nei giri contabili (no DocFinance)

Dobbiamo verificare quali sono i conti su cui ruota la nuova tesoreria.

*=senza chiudere il cliente

I conti di tipo Banca x c\c vanno gestiti a data valuta.

Il conto Banca x c/sbf non va gestito a data valuta. Questa è una differenza rispetto alla gestione con la vecchia tesoreria. Non abbiamo bisogno di gestire la data valuta in quanto la disponibilità nel tempo collegata a questo conto è (leggiamo dalle scadenze degli effetti) canalizzata sui vari conti

Il conto Banca x c/anticipi sbf non va gestito né a partite né a scadenze. Questo conto serve a gestire l'anticipo su sbf. Se anticipo dei soldi sul portafoglio presentato si tratta di un finanziamento e quindi la rappresentazione più corretta é farlo comparire tra i debiti. Per cui se viene fatto un anticipo sull'sbf non devo chiudere il conto sbf ma devo aprire il conto anticipi su sbf.

Il conto Banca x c/anticipi su fatture va gestito a partite e scadenze (non serve gestirlo a data valuta). Per quanto riguarda il giro del conto anticipi sulle fatture è un conto simile al conto anticipi su sbf ma non ho il conto ri.ba. (Effetti attivi) a monte.

Cassa assegni è un conto utilizzato per la gestione degli assegni post-datati ricevuti. Deve essere gestito a partite ma non a scadenze. Può anche essere gestito non a partite ma gestito a data valuta. È un vantaggio il fatto di gestirlo a partite in quanto mi consente di consultare il partitario 'A partite'. Non è fondamentale in quanto ho un archivio degli assegni dal quale posso visualizzare quali assegni sono aperti e quali no.

Il conto Clienti c/rb gestito va utilizzato quando emetto gli effetti e non chiudo il cliente. È un conto di tipo Sottoconti e va gestito a partite e scadenze.

Esempio di codifica delle banche

Le tipologie di rapporti bancari gestiti sono 4:

1. conto corrente;

2. conto salvo buon fine;

3. conto anticipi salvo buone fine;

4. conto anticipi su fatture

Un esempio di codifica può quindi essere il seguente:

Conto corrente

Conto Salvo Buon Fine

Conto Anticipazione da SBF

Conto Anticipi su Fatture

Clicca per accedere al sito di NTS Informatica