Newsgroup: it.comp.appl.access
Titolo: Struttura ad albero dinamica. piano dei conti

Ciao a tutti,
Volevo aprire una breve discussione su alcuni principi di base.
Penso che tutti sappiano che il database relazionale non può gestire in 
maniera nativa una struttura ad albero come un piano dei conti, nel senso 
che richiede alcuni accorgimenti.
Personalmente ne ho fatti alcuni statici (tipo piano dei conti a tre 
livelli, riducibili a due con un piccolo artificio dell'utente) e altri 
dinamici.
Non sono però convinto di aver sempre inquadrato la via migliore.
Inutile dire che l'ideale sarebbe un piano dei conti dinamico, ma questo 
richiederebbe la gestione di relazioni piuttosto complesse, per non parlare 
del fatto che per collegare la radice d'origine nonchè tutti i nodi alle 
relative foglie richiederebbe passaggi seccanti e che presentano alcuni 
rischi nel mantenimento dell'integrità.
Ora sto creando un piano dei conti dinamico e ho diverse possibili scelte, 
ad esempio (se dico cavolate non fateci caso, è l'orario):
Mastri e conti superiori in unica tabella autoreferenziata
conti finali in un'altra tabella con riferimento al conto superiore nella 
tabella precedente.
Funziona ma, dato che il piano dei conti è dinamico, richiede la creazione 
dinamica delle query per collegare mastri e conti a tutti i relativi 
sottoconti.
Oppure mastri e conti tutti in un unica tabella autoreferenziata (fattibile 
ma a mio giudizio pericoloso e co0munque presenta lo stesso inconveniente di 
prima)
Oppure creare una struttura dinamica solo apparente nel senso che si danno 6 
o 7 livelli di sottoconti e nel caso se ne usino meno si usano i sottoconti 
in più solo come riferimento per arrivare al conto finale. In questo caso 
non ci sarebbe bisogno di query dinamiche ma si avrebbe comunque una 
situazione molto articolata per collegare il mastro o i sottoconti a tutti i 
suoi sottoconti finali.
Oppure si può nel sottoconto finale referenziarlo con tutti i livelli 
superiori avendo così la possibilità di richiamare direttamente i sottoconti 
finali partendo dal mastro che ci interessa, ma si avrebbe una ridondanza 
dalla preicolosità devastante in caso di errore dell'utente (eliminazione o 
modifica di un riferimento e simili).
Mi interesserebbe l'opinione di chi si sia interessato del problema.
Ciao a tutti
Davide (Sib) 


Nel caso specifico del piano dei conti non riesco a comprendere il 
superamento di 3 livelli.
La struttura  dovrebbe essere molto rigida e gerarchizzata.
Del tipo
Gruppo, Mastro, Sottoconto
10.20.30
Dove 10 identificanto attività, passività, costi, ricavi; 20 un 
raggruppamento del tipo oneri, spese generali, debiti v/enti ecc e 30 
rappresenta il vero e proprio mastrino.
Se quindi il pdc è popolato come segue non credo hai bisogno di chissà 
quale invenzione
10.0.0 Qui non ci sono mai movimenti
10.10.0 Qui non ci sono mai movimenti
10.10.2
10.10.3
10.20.0 Qui non ci sono mai movimenti
10.20.1
10.20.2
10.20.3
20.0.0 Qui non ci sono mai movimenti
20.20.0 Qui non ci sono mai movimenti
20.20.1
20.20.2
20.20.3
E così via
Ciao
-- 
Daniele
Rispondere scartando OneEDP, spam e 32

 superamento di 3 livelli.
Non e' cosi'. Personalmente mi sono trovato a gestire un piano dei conti 
(circa 13.000) che arrivava fino al 6' livello e non sempre il 6' 
livello era il livello di dettaglio. Quindi piano dei conti "dinamico" 
quello che descrive sib (che saluto) oserei dire che e' "semidinamico" 
poiche', se non ho capito male, il livello di dettaglio e' comunque 
sempre il piu' basso.


13.000 clienti e fornitori compresi?
Cmq mi piacerebbe comprendere con te le motivazioni "contabili" di 6 o 
più livelli.
C'è sempre da imparare qualcosa no?
Grazie
Per quanto riguarda i livelli in sql server ci sono le CTE con anchor 
member e via dicendo che gestiscono benissimo queste situazione.


 C'è sempre da imparare qualcosa no?
Prova a pensare alle necessita' di un grande ente statale presente su 
tutto il territorio nazionale (ed anche extranazionale) con necessita' 
di raggruppare per dipartimento, dipartimento territoriale, servizio, 
tipo del conto e dettaglio.
I clienti/fornitori non erano poi molti ma anche quelli per necessita' 
statistiche spesso richiedevano una codifica gruppo/sottogruppo.
Probabilmente se vedi il piano dei conti funzionale solo alla produzione 
di un bilancio di 3 o 4 pagine i tuoi 3 livelli vanno anche bene ma per 
situazioni piu' complesse sono decisamente insufficienti


Moltiplica per n volte le 3 pagine :-)
Fermo restando i 3 livelli, la determinazione significativa del bilancio 
si compone degli ultimi tre credo.
Tutti gli altri livelli gerarchizzati a livello più a vertice possono 
essere implementati anche per esempio gerarchizzando le scritture 
contabili del tipo
dipartimento, dipartimento territoriale, servizio , altro che ne sò 
divisione, ecc...
di seguito
i 3 gruppo,mastro,sottoconto
questo caso va bene se il bilanzio da redigere è topologicamente 
identico per tutti i dipartimenti
In pratica sposterei parte della gerarchia a "livello" di scritture 
contabili, in modo che la codifica in anagrafica abbia sempre gli stessi 
"nomi" riducendo (solo riducendo) il rischi di ridondanze magari 
attribuendo ad una stessa voce di costo due descrizioni  leggermente 
diverse...
Ovviamente non è una possibile soluzione che mi azzardo di dare non 
conoscendo il caso a fondo.
Se poi vogliamo convertire in bilancio cee... è un'altra storia.


 ha scritto nel messaggio

Ciao Alessandro, come va?
Sě, uno dei modelli che ho descritto e realizzato era proprio come dici tu.
Il fatto č che sono alla ricerca di un miglioramento, per questo volevo 
scambiare un po' di opinioni.
Puoi darmi un'idea della struttura dati che hai usato?
Ciao
Davide (Sib) 

 10.20.30
CUT
Quindi la tua struttura coincide con la mia seconda ipotesi, unica struttura 
in cui solo i conti marcati come finali contengono i movimenti.
Anche secondo me è una buona struttura anche se presenta la necessità di 
alcuni accorgimenti per evitare che un utonto (ops, utente) incasini la 
struttura con conseguenze poco prevedibili.
Comunque sulla tua obiezione vorrei prendere l'esempio della liquidità:
1 Disponibilità liquide
1.1 Banche
1.1.1 Banca PippoFranco
1.1.1.1 Conto 123
1.1.1.2 Conto 124
Viceversa devi scrivere:
1 Disponibilità liquide
1.1 Banche
1.1.1 Banca PippoFranco Conto 123
1.1.2 Banca PippoFranco Conto 124
Il che può anche andare ma a livello strutturale è meno coerente perchè non 
puoi raggruppare la liquidità sulla Banca PippoFranco se non con artifici.
Ciao
Davide (sib) 

 Puoi darmi un'idea della struttura dati che hai usato?
Ciao Davide, anche se sono piu' affezionato a sib ;-{)
La struttura e' facile ma ti sara' di poco aiuto poiche' al tempo non 
avevo a disposizione ne relazionale(DB2) ne gerarchico (DL1) ma il tutto 
fu realizzato con un file ISAM mi limitavo a leggere il record che mi 
interessava ed il successivo, un paio di if ed avevo il responso "se po 
fa", "nun se po fa"
Comunque il problema l'ho gestito anche in relazionale e l'ho risolto 
con i soliti campi codice attuale e codice (o ID) che punta al padre 
(classica distinta base,se padre null o zero e' una radice). La logica 
di gestione poi la gestivo via codice mediante una classe ricorsiva e 
gerarchica che generava un btree.
Una cosa del genere, ovviamente, mi consentiva/consente di avere tutta 
la profondita' che voglio (non a caso la gestivo proprio per la distinta 
base) anche solo limitata ai tre livelli a cui OneEDP (;-{)) e' cosi' 
affezionato
--
ac

 affezionato
Come ho risposto anche a One (che peraltro ringrazio per la risposta) già 
solo con le banche raggiungi 4 livelli in men che non si dica:
1 Liquidità
1.1 Banche
1.1.1 Banca Pinco pallo
1.1.1.1 Conto 1
1.1.1.2 Conto 2
Il problema è poi mettere d'accordo i resoconti avendo profondità diverse:
1 Liquidità
1.2 Cassa
Con le banche hai 4 livelli, con la cassa 2, eppure si tratta di quantità 
che vanno messe assieme.
Ci penserò ancora sù
Saluti
Davide 


Anche in questo caso rimango affezionato a 3 livelli :-)
Il problema non è la profondità del pdc, ma la struttura del db.
Se il db gestisce più filiali, bisognerebbe gestire il db stutturando in 
funzione di questo, come ad esempio "spostare" la logica dei livelli 
sulle scritture contabili.
Se l'amministrazione gestisce più filiali organicamente ci sarà un pdc 
identico per ogni filiale. Invece con la gerarchia da te esposta
1.1.1.1 Conto 1
incorri in ridondanze
per cui iscriverei le informazioni relative a banche/banca pinco pallo 
in modo orizzontale sui movimenti contabili sui quali riportare l'ID 
unico del PdC.
In sql server questo comporterebbe ad esempio la possibilià di 
partizionare in modo orizzontale le varie filiali o creare indici sui 
livelli più alti per ottenere performance migliori.
Spero di non aver filosofeggiato troppo :-)



è una possobilità che mi hanno prospettato anche esperti di contabilità.
C'è qualcosa però che mi lascia perplesso, anche se non so ancora 
esattamente cosa.
Ho sempre considerato le informazioni contenute nel movimento come 
informazioni generiche, gestire quindi la catalogazione in base alla causale 
o ad altro campo tipizzante lo trovo molto pericoloso.
Proprio in questi giorni sto sistemando a manina la struttura destinatari di 
un cliente perchè lo hanno incasinato inserendo più volte gli stessi 
destinatari di volta in volta con descriizoni diverse. Il risultato è che la 
catalogazione dei movimenti fa un casino impressionante.
Il piano dei conti tradizionale, invece, data la sua struttura rigorosa, è 
molto più difficile da incasinare anche da parte di utonti.
A tutto questo va aggiunto che non riesco a entrare nella logica della 
contabilità, quando mi sembra di aver capito qualcosa entra un nuovo fattore 
che stravolge tutto e mi fa sembrare la contabilità più vicina alla 
filosofia che alla matematica.
Ciao
Davide (Sib) 

 solo con le banche raggiungi 4 livelli in men che non si dica:
Sulle banche avevo il tuo stesso identico problema e quindi , come si 
suol dire, sfondi una porta aperta
--
ac
porcaputtanalapizza!!!!!!!!!!!!!!!!!!!
Fiuuuuuu......ripresa per un'acciuga

 Fiuuuuuu......ripresa per un'acciuga
Meno male ;-)
Altrimenti a letto senza cena...
Ciao
Davide (sib) 

    
Ciao


 spero che per "orizzontale" tu non intenda quello che penso.
Non intendo la posizione orizzontale :-) intendo le partizioni di sql server
Ciao


 doppia.
Non mi riferivo alle pa, ma proprio alla partita doppia.
Sarà che non sono ragioniere ma non riesco a seguirne la logica.
Ciao
Davide 

 Davide


 server
Vabbe' questa cosa e' solo ai fini prestazionali e da quello che mi 
ricordo (non su SQLServer, al tempo non esisteva c'era solo il suo 
antenato Sybase) non e' che ti risolve la questione della codifica. Fa 
solo in modo che *a fronte* della codifica il sistema mette la 
registrazione nella partizione giusta. Cio' sempre che le partizioni 
SQLServer (che dovrebbero essere invenzione abbastanza recente) siano 
simili a quelle che ho usato.

 Sarà che non sono ragioniere ma non riesco a seguirne la logica.
Ma non e' un po come l'informatica? Entra una cosa, macinatina, esce 
qualcosa nella stessa quantita' di entrata?  ;-{)
Il problema e' che spesso i contabili non sanno quello che stanno 
facendo e quindi diventi scemo a capire cosa vogliono.
Diventa ancora piu' complicato se, sempre i medesimi contabili, hanno 
imparato a far casino con Excel.

 simili a quelle che ho usato.
Questo sono le partizioni che intendo 
http://msdn.microsoft.com/it-it/library/ms187802.aspx


 
http://msdn.microsoft.com/it-it/library/ms187802.aspx
Ohhhhh.....yessssss, a occhio mi sembrano la "misma" cosa.
Hot water? Forged long time ago.

 imparato a far casino con Excel.
era quello che pensavo anch'io, ma non volevo sembrare presuntuoso... ;-)
Davide (Sib) 

 L'è dura, ma la logica una volta acquisita è molto semplice.
Più che altro non mi riferivo alla mia logica, ma a quella del ragioniere 
che spesso, come dice alessandro, non ha idea di cosa sta facendo quando 
registra le cose, in realtà lo fa meccanicamente senza capire perchè e 
quindi non te lo sa spiegare cosa fa...
Davide (Sib)