Newsgroup: it.comp.lang.visual-basic
Titolo: Programma di Contabilità Generale

Sono interessato a discutere la proggettazione di questo tipo di
programma.
Se qualcuno è interessato mi farebbe piacere essere contattato.
Grazie
Giovanni

 >
  Premetto che le cose che dirò sono le cose che ritengo giuste, ma ti pregherei
di voler considerare che non sono saccente, ne di pensare che io sia un esaltato
o altro. Il linguaggio che uso può sembrarti categorico, ma sappi che tutti
sbagliano specialmente io. Sarei felice di sapere tutti i punti sui quali non
trovi il tuo parere concorde con il mio.
Le mie consoscenze in VB non mi permettono di analizzare la programmazione di un
programma funzionante in rete. Ritengo però che questa sia condizione
assolutamente necessaria.
La mia analisi parte ovviamente dal basso. La struttura dei dati, ritengo sia
alla base della piramide, se così possiamo immaginarla, della struttura di un
programma contabilità.
Un problema del quale mi piacerebbe discutere con te sarebbe quello della
struttura dei record anagrafici dei clienti o dei fornitori.
Dalla anagrafica di un cliente bisogna poter evicere ogni tipo di informazione.
Deve essere cioè un archivio contenete qualsiasi informazione su di esso. Ad
esempio se il cliente ha diverse destinazioni per la merce che acquista queste
si devono trovare tutte nella anagrafica dello stesso. Può sembrare una cosa
ovvia, ma ti assicuro che per molti programmi non lo è.
Ad esempio, se il cliente acquista scarpe, nella sua anagrafica trovremo anche
la marca che utilizza sulle etichette delle scatola, il suo spedizionere di
fiducia, dei giorni particolari nei quali non vuole la scadenza delle ricevute
bancarie emesse a suo debito, tutte le informazioni possibili ed immaginabili.
L'anagrafica del cliente/fornitore, deve dirci vita, morte e miracoli dello
stesso.
Un altro agromento importante è la struttura del record. Il cliente protrebbe
avere una destinazione di versa da quella della ragione sociale, o addirittura
ne potrebbe avere molte nel caso in cui sia un cliente con più punti vendita.
Dovrebbe quindi esistere una tabella nella quale fossero raccolti tutti i campi
utilizzabili nella anagrafica di un cliente/fornitore,  facoltativi o
obligatori.
I campi ultilizzabili dovrebbero poter essere ultilizzati più volte in una
stessa anagrafica.
Per questo oltre al codice del campo andrebbe il codice riga. Potrei avere cosi
il campo "Numero di tel." utilizzato più volte incrementando, ad ogni nuovo
numero di telefono, il numero di riga.
Queste sono le mie prime considerazioni.
Sarei felice di avere da parte tue dei commenti. Forse i mie raggionameni sono
troppo affrettati? Forse dovrei partire da altro punto?
Ti preghere di continuare la discussione sia inviando il tuo messaggio
direttamente a me sia al Newsgroup in modo tale da permettere a tutti quelli
interessati di intervenire in merito.
Grazie per l'attenzine
Giovanni

Anch'io, per motivi di lavoro, sarei interessato a progettare, e soprattutto
realizzare un buon programma di contabilità generale che sia facilmente
trasportabile in situazioni diverse.
Sarei quindi interessato a partecipare alla discussione.
In primis:
Per contabilità generale intendete anche collegamento a fatture, ordini,
magazzino e riscontro dei documenti  o una semplice partita doppia ?
State pensando a una tipologia di cliente particolare?

Ciao Giovanni.
Ti dirò innanzitutto che l'analisi della struttura dati è una delle attività
più complesse
dell'information technology in generale.
Primo perchè richiede una grossa capacità di astrazione
Secondo perchè richiede comunque una grossa esperienza
Terzo perchè richiede, oltre a delle conoscenze ben consolidate per
l'analisi e lo sviluppo del software,
delle competenze specifiche della materia che si intende trattare.
Quarto perchè mentre un programma anche se già utilizzato da qualcun altro
può essere riscritto da cima a fondo senza creare scompensi all'utente
finale questo non può essere fatto per la base dati poichè il mantenimento e
la struttura delle informazioni fino ad allora inserite spesso non lo
permettono se non con un notevole sforzo per cui....... nessun errore.
In generale , come ogni cosa, non esiste un metodo migliore di un altro,
esistono delle soluzioni più funzionali di altre per un determinato scopo.
Comunque nello specifico ad esempio
conviene studiare innanzitutto le informazioni che si devono trattare e
cercare di normalizzarle
facendo uso delle relazioni che intercorrono tra di loro:
Es:  Clienti Fornitori , Vettori , Destinazioni cosa sono ?
Sono dei nominativi, Hanno un nome , un Cognome o una ragione sociale , una
partita iva o un codice fiscale  Ha senso creare tre o più tabelle
differenti ? e se un Fornitore diventa anche Cliente , o Se un Vettore
diventa anche un CLiente o viceversa ? In effetti Una anagrafica è cosa ben
distinta da un cliente o da un fornitore.  Una Anagrafica è un'insieme di
dati informativi che vivono indipendentemente da me Azienda, quindi
converrebbe inserirli in un'unica tabella. Quando poi Una di queste
anagrafiche intrattiene un rapporto commerciale creerò questa relazione Tra
Me e L'anagrafica in una tabella separta , questa relazione potrà essere
chiamata Cliente. Il cliente conterrà informazioni aggiuntive che hanno un
senso in funzione di un rapporto tra me Azienda e lei Anagrafica  come ad
esempio La condizione di pagamento , la modalità di fatturazione etc. Quindi
converrebbe non inserire tutti i dati in un unica tabella Clienti e ogni
Cliente avrà un riferimento alla tabella anagrafica.
Lo stesso ragionamento potrà essere applicato anche ai Vettori , ai
Fornitori e Alle Destinazioni e a tutte quelle informazioni che fanno parte
del mio sistema.
La relazione precedente è una relazione di tipo Uno-a-molti,
Nel caso delle Destinazioni invece il tipo di relazione è molti-a-molti
perchè una destinazione potrebbe essere valida per più di un cliente e più
destinazioni potrabbero riferirsi ad un unico cliente . In questo caso
potrebbe risultare utile utilizzare una tabella di Link tra clienti e
Destinazioni  con cui registrare le associazioni logiche tra Clienti e
Destinazioni e via dicendo.
In generale la cosa più conveniente è quella di considerare le informazioni
secondo i seguenti criteri:
La mia informazione è autonoma ?
Ha delle Relazioni con altre informazioni ?
Ha una relazione di tipo uno-a-molti , uno-a-uno , molti-a-molti ?
Come posso descrivere queste relazioni in modo nel modo più flessbile ?
Trovare il "netto" di una informazione può essere un' operazione non
semplice anche perhè spesso risulta confuso il confine tra una informazione
e l'altra , specie se la materia che si tratta la si conosce
superficialmente.Non basta infatti parlare con un utente, si deve cercare di
interpretare ciò che viene detto e confrontarlo con gli schemi mentali già
acquisiti e precedentemente verificati sul lavoro.
Ciò che hai detto direi che ha sicuramente una corretta impostazione, il
modo con cui desideri implementare il tutto è un altro paio di maniche.
Cerca innanzitutto di astrarti e tatta le informazioni
in modo asettico , senza pensare a come vorresti che l'applicazione gestisca
le informazioni.
Cerca le relazioni tra di esse.
E poi alla fine pensa al modo di tradurre sotto forma di procedura la
dinamica di queste relazioni.
Scendere nello specifico è praticamente imposibile senza intassare qualsiasi
news.
Se sei interessato ad approfondire la materia per ciò che riguarda la
normalizzazione e la struttura dei dati ti consiglio un ottimo libro che è
in grado di darti una solida infarinatura.
Oggeti e Visual Basic 5.0 - Aut. Deborah Kurata - Ed. Ziff Davis.
                            Ciao Antonello

Sono interessato a partecipare e contribuire.
~~~~~~~~~~~~~~~~~
Adriano Ghezzi
Avion Sistemi Srl
mailto:
agh...@isp.it
http://www.isp.it


...


Prima di parlare di magazzino e produzione, bisogna creare il programma di
contabilità, sempre tenendo conto dei paramentri che serviranno nella
fatturazione e programmazione. La fatturazione può essere anche non collegata
alla produzione. E' importante creare degli archivi, con tipi di record non
fissi. Ci devono essere delle tabelle di riferimento che indicano i vari campi
utilizzabili, poi  dei record (anagrafica clienti/fornitori, tabella causali
cotabili) che contengono quelli scelti.
Questo ci permette di aggiungere campi nuovi man mano che se ne presenta
l'esigenza.
Il problema è come realizzare questa cosa in VB.
Ora putrobbo devo abbandonarvi, a + tardi.
Saluti Giovanni


...
