Duplicare Ragione Sociale

di il
28 risposte

28 Risposte - Pagina 2

  • Re: Duplicare Ragione Sociale

    ettore56 ha scritto:


    Quali sarebbero le scelte discutibili?
    Hai capito quello che ho detto...?
  • Re: Duplicare Ragione Sociale

    @Alex ha scritto:


    ettore56 ha scritto:


    Quali sarebbero le scelte discutibili?
    Hai capito quello che ho detto...?
    Certo che ho capito!
    Tu stai mettendo in discussione che la scelta migliore per realizzare un gestionale che si occupi di contabilità, sia quella di avere tabelle separate per le anagrafiche dei clienti, dei fornitori e dei vettori.
    Non so se tu ti occupi anche di scritture contabili, e se hai dimestichezza con la compilazione di una prima nota ordinaria, gestione dei registri IVA, gestione del librio giornale, gestione del libro inventari, comunicazione periodiche IVA, comunicazione dati fattire (DTE e DTR), liquidazioni periodiche IVA, etc., etc.
    Bene, ti posso garantire che QUASI (dico quasi perchè non c'è mai nulla di certo) nessuna software house penserebbe mai di realizzare un gestionale, che gestisca anche solo alcune delle problematiche che ti ho elencato, non utilizzando tabelle separate per le diverse categorie di nominativi.
    La tua soluzuione potrebbe andare bene per la gestione di un piccolo applicativo per la sola gestione della fatturazione, ma, a mio avviso e secondo l'esperienza da me accumulata in diversi anni di gestione contabile, diventerebbe improponibile per un programma di contabilità, fosse anche solo in forma semplificata e non in ordinaria.
    Non prendere questa mia risposta come una presa di posizione nei tuoi confronti, ma semplicemente ho voluto puntualizzare che, oltre ad avere capito benissimo la tua obiezione, non sono assolutamente d'accordo con te.
    Poi ognuno, soprattutto in informatica, è libero d'intraprendere la strada che reputa per se la migliore e la più semplice. L'importante è cogliere il risultato.
  • Re: Duplicare Ragione Sociale

    @Alex ha scritto:


    Magari non è che la tabella Anagrafica possa essere Una sola, e poi pensare ad una Relazione in 3 FN in cui ogni Anagrafica possa avere N ruoli...?
    A me sembra che @Alex abbia risposto al "dilemma". Lui (e anch'io) siamo abituati a ragionare secondo le regole di normalizzazione. Una di queste (@Alex potrebbe dire meglio qual è) dice che non devono esistere 2 tabelle con gli stessi campi.
    Per quanto mi riguarda (parlo per me stesso) sono scettico sulla progettazione di software "belli e pronti"...sai a quante esigenze personalizzate non possono rispondere?
    Bla...bla...bla...mi sa che rischiamo di andare fuori tema e GiuliaB chissà che idea si sta facendo di Access, questo forum, del destino del suo progetto ecc...
    Io propongo di fermarci tutti e lasciare meditare GiuliaB su quello che "a piccoli passi" vorrà fare partendo dal foglio Excel da cui era partita. Non vi pare?
  • Re: Duplicare Ragione Sociale

    Sono contento tu abbia compreso.
    E' evidente che Teoria e Pratica possono avere divergenze applicative, o meglio per vantaggi pratici si deforma la teoria..., ma la Teoria insegna e serve maneggiarla bene prima di arrivare a capire come personalizzarla, e ribadisco che l'aspetto Teorico che ho suggerito è implicito in qualsiasi analisi strutturata di un sistema che risponde ai requisiti di Multifunzionalità di classe.
    Poi ognuno come hai giustamente indicato... è libero... anche di Denormalizzare... o usare Database non relazionali... sono sempre scelte per le quali ci sono motivi che giustificano il singolo e che troveranno contrarietà in altri...
  • Re: Duplicare Ragione Sociale

    Mi scuso se rispondo un po' in ritardo, ma la pausa pranzo era indispensabile...!

    OsvaldoLaviosa ha scritto:


    ...Io propongo di fermarci tutti e lasciare meditare GiuliaB su quello che "a piccoli passi" vorrà fare partendo dal foglio Excel da cui era partita. Non vi pare?
    Assolutamente sì! Mi dispiacerebbe perdere così precocemente una nuova "amica" come GiuliaB!

    OsvaldoLaviosa ha scritto:


    ...A me sembra che @Alex abbia risposto al "dilemma". Lui (e anch'io) siamo abituati a ragionare secondo le regole di normalizzazione. Una di queste (@Alex potrebbe dire meglio qual è) dice che non devono esistere 2 tabelle con gli stessi campi.
    Problema bypassabile mediante la rinomina dei campi delle tabelle per esempio con "DenominazioneC" e "DenominazioneF" e "DenominazioneV" etc., assolutamente indispensabile qualora si pensasse di volere emettere fatture elettroniche, dove sono richiesti, in parte obbligatori ed in parte facoltativi, centinaia di campi per ogni categoria di nominativi.

    @Alex ha scritto:


    S.... E' evidente che Teoria e Pratica possono avere divergenze applicative, o meglio per vantaggi pratici si deforma la teoria..., ma la Teoria insegna e serve maneggiarla bene prima di arrivare a capire come personalizzarla
    Ed è qui che subentra il famoso detto che "la necessità aguzza l'ingegno". Ovvio che occorre avere le basi giuste per farlo!
    Ciao a tutti e aspettiamo, a questo punto, anche un commento di GiuliaB.
  • Re: Duplicare Ragione Sociale

    ettore56 ha scritto:


    Bene, ti posso garantire che QUASI (dico quasi perchè non c'è mai nulla di certo) nessuna software house penserebbe mai di realizzare un gestionale, che gestisca anche solo alcune delle problematiche che ti ho elencato, non utilizzando tabelle separate per le diverse categorie di nominativi.
    Ecco, secondo me la parola magica è
    QUASI
    [/b].

    Di gestionali contabili ne conosco molti, ci ho lavorato con altrettanti (molti) e non mi è mai capitato (dico MAI) di avere le anagrafiche separate, ma di avere dei flag di distinzione tra clienti, fornitori, vettori, ecc. e poi ulteriori tabelle ad essi riferiti con le rispettive informazioni.
  • Re: Duplicare Ragione Sociale

    gibra ha scritto:


    Di gestionali contabili ne conosco molti, ci ho lavorato con altrettanti (molti) e non mi è mai capitato (dico MAI) di avere le anagrafiche separate, ma di avere dei flag di distinzione tra clienti, fornitori, vettori, ecc. e poi ulteriori tabelle ad essi riferiti con le rispettive informazioni.
    Ma non ti sembra di essere un po' in contraddizione?

    gibra ha scritto:


    Non si duplica mai una ragione sociale, possono esservi delle ragioni sociali omonime ma hanno la Partita IVA e/o il Codice Fiscale differenti.
    Quindi stai procedendo nel modo sbagliato.

    gibra ha scritto:


    Osvaldo, gli stai facendo fare una cosa sbagliata!
    Non si duplica la Ragione Sociale. MAI!!!
    E' un errore madornale.

    Nel caso un Cliente/Fornitore fosse anche un Vettore che fai, lo triplichi? ...
    Per forza lo triplichi!!!
    Se la società "Pinco Pallino", che si occupa, tra i vari oggetti sociali, anche di trasporti, viene da te utilizzata come vettore e, contestualmente, alla stessa ditta tu gli vendi le risme di carta per le fotocopiatrici e, inoltre, dalla stessa ditta un giorno decidi di acquistare un loro veicolo usato, oppure delle scrivanie usate o qualsiasi altra cosa (sto solamente facendo degli esempi che comunque possono accadere), avrai la necessità di censirla sia come Vettore, sia come Cliente, sia come Fornitore?
    C'è forse qualche norma che ti impedisce di farlo?
    Oppure tu come la gestiresti?
    Quando ricevi da un tuo fornitore una fattura in regime di reverse charge, come la registri in contabilità?
    Non devi forse emettere un documento fiscale utilizzando lo stesso nominativo del fornitore come cliente, per potere esporre l'IVA ed evidenziare che si tratta di un'operazione in reverse charge?
    Quando si realizza un programma gestionale di contabilità bisogna avere una discreta infarinatura sulla materia e, inoltre, prevedere quasi anche l'impossibile!
    Detto ciò, io non ho escluso la possibilità di utilizzare dei flag all'interno di un'unica tabella per differenziare il cliente dal fornitore e dal vettore, ma ti assicuro che alla fine risulterebbe essere un GRANDISSIMO PASTROCCHIO, privo di qualsiasi logica e per di più poco utilizzabile!
    In questo caso occorre tralasciare il puro discorso didattico di programmazione che prevede che un database debba essere necessariamente "Normalizzato" in una certa maniera, ma bisogna capire come potere poi estrapolare, dalle registrazioni effettuate, le informazioni, i modelli di dichiarazione e quant'altro richiesto dall'AdE, che sicuramente non è una software house e che se ne frega se tu per soddisfare le sue esigenze ti devi inventare procedure impossibili.
    Ti rammento che GiuliaB ha chiaramente esposto questo problema:

    GiuliaB ha scritto:


    ...Può accadere che un Cliente sia anche Fornitore, in un primo momento ho pensato di aggiungere una voce alla Categoria chiamandola Cliente-Fornitore, ma in una logica più ampia di gestionale mi incasino sulle query che mi servono poi per le varie attività: prima nota, iva etc....
    HA PERFETTAMENTE RAGIONE!
    Sulle query che le servono s'incasinerà per forza se non avrà divise e distinte le tabelle dei clienti, fornitori, piano dei conti, causali contabili, codici iva, etc.
  • Re: Duplicare Ragione Sociale

    ettore56 ha scritto:


    Ma non ti sembra di essere un po' in contraddizione?
    Ma non sai leggere?
  • Re: Duplicare Ragione Sociale

    Buongiorno ragazzi! Siete fantastici, adoro la vostra passione!
    Scusate se mi dilungherò in questo post, ma devo fare una piccola premessa.
    Sono una semplice impiegata appassionata di gestionali, nella mia esperienza lavorativa ho seguito l’introduzione (lato user) di Sap e Teamsystem, ma non ho nessuna conoscenza di programmazione, tanto meno in VBA.
    Ho “studiato” su un libro per Access 2007 basato su un esempio di Northwind, ma era insufficiente per le mie esigenze, mi sono stati molto utili i videotutorial di Lana, Cordelli, Cucchiara, Fortunato ed ho letto un po’ di forum compreso il vostro.
    Preciso che ho un dabatase in Access che viene usato come un Excel, insomma è come avere una Ferrari ed usarla come una 500!! Quindi sto cercando di creare un gestionale nuovo che abbia un valore aggiunto, ho realizzato una mappa concettuale per avere le idee chiare sui processi lavorativi, ma realizzarlo è tutta un’altra cosa!!

    Osvaldo, proponi di tenere le cose separate, secondo te dovrei fare una tabella con ID_Anagrafica, una con ID_Categoria, poi creare una tabella di collegamento che mi metta in relazione i due ID_, a quel punto dovrei usare l’ID di collegamento tra i due come ID_Anagrafica principale, dopo funzionerà tutto in Maschere/Query/Report?

    Ettore, se ripenso ai programmi di contabilità come AS400 e gli altri due sopra citati, apparentemente le anagrafiche sono separate, es. Fornitori a partire dal codice 400.xxx e Clienti dal 300.xxx, come questo si tramuti in programmazione non lo so. Anch’io avevo pensato a due anagrafiche separate, i vettori potrei gestirli come Fornitori anche se non generano movimenti contabili, a queste due però devo aggiungere un’anagrafica dipendenti, questo implica avere 3 maschere di inserimento ed una query con campi duplicati nella maschera di consultazione dell’anagrafica, oppure altre due maschere di consultazione, idem come sopra, funzionerà tutto?

    Sicuramente avete tutti ragione, ma io ho bisogno di chiudere il cerchio con il minimo sforzo ed il massimo risultato, stiamo parlando di 100 fornitori, 30 clienti e 5 vettori, avrei voluto semplificarmi la vita e partire già dall’anagrafica con le idee chiare, se non è possibile ci metterò un po’ di mesi, ma a forza di provare ci riuscirò! Scusate, ma non cosa sia la “normalizzazione”.
    Spero di essere stata chiara, grazie a tutti!
  • Re: Duplicare Ragione Sociale

    GiuliaB ha scritto:


    Scusate, ma non cosa sia la “normalizzazione”.
    Allora quel libro per Access 2007 valeva veramente poco, detto da uno che ha saltato la pagina delle "relazioni tra tabelle", nel senso che proprio s'è sfuggita, e ha scoperto cosa sono dopo 5 anni.

    GiuliaB ha scritto:


    se ripenso ai programmi di contabilità come AS400
    AS400 non è un programma... quanti ricordi! Quindi dipende da come è fatto il programma che gira su AS400, non tanto dall'AS400.

    GiuliaB ha scritto:


    non ho nessuna conoscenza di programmazione, tanto meno in VBA.
    Per ora non è così fondamentale, lo diventerà presto quando vorrai fare il salto di qualità.

    Dico la mia anche se il gestionale che uso (è un prodotto commerciale, non l'ho fatto io) è un po' "di nicchia" quindi non è rappresentativo della situazione classica, però illustra come viene applicato quanto spiegato da Gibra.
    C'è una sola tabella delle anagrafiche, una! Contiene i dati minimi essenziali, strettamente "anagrafici" (scusa il gioco di parole): cognome o denominazione, nome, codice fiscale, partita iva, data e luogo di nascita, tipo del soggetto (persona fisica o giuridica). Stop qui, più o meno (altri campi "di servizio" ma non contano), niente di specifico.
    Poi ci sono varie tabelle in relazione uno ad uno, per le caratteristiche specifiche di ogni soggetto a seconda del "ruolo" che riveste. Clienti e fornitori, in questa tabella dedicata alla parte contabile, sono in un'unica tabella ed in questa vengono inserite le informazioni specifiche per la loro veste di cliente/fornitore.
    Chiamando la prima tabella tblSogg, ad esempio, per definire un soggetto come cliente/fornitore viene caricata la sua pk nella tabella tblForn (il fatto che ci sia la desinenza -Forn non significa che è solo per i fornitori ma si tengono i nomi delle tabelle corti, per la portabilità sui vari RDBMS) e qui si inseriscono le informazioni prettamente contabili. Potrebbe esserci una tabella tblVettori, inserisci la pk del soggetto in quella tabella e popoli i campi specifici dello status di vettore.
    Un po' di query "base" per avere in un'unica sorgente di dati le informazioni complete di ogni soggetto, del tipo
    qryForn che mette in relazione tblSogg e tblForn, con i campi dell'una e dell'altra
    qryVett che mette in relazione tblSogg e tblVett e via dicendo.
    Facile? no!
    Corretto? direi di sì. E noi di soggetti ne abbiamo tanti, veramente tanti, di tanti tipi.
    Aggiungici poi che questo permette anche di facilitare la limitazione di accesso alle informazioni: chi non deve sapere/vedere i dati di un vettore non ha accesso alla tabella tblVett ma continua ad accedere a tblSogg.
  • Re: Duplicare Ragione Sociale

    GiuliaB ha scritto:


    Osvaldo, proponi di tenere le cose separate, secondo te dovrei fare una tabella con ID_Anagrafica, una con ID_Categoria, poi creare una tabella di collegamento che mi metta in relazione i due ID_, a quel punto dovrei usare l’ID di collegamento tra i due come ID_Anagrafica principale, dopo funzionerà tutto in Maschere/Query/Report?

    GiuliaB ha scritto:


    stiamo parlando di 100 fornitori, 30 clienti e 5 vettori
    1. Stiamo parlando con una principiante
    2. Fino ad ora abbiamo parlato soltanto di Anagrafica

    Io sentenzio la mia proposta (che fa i conti con il punto 2. precedente) di:
    1. Cancellare il campo Categoria da Anagrafica
    2. Metti 3 campi Fornitore, Cliente, Vettore di tipo Sì/No
  • Re: Duplicare Ragione Sociale

    Grazie molte Phil, scusa per la definizione di programma di AS400, noi lo chiamavamo così
    La tua proposta è sicuramente interessante e formalmente corretta, ma in effetti è un po' complicata, tenendo conto che non so quante altre tabelle dovrò creare se ne faccio già tante per l'anagrafica non so dove andrò a finire.

    Osvaldo, ho già messo un campo si/no per definire se quella ragione sociale è attiva o meno, ma come faccio poi a dare il criterio nelle query?
    Basta sì/no, oppure bisogna usare dei codici 0-1 1-2, mi sembra di ricordare di avere provato diverse soluzioni, ma non funzionavano. Grazie!
  • Re: Duplicare Ragione Sociale

    GiuliaB ha scritto:


    Grazie molte Phil, scusa per la definizione di programma di AS400, noi lo chiamavamo così
    Non chiedere scusa, non ce n'è bisogno. Il mio è stato un segno di rispetto per l'AS400 che mi ha accompagnato per anni... il primo DB2 non si scorda mai.

    GiuliaB ha scritto:


    La tua proposta è sicuramente interessante e formalmente corretta, ma in effetti è un po' complicata, tenendo conto che non so quante altre tabelle dovrò creare se ne faccio già tante per l'anagrafica non so dove andrò a finire.
    Beh... non accantonarla solo per il fatto del numero delle tabelle, non è certo lì il problema. Che sia complicata non lo dubito. Ripeto che è in un gestionale commerciale, io "non li so fare" tanto per dire.
  • Re: Duplicare Ragione Sociale

    GiuliaB ha scritto:


    Osvaldo, ho già messo un campo si/no per definire se quella ragione sociale è attiva o meno, ma come faccio poi a dare il criterio nelle query? Basta sì/no, oppure bisogna usare dei codici 0-1 1-2, mi sembra di ricordare di avere provato diverse soluzioni, ma non funzionavano. Grazie!
    Per i campi di tipo Sì/No le sintassi criterio valide sono:
    Vero/Falso
    -1/0
Devi accedere o registrarti per scrivere nel forum
28 risposte