Storicizzazione delle scadenze
Questo strumento permette di risincronizzare la tabella di storicizzazione delle scadenze (HISTODUD) che viene aggiornata quando il codice attività HDU è attivo e non appena viene modificata una scadenza.
Tale risincronizzazione può essere di due tipi:
- primo caso: rilevamento di anomalie sui record esistenti e correzione di queste anomalie, ma senza creazione di nuovi record. In questo caso, la risincronizzazione/correzione effettua due tipi di controllo:
- la ricerca di incoerenze tra i dati della tabella di riferimento (GACCDUDATE) e quelli della tabella di storicizzazione delle scadenze (HISTODUD).
Se vengono individuate incorenze tra le due tabelle, la tabella HISTODUD viene riaggiornata mediante la risincronizzazione sulla base del contenuto della tabella GACCDUDATE. - la verifica di coerenza di alcuni dati propri della tabella HISTODUD sulla base di un determinato numero di regole.
- secondo caso: cancellazione dei record esistenti (se ve ne sono) e creazione di nuovi record di storicizzazione:
- la ricostituzione dei record di storicizzazione ha lo scopo di eliminare i record già costituiti e crearne di nuovi, compreso il caso in cui il codice attività HDU fosse attivato in corso di utilizzo.
Questa ricostituzione della storicizzazione non si basa sui flussi dei moduli a monte della contabilità bensì sul pareggio(per saperne di più...).
Prerequisiti
Riferirsi alla documentazione di Implementazione
Gestione videata
Le due caselle da contrassegnare Risincronizzazione e Cancellazione permettono di scegliere una delle due modalità operative di aggiornamento della tabella HISTODUD.
La casella Traccia dettagliata permette di ottenere un elenco dei record modificati o creati dalla risincronizzazione.
Combinazioni possibili ed impatti
Risincronizzazione | Cancellazione | Traccia dettagliata | Impatti | Esempi di informazioni ottenute nella traccia | |
No | No | No | File traccia che elenca le anomalie nei record esistenti. Nessuna correzione né creazione. | Documento FAC FCRHDU10102VEN00001 Riga 1 Scadenza 1 (151016) | Con l'informazione del numero di scadenza storicizzata ([F:HDU]NUMHDU) e la natura dell’anomalia (come una DATEVT errata). |
Si | No | No | Correzione delle anomalie rilevate sui record esistenti. File traccia che elenca le anomalie corrette. | Documento FAC FCRHDU10102VEN00001 Riga 1 Scadenza 1 (151020) |
|
No | Sì | No | File traccia che elenca i record che lo strumento può eventualmente creare se viene lanciato in effettivo (senza tener conto di quelli già esistenti). | Documento FAC FCRHDU10102VEN00001 Riga 1 Scadenza 1 | Con alla fine l'informazione della DATEVT applicata se lo strumento viene lanciato in effettivo. |
No | Sì | Sì | File traccia che elenca i record esistenti che verranno cancellati se lo strumento viene lanciato in effettivo. File traccia che elenca i record che lo strumento può eventualmente creare se viene lanciato in effettivo (senza tener conto di quelli già esistenti). | *** 150983 10/02/11 Documento FAC FCRHDU10102VEN00001 Riga 1 Scadenza 1 | Il record da cancellare è identificato grazie al suo [F:HDU]NUMHDU e la sua DATEVT. Con alla fine l'informazione della DATEVT che verrà applicata se lo strumento viene lanciato in effettivo. |
Si | Si | No | Cancellazione dei record esistenti e creazione dei nuovi record di storicizzazione delle scadenze. | Documento FAC FCRHDU10102VEN00001 Riga 1 Scadenza 1 |
|
Si | Si | Sì | Cancellazione dei record esistenti e creazione dei nuovi record di storicizzazione delle scadenze. | Documento FAC FCRHDU10102VEN00001 Riga 1 Scadenza 1 |
|
Videata di inserimento
Campi
I seguenti campi sono presenti in questo folder :
Testata
| Nessun help collegato a questo campo. |
Criteri
| Nessun help collegato a questo campo. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Blocco numero 3
| La risincronizzazione si effettua solo sulle registrazioni il cui Stato DUDSTA ha il valore 'due', che corrisponde ad una scadenza collegata ad un documento contabilizzato (contrariamente per esempio alle scadenze collegate alle fatture non contabilizzate). Un certo numero di campi della tabella HISTODUD non viene aggiornato:
Alcuni campi sono risincronizzati mediante l'applicazione di una regola:
|
| L’opzione ‘Cancellazione’ crea dei nuovi record di storicizzazione. I dati del file delle scadenze costituiscono il punto di partenza di questa creazione.
LIMITE n°1La risincronizzazione con cancellazione non si basa sui flussi nei moduli a monte della contabilità bensì sull’evento contabile del pareggio. Esempio: LIMITE n°2La risincronizzazione con cancellazione non permette di gestire il caso di un annullamento di pagamento che interverrebbe a posteriori di questa risincronizzazione. Esempio: Rilanciando una risincronizzazione con cancellazione sul relativo terzo, i nuovi dati dello storico vengono ricostituiti senza questo limite. |
| Se si richiede la traccia dettagliata, il file traccia viene completato con l'elenco dei record HISTODUD che possono venire cancellati nella fase di cancellazione (con o senza risincronizzazione). |
Chiudi
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).
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ù.
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.
Job batch
Questa funzione può essere lanciata in batch. Il job standard ACCRECHDU è previsto per questo.
Messaggi di errore
Oltre ai messaggi generici, i seguenti messaggi d'errore possono apparire al momento dell'inserimento :
Alcuni campi collegati direttamente alla tabella di riferimento GACCDUDATE sono aggiornati, i messaggi di errore sono allora identici a quelli utilizzati nella risincronizzazione delle scadenze, ovvero:
- ACCNUM: Numero interno errato
- CPY: Società errata
- FCY: Sito errato
- CUR: Valuta errata
- SNS: Segno errato
- SAC: Colletivo errato
- BPR / BPRTYP / BPRPAY: Terzo errato