Gestione Documenti

di il
51 risposte

51 Risposte - Pagina 3

  • Re: Gestione Documenti

    Emadragon ha scritto:


    Un Documento (contratto) può essere collegato a Tanti Documenti (ricevute che fanno riferimento al Documento Contratto)

    Non capisco il modo per creare una relazione del genere....

    se ho un contratto che mi dice
    Scadenza Uno 100 €
    Scadenza Due 200 €
    Scadenza Tre 150 €

    Il giorno del ricevimento del pagamento devo emettere altri Documenti (ricevute) relative a quelle scadenze...
    Quindi avrò delle ricevute (che devono avere un numero univoco esattamente come le fatture)
    Io mi rifaccio a questa che mi appare la più chiara di tutte. Se non ti piace l'IDDocumento perché si tratta di un numero progressivo fornito da Access, nessuno ti vieta di avere un altro tipo di "numero" (purchè univoco) che sia più legato alla TUA logica/consuetudine. Tale numero sarà digitato da te manualmente e sarà la chiave primaria per la tabella Documenti. Idem "chiave esterna" per Ricevute (o Pagamenti????? come la stai chiamando quest'ultima tabella???).
  • Re: Gestione Documenti

    OsvaldoLaviosa ha scritto:


    Emadragon ha scritto:


    Un Documento (contratto) può essere collegato a Tanti Documenti (ricevute che fanno riferimento al Documento Contratto)

    Non capisco il modo per creare una relazione del genere....

    se ho un contratto che mi dice
    Scadenza Uno 100 €
    Scadenza Due 200 €
    Scadenza Tre 150 €

    Il giorno del ricevimento del pagamento devo emettere altri Documenti (ricevute) relative a quelle scadenze...
    Quindi avrò delle ricevute (che devono avere un numero univoco esattamente come le fatture)
    Io mi rifaccio a questa che mi appare la più chiara di tutte. Se non ti piace l'IDDocumento perché si tratta di un numero progressivo fornito da Access, nessuno ti vieta di avere un altro tipo di "numero" (purchè univoco) che sia più legato alla TUA logica/consuetudine. Tale numero sarà digitato da te manualmente e sarà la chiave primaria per la tabella Documenti. Idem "chiave esterna" per Ricevute (o Pagamenti????? come la stai chiamando quest'ultima tabella???).
    ok...

    resta il fatto che Contratto e Ricevuta restano scollegati tra loro...
    non centra niente l'idDocumento... (forse nn ci capiamo....)

    Devo poter pagare Creando un nuovo documento un contratto che anche esso è un documento...
  • Re: Gestione Documenti

    Ammetto di essere il più duro di comprendonio di tutto il forum. Reset. Proviamo a parlare come sono abituato io?
    1. Nella tabella Persone tu hai:
    Antonio
    Giuseppe
    Paolo
    Filippo

    2. Antonio produce un Contratto il 5/1/2018. Che Contratto è per cui poi ci sono altre Ricevute?
    3. Giuseppe produce 3 Contratti nei giorni 7/1/2018, 10/2/2018, 24/6/2018. Ai primi 2 seguono rispettivamente 4 e 7 Ricevute. Al terzo solo 1 Ricevuta.
    4. Filippo produce 2 Contratti nei giorni 3/3/2018, 22/10/2018. Al primo fanno seguito 2 Ricevute, al secondo nemmeno una.

    Questa analisi che ho fatto è realistica? Cosa altro non torna?

    Emadragon ha scritto:


    Devo poter pagare Creando un nuovo documento un contratto che anche esso è un documento...
    Ho capito che un Contratto è un Documento. Una Ricevuta è un Documento pure.
    Io ho capito che da Un DocumentoContratto seguono Molti DocumentiRicevute. Le due cose che ti "appaiono" slegate, sono in realtà legate dal IDDocumento.
    Non conosco il tuo campo professionale (sarebbe bene che tu espliciti anche questo aspetto, così chiariremmo qualche campo in più da mettere in questa o quella tabella).
    Se non vuoi "slegare" (che poi significa "relazionare")...mi dici quale alternativa avresti?
    Se Documenti e Ricevute ti sembrano OMOGENEI...a sto punto mettili tutti nella stessa tabella Documenti, poi ci aggiungi un campo che chiamerai Riferimento che li accomuna tutti.
  • Re: Gestione Documenti

    OsvaldoLaviosa ha scritto:


    Ammetto di essere il più duro di comprendonio di tutto il forum. Reset. Proviamo a parlare come sono abituato io?
    1. Nella tabella Persone tu hai:
    Antonio
    Giuseppe
    Paolo
    Filippo

    2. Antonio produce un Contratto il 5/1/2018. Che Contratto è per cui poi ci sono altre Ricevute?
    3. Giuseppe produce 3 Contratti nei giorni 7/1/2018, 10/2/2018, 24/6/2018. Ai primi 2 seguono rispettivamente 4 e 7 Ricevute. Al terzo solo 1 Ricevuta.
    4. Filippo produce 2 Contratti nei giorni 3/3/2018, 22/10/2018. Al primo fanno seguito 2 Ricevute, al secondo nemmeno una.

    Questa analisi che ho fatto è realistica? Cosa altro non torna?
    Perfettamente
    Ma il contratto creerà delle scadenze...
    e le ricevute saranno il pagamento di determinate scadenze...
    oppure possono essere a se stanti... senza un contratto dietro...

    OsvaldoLaviosa ha scritto:


    Emadragon ha scritto:


    Devo poter pagare Creando un nuovo documento un contratto che anche esso è un documento...
    Ho capito che un Contratto è un Documento. Una Ricevuta è un Documento pure.
    Io ho capito che da Un DocumentoContratto seguono Molti DocumentiRicevute. Le due cose che ti "appaiono" slegate, sono in realtà legate dal IDDocumento.

    OsvaldoLaviosa ha scritto:



    Non conosco il tuo campo professionale (sarebbe bene che tu espliciti anche questo aspetto, così chiariremmo qualche campo in più da mettere in questa o quella tabella).
    Sto cercando di creare un db per la mia asd ma che sia flessibile...

    OsvaldoLaviosa ha scritto:


    Se non vuoi "slegare" (che poi significa "relazionare")...mi dici quale alternativa avresti?
    Se Documenti e Ricevute ti sembrano OMOGENEI...a sto punto mettili tutti nella stessa tabella Documenti, poi ci aggiungi un campo che chiamerai Riferimento che li accomuna tutti.
    appunto vi è un modo per creare una relazione tra questo campo e la tabella in questione ????
    possibilmente trovando il modo di abbinare le scadenze alle relative ricevute????
    ma che saranno Scadenze di contratto ma risolte dal pagamento della relativa ricevuta
  • Re: Gestione Documenti

    Emadragon ha scritto:


    Perfettamente
    Ma il contratto creerà delle scadenze...
    e le ricevute saranno il pagamento di determinate scadenze...
    oppure possono essere a se stanti... senza un contratto dietro...
    La discussione si è talmente allungata che ho perso la lista dei campi di ogni tabella.
    Documenti deve avere un campo TipoDocumento (Contratto, Ricevuta).
    Hai detto che ci sono Documenti=Ricevuta che nascono e muoiono in un solo colpo. OK, in tabella Documenti tu la traccerai come TipoDocumento=Ricevuta. In Pagamenti ci scrivi la medesima cosa con un record solo.
    Resta fermo il concetto che IDDocumento (oppure NumeroDocumento) sarà il tuo Riferimento per accomunare Documento con tutti i suoi Pagamenti.

    P.S.: A me però non convince una cosa. Dietro un Contratto, ma anche dietro una Ricevuta, c'è sempre una STORIA che deve essere raccontata. Questa "storia" va descritta in Documenti. Quando dico "storia" intendo una serie di campi più espliciti. Occorre abbondare un po' anche con i campi. Pagamenti deve tracciare solo il suo "sviluppo" successivo.

    Riepilogo tutto in maniera chiara.
    Persone
    IDPersona (PK)
    Cognome
    Nome
    ...altri campi tipicamente anagrafici…

    Documenti
    IDDocumento (PK)
    DataDocumento
    TipoDocumento
    Descrizione
    IDPersona (FK)

    Pagamenti
    IDPagamento (PK)
    DataPagamento
    Causale
    Importo
    IDDocumento (FK)

    Ovvie relazioni a seguire.
  • Re: Gestione Documenti

    OsvaldoLaviosa ha scritto:


    Emadragon ha scritto:


    Perfettamente
    Ma il contratto creerà delle scadenze...
    e le ricevute saranno il pagamento di determinate scadenze...
    oppure possono essere a se stanti... senza un contratto dietro...
    La discussione si è talmente allungata che ho perso la lista dei campi di ogni tabella.

    OsvaldoLaviosa ha scritto:


    Documenti deve avere un campo TipoDocumento (Contratto, Ricevuta).
    Si era previsto

    OsvaldoLaviosa ha scritto:


    Hai detto che ci sono Documenti=Ricevuta che nascono e muoiono in un solo colpo. OK, in tabella Documenti tu la traccerai come TipoDocumento=Ricevuta. In Pagamenti ci scrivi la medesima cosa con un record solo.
    Esatto

    OsvaldoLaviosa ha scritto:


    Resta fermo il concetto che IDDocumento (oppure NumeroDocumento) sarà il tuo Riferimento per accomunare Documento con tutti i suoi Pagamenti..
    Fermissimo

    OsvaldoLaviosa ha scritto:


    P.S.: A me però non convince una cosa. Dietro un Contratto, ma anche dietro una Ricevuta, c'è sempre una STORIA che deve essere raccontata. Questa "storia" va descritta in Documenti. Quando dico "storia" intendo una serie di campi più espliciti. Occorre abbondare un po' anche con i campi. Pagamenti deve tracciare solo il suo "sviluppo" successivo.
    Si... ma quando io pago una scadenza... Devo correlarla col relativo Documento di Pagamento....

    OsvaldoLaviosa ha scritto:


    Riepilogo tutto in maniera chiara.
    Persone
    IDPersona (PK)
    Cognome
    Nome
    ...altri campi tipicamente anagrafici…

    Documenti
    IDDocumento (PK)
    DataDocumento
    TipoDocumento
    Descrizione
    IDPersona (FK)

    Pagamenti
    IDPagamento (PK)
    DataPagamento
    Causale
    Importo
    IDDocumento (FK)

    Ovvie relazioni a seguire.
    A sto punto sarebbe ideale cmq avere una tabella Scadenze
    Scadenze
    IDScadenza (PK)
    DataScadenza
    Causale
    Importo
    IDDocumento (FK)

    Collegata al Contratto...

    Ora Contratto => più Scadenze
    Ricevuta => 1 Pagamento
    Oppure
    Ricevuta => 1Pagamento di 1ScadenzaDiContratto...

    Ma ho anche il fatto...
    Fattura => Scadenze => Pagamenti...


    Creare una tabella...
    PagamentoScadenza

    IDScadenzaPagamento(PK)
    IDContratto(FK)
    IDRicevuta(FK)

    è o meno una soluzione sensata/Funzionale???
    o vi è di meglio per questa soluzione????
  • Re: Gestione Documenti

    Secondo me devi scindere ciò che è "previsionale" da ciò che è la realtà. Quasi mai una Persona viene a pagarti nel giorno di Scadenza. Accade anche che non tutti rispettano le Scadenze. Accade che qualcuno non ti paga più proprio. In base a questa analisi io ci vedo 2 possibili soluzioni:
    A) Una tabella a parte Scadenze come l'hai indicata tu. Quindi Documenti uno-a-molti Scadenze
    B) In tabella Pagamenti aggiungi un campo DataScadenza.
    Ma la soluzione B) non mi convince per il fatto che qualcuno può versare Acconti, pagare in altro modo...e direi che questo viene esplicitato dal campo Pagamenti.Causale.

    Per la soluzione A), l'uso di una tabella Scadenze può tornare utile se vorrai implementare query e codice VBA che ti allerti quando qualcuno è fuori dalle previsioni...ma questo è un discorso a parte, fuori da "Progettazione database".
  • Re: Gestione Documenti

    OsvaldoLaviosa ha scritto:


    Secondo me devi scindere ciò che è "previsionale" da ciò che è la realtà. Quasi mai una Persona viene a pagarti nel giorno di Scadenza. Accade anche che non tutti rispettano le Scadenze. Accade che qualcuno non ti paga più proprio. In base a questa analisi io ci vedo 2 possibili soluzioni:
    A) Una tabella a parte Scadenze come l'hai indicata tu. Quindi Documenti uno-a-molti Scadenze
    B) In tabella Pagamenti aggiungi un campo DataScadenza.
    Ma la soluzione B) non mi convince per il fatto che qualcuno può versare Acconti, pagare in altro modo...e direi che questo viene esplicitato dal campo Pagamenti.Causale.

    Per la soluzione A), l'uso di una tabella Scadenze può tornare utile se vorrai implementare query e codice VBA che ti allerti quando qualcuno è fuori dalle previsioni...ma questo è un discorso a parte, fuori da "Progettazione database".
    Hai abbastanza colpito nel segno....

    anche a me interessa l'opzione A ma non riesco a trovare una opzione che mi permetta di concepire le casistiche da te elencate...

    a rigor logico

    Documento => Scadenza
    Documento => Pagamenti

    potrei in caso usare una terza tabella così gestita....

    IDPagamentiScadenza
    ID(PK)
    IDScadenza(FK)
    IDPagamento(FK)

    che mi permette di ottenere una relazione molti molti tra una e l'altra....

  • Re: Gestione Documenti

    Ad ora ho risolto così
    ScadenzePagate
    ID
    IDScadenza
    IDPagamento

    Pagamenti
    PK
    Data
    Importo
    IDDocumento
    (altri dati relativi al pagamento)
    Scadenze
    PK
    Data
    Importo
    IDDocumento


    Documento
    ID
    (altri dati relativi al pagamento)
    HA tante Scadenze
    Ha tanti Pagamenti...

    Se creo un documento ttt ok

    se pago una scadenza ttt ok
    compilo la tabella
    Scadenzepagate...

    volendo posso fare in modo di pagare + di una scadenza con un pagamento o altro...

    non ho trovato ad ora una soluzione + sensata...
  • Re: Gestione Documenti

    Io ti consiglio di non fossilizzarti troppo sulle Scadenze. Nella tabella Documenti potresti mettere un campo di tipo Sì/No per indicare che il Documento ha esaurito il suo ciclo (ossia è stato interamente pagato). Anche un volgare campo Note (testo lungo, in tabella Documenti) dove scrivi come sta andando l'andamento Pagamenti può tornare utile. Se domani riesci a cogliere un senso di continuità/ripetitività sistematica in quello che ti succede, prova a implementare altri campi. Per esperienza ti dico che molte cose le impari strada facendo, inserendo i dati.
  • Re: Gestione Documenti

    OsvaldoLaviosa ha scritto:


    Io ti consiglio di non fossilizzarti troppo sulle Scadenze. Nella tabella Documenti potresti mettere un campo di tipo Sì/No per indicare che il Documento ha esaurito il suo ciclo (ossia è stato interamente pagato). Anche un volgare campo Note (testo lungo, in tabella Documenti) dove scrivi come sta andando l'andamento Pagamenti può tornare utile. Se domani riesci a cogliere un senso di continuità/ripetitività sistematica in quello che ti succede, prova a implementare altri campi. Per esperienza ti dico che molte cose le impari strada facendo, inserendo i dati.
    Si e ti ringrazio molto dei preziosi consigli...
    solo che a mia idea... sarebbe meglio evitare i campi "vuoti" nei DB...
    ma non so quale possa essere il compromesso Spazio occupato <=> Prestazioni...

    hai qualche lettura/consiglio in più da darmi???
  • Re: Gestione Documenti

    È del tutto normale avere campi con valori Null (vuoti). Non devi minimamente preoccuparti delle prestazioni di Access.
  • Re: Gestione Documenti

    Domanda ....
    allora...
    è meglio avere tabelle con correlazioni 0-1
    oppure integrarle nella tabella originale correndo il rischio di avere campi vuoti???

    Es...
    tabella persone(fisiche o anche giuridiche creata per avere sia clienti che fornitori nella stessa tabella)...
    correlazizone 0-1 => DataNascita
    in modo tale che se è una persona fisica gli abbino i dati nella tabella data di nascita se no niente...

    ha senso???

    mi sto preoccupando inutilmente???
    (questo è solo un piccolo esempio...)

    parlando con varia gente in passato ho trovato per esempio chi mi sconsigliava altamente di mettere clienti e fornitori nella stessa tabella
    e chi mi diceva esattamente l'opposto????

    esiste una linea guida comune???
  • Re: Gestione Documenti

    Ahahaha.
    no, ovviamente.
    a parte la mia, ma sono comandamenti divini, non guide.

    Sui campi null: ni.
    in generale è meglio non averli affatto.
    Nel tuo caso un campo personagiuridica 0/1,non discrimine su data null
  • Re: Gestione Documenti

    +m2+ ha scritto:


    Ahahaha.
    no, ovviamente.
    a parte la mia, ma sono comandamenti divini, non guide.

    Sui campi null: ni.
    in generale è meglio non averli affatto.
    Nel tuo caso un campo personagiuridica 0/1,non discrimine su data null
    nel mio caso non avrei un campo persona giuridica 0/1 in quanto in realtà sarebbero di +
    ma un campo enum che indica il tipo di persona....

    era solo un discorso a livello di prestazioni....

    non che stia costruendo un DB con miliardi di dati...
    ma quando faccio una cosa mi piacerebbe farla bbbbene
Devi accedere o registrarti per scrivere nel forum
51 risposte