Stampe > Modulo Contabilità > Stampa BALAGEHIST (Ageing storicizzato) 

Il bilancio con ageing storicizzato permette di ricostituire il saldo alla data per una determinata data di riferimento.
Questa stampa può quindi essere confrontata con il bilancio generale ausiliario per disporre della giustificazione del saldo contabile alla data di riferimento.
Tale stampa vuole inoltre essere uno strumento di lavoro utile per il controllo delle scadenze clienti e fornitori.

Prerequisiti

Nel caso in cui si debba confrontare questa stampa con quella del bilancio generale terzi del Partitario Terzi, il criterio 'Pagamenti non validati' deve essere posizionato a 'Non'.

SEEINFO I movimenti in simulazione attiva vengono sistematicamente presi in considerazione, mentre quelli in simulazione non attiva non lo sono mai.

Elenco dei criteri

Parametro

Descrizione parametro

Tipo

societe

Società

CPY

sitedeb

Sito da/a

FCY

coldeb

Collettivo da/a

SAC

grpcol

Gruppo collettivi

GSC

tiersdeb

Terzo da/a

BPR

borne1

N. di giorni 1

C

borne2

N. di giorni 2

C

borne3

N. di giorni 3

C

borne4

N° di giorni 4

C

borne5

N° di giorni 5

C

ecrisim

Movimenti simulati (Menù locale No, Si)

M1

datref

Data di riferim.

D

sens

Segno (Menù locale Dare, Avere)

M626

detpce

Dettaglio per scadenza (Menù locale No, Si)

M1

tri

Ordinamento (Menù locale Numero, Titolo, Titolo breve)

M676

impselections

Stampa selezioni (Menù locale No, Si)

M1

Principi tecnici di aggiornamento della tabella di storicizzazione delle scadenz

La tabella di storicizzazione delle scadenze HISTODUD viene utilizzata dalle funzioni di consultazione del bilancio con ageing alla data (CONSBAH e CONSBAHF) e dalla stampa del bilancio con ageing storicizzato BALAGEHIST.
Questa tabella viene aggiornata non appena si crea una scadenza, poi ad ogni aggiornamento di una scadenza.

Tutti i campi che caratterizzano una scadenza non sono storicizzati. Così, il modo di pagamento, il livello di pagabile, i dati relativi ai solleciti non sono delle informazioni i cui aggiornamenti vengono monitorati.

I principali campi della tabella HISTODUD che vengono utilizzati sono:

  • la data dell’evento (DATEVT) che corrisponde alla data contabile alla quale accade l'evento.
  • lo stato della scadenza (DUDSTA) che precisa se una scadenza è collegata ad un documento contabilizzato o semplicemente ad un documento inserito (ad esempio una fattura inserita ma non contabilizzata).
    • DUDSTA=2 se la scadenza è associata ad un documento contabilizzato,
    • DUDSTA è diverso da 2 se la scadenza è associata ad un documento non contabilizzato. Il terzo ed il collettivo della scadenza (BPR e SAC) che contengono il terzo ed il conto collettivo sui quali la scadenza è contabilizzata.
  • il campo Saldata (FLGCLE), che caratterizza la scadenza rispetto al suo saldo, può assumere i seguenti valori: 
    • se FLFCLE=1 o 0, la scadenza è non pagata/saldata oppure pagata/saldata parzialmente,
    • se FLGCLE=2, la scadenza è definitivamente pagata/saldata (importo della scadenza AMTCUR = importo pagato contabilizzato PAYCUR e AMTCUR)<>0 ; o AMTCUR=0 e importo scadenza AMTLOC = importo pagato contabilizzato PAYLOC),
    • se FLFCLE=3, la scadenza ‘storiciczzata’ viene cancellata,
    • se FLGCLE=4, la scadenza viene pagata/saldata 'temporaneamente' (importo della scadenza AMTCUR = importo pagato contabilizzato a fronte della scadenza PAYCUR + importo provvisorio pagato a fronte della scadenza TMPCUR).

Precisazioni sul campo Data evento

A - Nel caso di una contabilizzazione di fattura, la data dell’evento corrisponde alla data contabile della fattura.

B - Nel caso di un pareggio parziale o completo di una scadenza (via l'imputazione diretta di un pagamento alla scadenza o il pareggio contabile), per la/le scadenzae pagate, la data evento corrisponde alla data contabile più alta dei movimenti del gruppo al momento del pareggio.

Esempio:
Si abbia:

  • un pagamento di un acconto intervenuto in data contabile T1,
  • la contabilizzazione di una fattura in data contabile T2,
  • contabilizzazione della ripresa di acconto in data contabile T3.

I documenti del gruppo saranno considerati come saldati alla DATEVT=data contabile più alta dei documenti del gruppo e quindi T3.

Nel caso di una scadenza parzialmente o totalmente saldata definitivamente (e quindi associata ad una riga di movimento con un codice pareggio minuscolo o maiuscolo), la data evento considerata ad ogni pareggio corrisponde alla data contabile massima dei movimenti del gruppo al momento del pareggio (e quindi a MTCDATMAX di GACCENTRYD).

SEEWARNING Secondo il metodo di pareggio, l’alimentazione della tabella HISTODUD e di questa data evento variano.

Esempio:
Si abbia una fattura contabilizzata in data T1 per 1.000 €, seguita da due pagamenti in data T2 e T3:

  • uno di 600 € in data contabile T2
  • uno di 400 € in data contabile T3.

Si distinguono due casi:

  • la fattura inzialmente viene pagata parzialmente per 600 (pagamento contabilizzato in T2) poi saldata dal pagamento di 400 (contabilizzato in T3),
  • i tre movimenti sono contabilizzati separatamente ed il pareggio avviene solo a posteriori, via il pareggio contabile (funzioni LETTRAGE o LETTRAUTO).

Nel primo caso, la storicizzazione rifletterà lo storico di pareggio:

  • alla data di riferimento T1, la fattura apparirà con il suo importo totale,
  • alla data T2, la fattura apparirà con un saldo di 400,
  • alla data T3, la fattura non apparirà più.

Nel secondo caso, trattandosi di un pareggio manuale di tre movimenti contabili, anche la data evento sarà la data contabile più alta ma il risultato sarà leggermente differente:

  • alla data di riferimento T1, la fattura apparirà con il suo importo totale,
  • alla data T2 appaiono la fattura con il suo importo totale di 1000 € ed il pagamento di 600 €,
  • alla data T3, la fattura ed il pagamento non appaiono più.

SEEINFO  Il risultato del primo scenario può essere ottenuto alla stessa maniera via il pareggio contabile se la fattura ed il pagamento di 600 € vengono pareggiati in una prima manipolazione. Il gruppo di pareggio di due movimenti con il pagamento di 400 € viene pareggiato in seguito in una seconda manipolazione. 
Queste manipolazioni sono possibili nella misura in cui lo storico di pareggio sarà stato ricostituito dall’utente mediante la scomposizione delle fasi di pareggio manuale.

C - Nel caso di un trasferimento di collettivo, non verrà creata nessuna registrazione, dato che le precedenti registrazioni vengono aggiornate per il codice collettivo e che la data evento non si sposta.

D -  Nel caso di una fusione di terzi, il principio è identico a quello del trasferimento di collettivi: nessuna creazione di nuova registrazione nella tabella HISTODUD, ma un semplice aggiornamento delle registrazioni esistenti senza modifica della data evento.

Descrizione della stampa