La gestione partite è stata sviluppata a layer così
da isolare ciò che è l’elaborazione vera e propria delle partite da ciò che
è la rappresentazione visuale più sensibile di personalizzazione cliente.
Pre Elaborazione
Il motore analizza i movimenti contabili del
soggetto con una precisa priorità di tipo documento:
1.
Invoice
2.
Credit Memo
3.
Blank
4.
Payment
5.
Dishonored
6.
Refund
Per ogni movimento si analizzano I movimenti
dettagliati per comprendere il collegamento tra le partite gestendo anche i
collegamenti relativi alle esposizioni RIBA.
Nei movimenti dettagliati viene applicata anche una
rigenerazione degli stessi per sopperire ai problemi di “importo applicato”
nel caso di collegamento molti a molti.
Il termine della elaborazione di questi movimenti
confluisce in un buffer “Assets Detail” temporaneo:
In questo esempio le prime tre righe si possono
leggere come “il movimento 2430 (fattura 00-1) è una partita principale ed è
chiuso da due movimenti 2584, 2586 e 2588 di tipo pagamento. L’intero blocco
ha il flag “Aperto” a falso segno che la partita è chiusa.
Il dettaglio generato viene riconfrontato (Funzione
“ProcessCustomerAssetsMerge” per i clienti) con i movimenti contabili al
fine di garantire la correttezza dei saldi anche in caso di errore di
analisi o dei movimenti.
Questo punto è particolarmente importante:
Qualora per un errore di analisi o nei dati un
movimenti contabile avesse, ad esempio, un saldo 1000 euro mentre secondo le
partite fosse solo 900, il motore inserirebbe automaticamente un movimento
di dettaglio per 100 euro al fine di far quadrare il saldo della partita
principale (che nella rappresentazione ad albero è il livello 2). Le partite
principali hanno sempre, by design, il valore corretto.
Generazione struttura ad albero
Per semplificare la
generazione di un dettaglio visivamente chiaro il dettaglio generato
precedentemente viene rielaborato in una struttura ad albero definito così:
1.
Partita principale, che generalmente intende
la fattura o qualsiasi movimenti con un residuo
2.
Rata
3.
Movimento collegato, che chiude completamente
o parzialmente la rata
4.
Informazione del movimento insoluto nel caso
il livello 3 sia una riba tornata non pagata.
Durante questa fase vengono valorizzati anche tutti i
campi relativi alle RIBA, eliminati i documenti chiusi e le rate con
scadenza fuori dai filtri.
Il buffer generato, anch’esso temporaneo, è il
seguente:
E’ immediato vedere che qualsiasi stampa che vuole
mostrare il saldo delle rate gli basta filtrare per “Livello = 2” mentre se
vuole mostrare anche i movimenti collegati gli basta filtrare per “Livello =
2..3”.
Ogni record di livello 2 è collegato al livello 1
tramite il campo “Node linked to”. Idem i livelli sotto e questo rende
semplice identificare come sono collegati i vari record.
Debug
Per rendere più semplice il debug, sia da eventuali
errori di analisi sia dei dati sono presente alcune funzionalità apposite.
Il primo problema è il debug di dettagli generati in
modo “temporaneo” dalle procedure e quindi non persistente in tabella.
Sulla page sono presenti due action nascoste che
possono essere portate a video andando in personalizzazione della page:
Il pulsante “Debug” fa si che il dettaglio di pre
elaborazione venga salvato sulla tabella “Assets Detail” e quindi sia
possibile analizzarlo facendo il run della tabella.
Il pulsante “Download Debug Excel” genera due
documenti excel relativi al dettaglio di pre elaborazione e del buffer della
page, visualizzando infine il download.
Nella tabella “Assets Detail” sono presenti due campi
di debug:
Il primo campo è “ID Interno”. Esso è un valore che
definisce quale è la procedura che ha inserito o modificato il record in
analisi.
Nella prima funzione “GetCustomerAssets” quel campo è
definito come il tipo documento in elaborazione:
Pertanto I è Fattura (Invoice), C è la nota di
credito (Credit Memo), B (Blank), etc.
Ogni movimento principale causa l’inserimento delle
partite di bilanciamento (i movimenti collegati).
Ad esempio se vediamo “1” possiamo cercare nella
codeunit il testo ‘1’ e troveremo:
Che è la prima funzione di analisi dei movimenti
dettagliati.
“P6” invece significa che il movimento è stato
inserito durante l’elaborazione dei Paayments e successivamente è stato
toccato dalla funzione “6” che corrisponde:
Che è la funzione che valorizza il campo “Partita
collegata”.
Il secondo campo è “Debug Sequence” che è un numero
progressivo di come sono stati inseriti i record in tabella. Questo fornisce
un ordine “cronologico” di elaborazione e assieme al campo descritto in
precedenza da una visione abbastanza chiara di come il modulo ha elaborato,
prima di addentrarsi nel debug passo a passo.
|
Type |
ID |
Name |
|
Table |
18004100 |
Assets Detail |
|
Table |
18004101 |
Assets Buffer |
|
Report |
18004137 |
NP Customer Aging |
|
Report |
18004138 |
NP Vendor Aging |
|
Report |
18004141 |
NP Vendor Aging (In Column) |
|
Report |
18004149 |
NP Customer Aging (In Column) |
|
Report |
18004255 |
NP Customer Statement |
|
Report |
18004256 |
NP Vendor Statement |
|
Report |
18004262 |
NP send fin. report to salesp. |
|
Report |
18004263 |
NP send fin. report to cust. |
|
Codeunit |
18004100 |
Assets Engine |
|
Page |
18004125 |
Assets Analysis |
| Query | 18004100 | Open CustLedgerEntry1 |
| Query | 18004101 | Open CustLedgerEntry2 |
| Query | 18004102 | Dishonored CustLedgerEntry3 |
| Query | 18004103 | Open VendLedgerEntry1 |
| Query | 18004104 | Open VendLedgerEntry2 |
