Campi proposti e modificabili

di il
19 risposte

Campi proposti e modificabili

Buongiorno a tutti,

sono nuova del forum e dovete pertanto scusarmi se magari non ho trovato la mia prossima domanda già trattata in qualche altro argomento.
Ho le tabelle Clienti e Preventivi, collegate tra esse da una relazione 1 a molti. Nella maschera di inserimento di nuovi Preventivi, richiamo il capo Pagamento che è registrato nella tabella Clienti; vorrei che questo campo fosse modificabile nel Preventivo ma non nella tabella di appartenenza del campo stesso, cioè non modificabile nella tabella Clienti. Sostanzialmente il Pagamento deve essere "suggerito" in quanto è il solito applicato, ma nella tabella dei Preventivi deve essere modificabile. Cosa devo fare?

Grazie anticipatamente a chi riuscirà a darmi un suggerimento.

19 Risposte

  • Re: Campi proposti e modificabili

    visionbbacc ha scritto:


    ...
    Ho le tabelle Clienti e Preventivi, collegate tra esse da una relazione 1 a molti. Nella maschera di inserimento di nuovi Preventivi, richiamo il capo Pagamento che è registrato nella tabella Clienti; vorrei che questo campo fosse modificabile nel Preventivo ma non nella tabella di appartenenza del campo stesso, cioè non modificabile nella tabella Clienti. Sostanzialmente il Pagamento deve essere "suggerito" in quanto è il solito applicato, ma nella tabella dei Preventivi deve essere modificabile....
    Prima cosa da fare è avere anche nella tabella Preventivi un campo [Pagamento], perché non puoi usare quello del Cliente. Hai una tabella che raccoglie le modalità di pagamento?
    Quando vai il preventivo, dopo aver selezionato il cliente scrivi codice vba in modo che il controllo associato al [Pagamento] del preventivo sia valorizzato a quello nell'anagrafica del cliente.
    Se hai una tabella che contiene tutte le modalità di pagamento ammesse potresti usare una combo per modificare il valore che viene proposto.
    Come è strutturata la maschera di creazione del nuovo preventivo? In particolare come scegli il cliente a cui si riferisce il preventivo? Capito questo vediamo qual è l'evento più adatto per valorizzare il pagamento del preventivo.
    ===
    Piccola divagazione: potrebbe interessarti associare ad ogni cliente più modalità di pagamento (di cui magari una predefinita) e prendere da quell'elenco le voci? questro prevede un'ulteriore tabella che dove inserisci per ogni cliente le varie modalità. Fine della divagazione
  • Re: Campi proposti e modificabili

    Allora, inizio con il creare un campo nella tabella Preventivi che si chiami anch'esso Pagamento visto che non c'è. Poi? Non ho comunque una tabella che raccoglie tutte le modalità di pagamento, serve per il mio fine?
    Scusami ma non so cosa dici quando parli di "scrivi codice VBA in modo che il controllo associato al [Pagamento] del preventivo sia valorizzato a quello nell'anagrafica del cliente", perché di programmazione SQL non so niente; pensi che ce la posso fare lo stesso?
    Nella maschera di creazione del nuovo preventivo ho un campo dove scrivo il codice del cliente e tramite questo codice univoco il preventivo va a prendersi i campi che servono dalla tabella del cliente.
    Per rispondere invece alla piccola divagazione, non mi interessa avere più modalità di pagamento sullo stesso cliente.
  • Re: Campi proposti e modificabili

    visionbbacc ha scritto:


    Allora, inizio con il creare un campo nella tabella Preventivi che si chiami anch'esso Pagamento visto che non c'è.
    Ecco, magari evita di usare lo stesso nome che hai usato per la tabella Clienti, in modo che si capisca fin da subito che si trova in Preventivi. Nel dettaglio: cosa scrivi nel campo [Pagamento] (nella tabella Clienti o in Preventivi)? un codice? una descrizione?

    visionbbacc ha scritto:


    Non ho comunque una tabella che raccoglie tutte le modalità di pagamento, serve per il mio fine?
    Non necessariamente ma, indipendentemente da questa specifica necessità, la vedrei bene una tabella che raccoglie le modalità di pagamento, così sono tutte codificate. Certo aiuterebbe molto poi se si vuole creare una combobox nella maschera (dell'anagrafica del cliente o di quella di creazione del preventivo) per proporre il valore da inserire. Sai cos'è la normalizzazione?

    visionbbacc ha scritto:


    Nella maschera di creazione del nuovo preventivo ho un campo dove scrivo il codice del cliente
    Lo scrivi? non hai una maschera, una combo o qualcosa che ti fa una ricerca del cliente? Detta così sembra una gestione molto "manuale"

    visionbbacc ha scritto:


    e tramite questo codice univoco il preventivo va a prendersi i campi che servono dalla tabella del cliente.
    Hai campi della tabella Preventivi che vengono popolati prendendo valori dalla tabella Clienti? Illustra meglio questo aspetto, non vorrei che sotto ci fosse un errore di strutturazione del db.

    visionbbacc ha scritto:


    Scusami ma non so cosa dici quando parli di "scrivi codice VBA in modo che il controllo associato al [Pagamento] del preventivo sia valorizzato a quello nell'anagrafica del cliente", perché di programmazione SQL non so niente; pensi che ce la posso fare lo stesso?
    No, non ce la fai se il codice vba lo chiami programmazione SQL e questo è l'ostacolo più difficile da superare, nel senso che dimostra che sei totalmente a digiuno di nozioni (in senso buono, non prenderla come un'offesa: tutti siamo partiti non conoscendo niente e abbiamo imparato nel corso del tempo). Con "scrivi codice vba" non intendevo comunque lasciarti in totale abbandono, il forum è qui anche per questo, però qualcosa devi già sapere.
    (rileggere, l'ho modificato almeno 8 volte in 2 minuti, anche se per dettagli)
  • Re: Campi proposti e modificabili

    Nel campo [Pagamento] della tabella Cliente è inserito un testo libero che appare identico quando lo visualizzo nella maschera Preventivi (perché la stessa è composta dai campi di entrambe le tabelle).

    Non so cosa sia la normalizzazione.

    Il codice lo inserisco a mano….ebbene sì

    No, non ho campi della tabella Preventivi che vengono popolati prendendo valori della tabella Clienti, ma è quello che avrei bisogno da fare. Nella maschera Preventivi appaiono sia campi della tabella Preventivi che campi della tabella Clienti e così poi nel report di stampa. Quindi come posso creare un campo nella tabella Preventivi che mi proponga il testo registrato nel campo [Pagamento] della tabella Clienti e che possa, una volta proposto, essere modificabile nella tabella Preventivi?
  • Re: Campi proposti e modificabili

    visionbacc ha scritto:


    il campo Pagamento che è registrato nella tabella Clienti

    visionbacc ha scritto:


    non ho campi della tabella Preventivi che vengono popolati prendendo valori della tabella Clienti, ma è quello che avrei bisogno da fare. Nella maschera Preventivi appaiono sia campi della tabella Preventivi che campi della tabella Clienti e così poi nel report di stampa

    visionbacc ha scritto:


    Non so cosa sia la normalizzazione.
    Quando non si conosce basilarmente la normalizzazione, bisogna affidarsi almeno al buon senso (che è lo stesso alla base della normalizzazione). Sembra un gioco di parole, ma in definitiva le cose stanno proprio così.
    Almeno un paio di errori che avresti commesso:
    1. Non si devono avere gli stessi campi in più tabelle, almeno che non si tratti della chiave primaria che richiama la chiave esterna, ma ciò avviene attraverso un solo campo fra 2 tabelle.
    2. I campi riguardanti una tabella devono essere "omogenei" ossia devono parlare lo stesso linguaggio o essere attinenti al titolo della tabella stessa. Una tabella anagrafica di Clienti deve contenere solo i suoi dati ANAGRAFICI. Il campo Pagamento non lo è.
  • Re: Campi proposti e modificabili

    OsvaldoLaviosa ha scritto:


    ...
    1. Non si devono avere gli stessi campi in più tabelle, almeno che non si tratti della chiave primaria che richiama la chiave esterna, ma ciò avviene attraverso un solo campo fra 2 tabelle.
    2. I campi riguardanti una tabella devono essere "omogenei" ossia devono parlare lo stesso linguaggio o essere attinenti al titolo della tabella stessa. Una tabella anagrafica di Clienti deve contenere solo i suoi dati ANAGRAFICI. Il campo Pagamento non lo è.
    Preciso che il mio intervento è riferito solo al discorso "Pagamento", così come illustrato all'inizio del thread.
    Per campo [Pagamento] inserito nell'anagrafica del Cliente io ho interpretato il "tipo di pagamento": contanti, bonifico, carta di credito ecc.
    Se, come ha detto visionbbacc, non serve associare ad un Cliente più di una modalità di pagamento, secondo me ci può stare (anzi è proprio la sua collocazione naturale) il campo (tipo di)[Pagamento] nell'anagrafica del Cliente.
    Siccome c'è la necessità di svincolarsi da quel valore, consentendo in sede di preventivo l'uso di una modalità di pagamento diversa da quella consueta, non si può che aggiungere un campo (tipo di)[Pagamento] anche alla tabella Preventivi che, con il famoso codice di cui si parla, dovrebbe essere in prima battuta valorizzato a quello presente nella tabella Clienti ma suscettibile di modifica (solo in Preventivi).
    Se ho inquadrato male la situazione, ovviamente, tutto quello che ho detto non vale. Se ci sono proposte diverse ben vengano, perché in situazioni di questo tipo mi sono sempre comportato così e... errare è umano, migliorare è informatico.
  • Re: Campi proposti e modificabili

    Per Philcattivocarattere: per me quello che hai proposto ha il sapore della "pezza a colori". Personalmente non sono d'accordo per i seguenti motivi:
    1. Il campo Pagamento non è omogeneo con i restanti campi tipicamente Anagrafici.
    2. Il fatto che si voglia inserire un TipoPagamento di default in tabella Preventivi, credo vada gestito diversamente. Si potrebbe catturare il TipoPagamento del primo record Preventivi del ClienteX. Oppure prendere il valore più diffuso dalla sua serie di Preventivi.

    A seguito del mio punto 2. ritengo che in ogni caso (sia per la tua soluzione, sia per la mia) ci sarebbe da mettere in piedi una query che valuti tale valore e sicuramente un opportuno codice VBA che provveda ad assegnarne il valore.

    Altra soluzione MOLTO PIU' SEMPLICE, senza codici e orpelli vari (così farei io). Se il cliente Rossi Mario ha prodotto il primo Preventivo, in esso comparirà il "primo" TipoPagamento. Se visionbbacc ha previsto maschera/sottomaschera (classica) Clienti/Preventivi, gli basterà (dal secondo record in poi) digitare CTRL+' (apostrofo) per sfruttare il valore precedentemente inserito.
  • Re: Campi proposti e modificabili

    Buongiorno ad entrambi e vi ringrazio anticipatamente.
    Venendo a noi: Philcattivocarattere ha capito in pieno il mio "problema" e concordo con lui sul discorso anagrafica, solo che a questo punto devo capire come scrivere un codice VBA e questo è un altro problema.
    Per OsvaldoLaviosa: non mi serve richiamare il pagamento utilizzato per il primo preventivo perché potrebbe nel tempo aver subito modifiche a fronte di uno storico; per esempio posso aver iniziamo con un pagamento "anticipato" e dopo alcuni preventivi (ovviamente diventati ordini) posso aver definito con il cliente il pagamento bonifico a 60 giorni, quindi se io continuo a richiamare il primo non è corretto per il cliente che potrebbe avere da ridire. Stessa cosa, non potrei nemmeno richiamare l'ultimo pagamento nell'ultimo preventivo perché magari è legato al cospicuo importo o a trattative. Devo quindi partire da quello che è il cosiddetto "Pagamento standard"
  • Re: Campi proposti e modificabili

    OsvaldoLaviosa ha scritto:


    Per Philcattivocarattere: per me quello che hai proposto ha il sapore della "pezza a colori". Personalmente non sono d'accordo per i seguenti motivi:
    1. Il campo Pagamento non è omogeneo con i restanti campi tipicamente Anagrafici.
    ....
    Indipendentemente dal fatto che si voglia avere la possibilità di usare una modalità di pagamento diversa in "Preventivi", dove metteresti la modalità di Pagamento "predefinita" del Cliente? Dalla ricostruzione che ne hai fatto comparirebbe solo in Preventivi e verrebbe selezionata in base a quella usata più di frequente (presente solo in Preventivi) o in base alla prima usata (sempre in Preventivi).
    Perché il tipo di pagamento non può essere in una tabella Anagrafica Cliente? solo per il fatto che non è strettamente un "dato anagrafico"? Però è strettamente e direttamente legato al Cliente, come il suo codice fiscale, il numero di telefono, l'indirizzo e-mail (parlo di una situazione semplice, rapporto 1 ad 1, un cliente - un numero di telefono solo, se al massimo ne voglio due, creo un altro campo con Telefono2, non vado a creare relazioni uno a molti per una cosa del genere)
  • Re: Campi proposti e modificabili

    visionbbacc ha scritto:


    ...
    Venendo a noi: Philcattivocarattere ha capito in pieno il mio "problema" e concordo con lui sul discorso anagrafica
    Almeno quello! (ndPhil: è un intercalare mio questo, che fa il verso ad una persona che conosco)

    visionbbacc ha scritto:


    ..., solo che a questo punto devo capire come scrivere un codice VBA e questo è un altro problema.
    l'hai detto

    visionbbacc ha scritto:


    ... posso aver definito con il cliente il pagamento bonifico a 60 giorni, quindi se io continuo a richiamare il primo non è corretto per il cliente che potrebbe avere da ridire. ...
    Ti consiglio comunque di codificare i Tipi di pagamento ed eventualmente anche il Termine di pagamento (compatibilmente con il Tipo pagamento)... anche se su quest'ultimo aspetto sono impreparato, non l'ho mai gestito.
    Non puoi ogni volta digitare "bonifico" (indipendentemente che sia a 30, 60 o n giorni) e memorizzarlo in un campo testo. Se scrivi "boMifico"? o " bonifico" (con lo spazio iniziale)? Siccome il valore lo prenderesti dall'anagrafica del Cliente, una tabella che codifica le modalità di pagamento è caldamente suggerita. Questa è una delle conseguenze del fatto che non conosci la normalizzazione.
    Accantonando per un attimo il fatto che non conosci vba, in ogni caso a lungo andare un database strutturato così mostrerebbe questi difetti di progettazione.
  • Re: Campi proposti e modificabili

    Philcattivocarattere ha scritto:


    Perché il tipo di pagamento non può essere in una tabella Anagrafica Cliente? solo per il fatto che non è strettamente un "dato anagrafico"? Però è strettamente e direttamente legato al Cliente, come il suo codice fiscale, il numero di telefono, l'indirizzo e-mail (parlo di una situazione semplice, rapporto 1 ad 1, un cliente - un numero di telefono solo, se al massimo ne voglio due, creo un altro campo con Telefono2, non vado a creare relazioni uno a molti per una cosa del genere)
    Sono convinto che un altro utente più esperto di me mi darebbe ragione.
    Il tuo ragionamento tenta di reggere quando affronti il discorso uno-a-uno...ma...Ma ci rendiamo conto che un TipoPagamento è più strettamente legato al singolo Preventivo e non alla Persona? Quanto affidabile è il valore predefinito in tabella Anagrafica qualora un Cliente tende a pagare in molti modi diversi?

    Attenzione quando si fanno attribuzioni di questo genere...ho paura di andare fuori tema...ma sento fortemente di dirlo. Ci pensate se in una tabella Anagrafica esistesse il campo PensieroPolitico? Molti di noi tendiamo facilmente a ETICHETTARE le Persone e riempiremmo volentieri quel campo. Ma ci rendiamo conto della pericolosità di una operazione del genere? Non dico che etichettare in questo senso sia sbagliato, ma è sbagliato attribuirlo in senso assoluto.

    Ritornando a Clienti e Preventivi. E se ci si accorge, con il passare del tempo (perchè è questo che detta legge nella moltitudine dei record di un database) che non sono poi così tanti e sistematici coloro che pagano nella stessa maniera? Il campo Clienti.Pagamento rischia seriamente di essere vanificato.

    Secondo me visionbbacc non ha colto la potenzialità della normalizzazione e suddivisione ragionata su più tabelle e avrebbe focalizzato l'attenzione su questo problema che, per me, si presenta come "falso problema". Non mi stupisco, può accadere, siamo qui ad analizzarlo e dibatterlo.
    Sotto questo punto di vista, mi associo a queste considerazioni

    Philcattivocarattere ha scritto:


    Ti consiglio comunque di codificare i Tipi di pagamento ed eventualmente anche il Termine di pagamento (compatibilmente con il Tipo pagamento)... anche se su quest'ultimo aspetto sono impreparato, non l'ho mai gestito.
    Non puoi ogni volta digitare "bonifico" (indipendentemente che sia a 30, 60 o n giorni) e memorizzarlo in un campo testo. Se scrivi "boMifico"? o " bonifico" (con lo spazio iniziale)? Siccome il valore lo prenderesti dall'anagrafica del Cliente, una tabella che codifica le modalità di pagamento è caldamente suggerita. Questa è una delle conseguenze del fatto che non conosci la normalizzazione.
  • Re: Campi proposti e modificabili

    Dico la mia , ovvero come faccio io nei programmi gestionali che ho realizzato:

    1) una tabella ModalitaPagamenti:
    Campi: IDPagamento (PK), Pagamento, Predefinito, Nota, ecc.
    Ovviamente c'è UN solo pagamentoe Predefinito.

    2) una tabella CategoriaPagamenti:
    Campi: IDCategoriaPagamento, Categoria
    per Categorie, si intende Assegno, Contanti, Bancomat, RIBA, Carta di Credito, RID, Altro, ..

    3) una tabella Rateazioni:
    IDRateazione (PK), IDPagamento, NrRata, NumGiorniDopoFineMese, NrGiorno, PercRata, FineMese
    Questa tabella serve a gestirte tutte le varie impostazioni relative alle eventuali rateazioni di pagamento, 2 esempi:
    1- RIBA 30/60/90 FM
    Il programma genera 3 rate (30/60/90) con scadenza a FineMese (FM).
    2- Bonifico 60/90/120/180
    Il programma genera 4 rate la cui scadenza cade lo stesso giorno del documento
    e così via...
    Ciò consentirà di fare emettere le RIBA alla banca, oppure di attivare il controllo dei pagamenti verificare

    4) una tabella Pagamenti:
    Questa tabella contiene tutte le informazioni relative ai singoli pagamenti (Dati del documento, Importo, DataScadenza, DataPagamento, Categoria e Modalita di pagamento, ecc.
    Questa tabella è fondamentale per la verifica dei pagamenti e la conseguente gestione dei solleciti (che richiede un ulteriore tabella Solleciti) che vengono inviati per email o per lettera, previa conferma dell'utente.

    5) Nella tabella anagrafica Clienti uso il campo IDPagamento; è quello predefinito del cliente, che viene valorizzato con il Predefinito della tabella ModalitaPagamenti al momento della creazione del cliente.

    6) Nelle tabelle dei Documenti uso il campo IDPagamento che è riferito al singolo documento.
    In sostanza: quando si crea un nuovo documento e si seleziona il cliente accade che:
    l'IDPagamento (ModalitaPagamenti) caricato è quello Predefinito del cliente, poi posso sempre modificarlo.

    Questo è il form di gestione dei pagamenti:


    Appare chiaro che le relazioni sono assolutamente da evitare per le tabelle ai punti 5 e 6.

    E' altrettanto ovvio che se non si conosce il VBA è impossibile anche solo pensare di poter gestire i pagamenti in modo efficiente ed efficacie.
    Non esiste strumento al mondo in grado di fare queste cose con qualche semplice clic (almeno io non ne conosco).

  • Re: Campi proposti e modificabili

    Philcattivocarattere ha scritto:


    OsvaldoLaviosa ha scritto:


    Per Philcattivocarattere: per me quello che hai proposto ha il sapore della "pezza a colori". Personalmente non sono d'accordo per i seguenti motivi:
    1. Il campo Pagamento non è omogeneo con i restanti campi tipicamente Anagrafici.
    ....
    Indipendentemente dal fatto che si voglia avere la possibilità di usare una modalità di pagamento diversa in "Preventivi", dove metteresti la modalità di Pagamento "predefinita" del Cliente? Dalla ricostruzione che ne hai fatto comparirebbe solo in Preventivi e verrebbe selezionata in base a quella usata più di frequente (presente solo in Preventivi) o in base alla prima usata (sempre in Preventivi).
    Perché il tipo di pagamento non può essere in una tabella Anagrafica Cliente? solo per il fatto che non è strettamente un "dato anagrafico"? Però è strettamente e direttamente legato al Cliente, come il suo codice fiscale, il numero di telefono, l'indirizzo e-mail (parlo di una situazione semplice, rapporto 1 ad 1, un cliente - un numero di telefono solo, se al massimo ne voglio due, creo un altro campo con Telefono2, non vado a creare relazioni uno a molti per una cosa del genere)
    E' estremamente evidente che alla base c'è una grande confusione di quello che è Normalizzazione e di quello che invece sono le Funzionalità dei campi...!
    Se il Cliente ha delle Impostazioni di Default questo è ovvio che richieda vengano salvate da qualche parte... questo non significa DUPLICARE o contravvenire alla NORMALIZZAZIONE... e bisogna conoscerla e capirla per portarla a supporto.
    L'idea di prendere il primo o il più usato, come ho sentito,... è una cosa che non esiste nella realtà, o meglio non risponde al concetto di valori predefiniti.

    Questa stasituazione è molto semplice e nonostante questo si riesce a fare confusione...
    La soluzione che proponi tu è sicuramente tutt'altro che una "pezza a colori" ma va bene, e se la si guarda nell'ottica più concreta è in sostanza quello che ha esposto GIBRA.

    Purtroppo non si capisce cosa significa dati di DEFAULT nella maggior parte dei casi... e non li si distingue dai Dati di archiviazione...

    Ad esempio se seguamo una manutenzione di macchinari, ogni tipo di Macchinario ha di Default, in base al TIPO, delle specifiche attività di manutenzione, ma nulla mi vieta di poter selezionare una Manutenzione non TIPICA da un Catalogo più generale...
    Questo richiede che le tabelle CatalodoTipo e CatalogoGenerico abbiano aggregazioni specifiche.
    Questi dati tuttavia sono STATICI o fini a se stessi... quando vado ad eseguire una Manutenzione, andrò ad inserire l'attività specifica in una Tabella di Interventi... ed ovviamente avrò una ipotetica ripetizione dei dati, in realtà non lo è... una cosa è il Catalogo un'altra l'applicazione...

    Abbiamo come sempre il problema dell'assolutismo non consapevole...
  • Re: Campi proposti e modificabili

    @Alex ha scritto:


    Se il Cliente ha delle Impostazioni di Default questo è ovvio che richieda vengano salvate da qualche parte...
    Vero quando dici "valore di default DA SALVARE DA QUALCHE PARTE".

    @Alex ha scritto:


    questo non significa DUPLICARE o contravvenire alla NORMALIZZAZIONE
    Queste cose tu le conosci meglio di tutti quanti (sicuramente meglio di me). Non posso che arrendermi.

    @Alex ha scritto:


    Purtroppo non si capisce cosa significa dati di DEFAULT nella maggior parte dei casi... e non li si distingue dai Dati di archiviazione...

    Ad esempio se seguamo una manutenzione di macchinari, ogni tipo di Macchinario ha di Default, in base al TIPO, delle specifiche attività di manutenzione, ma nulla mi vieta di poter selezionare una Manutenzione non TIPICA da un Catalogo più generale...
    Questo richiede che le tabelle CatalodoTipo e CatalogoGenerico abbiano aggregazioni specifiche.
    Questi dati tuttavia sono STATICI o fini a se stessi... quando vado ad eseguire una Manutenzione, andrò ad inserire l'attività specifica in una Tabella di Interventi... ed ovviamente avrò una ipotetica ripetizione dei dati, in realtà non lo è... una cosa è il Catalogo un'altra l'applicazione...
    Pienamente d'accordo. Su questa linea (che tu hai esposto magistralmente) io mi muoverei analogamente...ma la discussione si era piuttosto infognata/stagnata...e probabilmente nessuno era in grado di esprimerla in questi termini.

    Per me resta però che non metterei mai il campo TipoPagamento nella tabella Clienti.
    A questo punto siamo nell'ambito delle scelte soggettive.
Devi accedere o registrarti per scrivere nel forum
19 risposte