Gestione di più listini

di il
28 risposte

Gestione di più listini

Salve a tutti,
ho necessità di sostituire un database che avevo costruito 10 anni fa per la gestione delle lavorazioni di un laboratorio odontotecnico. Ovviamente negli anni le mie già misere nozioni di access sono abbastanza evaporate.
Comunque:
la base dati è costituita dalle tabelle:
CLIENTI (id, nomeCliente, ragione sociale, indirizzo etc.)
ORDINI (idOrdine, data ingresso, idCliente, Rif Paziente, note, dataChiusura)
LAVORAZIONI DA IMPUTARE (ID, quantità, ID tipo di lavorazione, IdOrdine, etc)
TIPI DI LAVORAZIONE (ID, NomeLavorazione, prezzo1, prezzo2, prezzo 3)

il problema nasce dalla necessità di gestire più listini per le stesse lavorazioni e legare un determinato listino ad un cliente (rel uno a molti, un listino può essere attribuito a più clienti)
una soluzione può essere quella sopra riportata prevedendo più colonne listino 1, 2 etc nella tabella tipi di lavorazione, però pensavo anche alla possibilità di fare una tabella LISTINI (ID, NomeListino) e una tabella LISTINI\LAVVORAZIONI (id, idListino, idLavorazione, prezzo) in modo da poter facilmente legare la tabella LISTINI a quella CLIENTI
Un'altra esigenza e quella di poter modificare manualmente in fase di input nelle maschere i valori calcolati quantità*prezzo, pensavo di fare in modo che all'atto della chiusura del lavoro il record venga trasferito in una tabella che si implementa
Altra cosa, l'aggiornamento dei listini non dovrebbe riperquotersi sui dati già archiviati.
spero di esser riuscito a farmi capire decentemente.
ringrazio già da ora chi volesse aiutarmi, sono decisamente all'empasse...

28 Risposte

  • Re: Gestione di più listini

    Intanto ti consiglio di nominare i campi ID in maniera propria in modo da non fare confusione, quindi IDCliente, IDOrdine, IDTipoLavorazione, IDListino...
    Sicuramente devi prevedere una tabella Listini con la relazione TipiLavorazioni uno-a-molti con Listini.
    Ordini e Listini sono in relazione molti-a-molti, quindi devi prevedere una tabella DettagliOrdini con i seguenti campi:
    IDDettaglio (contatore, chiave primaria)
    IDOrdine (numerico)
    IDListino (numerico)

    Relazioni:
    Ordini.IDOrdine uno-a-molti con DettagliOrdini.IDOrdine
    Listini.IDListino uno-a-molti con DettagliOrdini.IDListino
  • Re: Gestione di più listini

    Per prima cosa ringrazio per la risposta.
    Provo a integrare la spiegazione per esser sicuro di fornire tutti gli elementi per il mio quesito:


    - CLIENTI contiene i dati dei dentisti committenti dell'ordine
    - ORDINI contiene i dati del lavoro commissionato (nome paziente, data ingresso, data chiusura etc)
    - DETTAGLI ORDINE sono le lavorazioni eseguite all'interno di un determinato ordine e assoggettate alle voci del listino
    - ELENCO LAVORAZIONI è l'elenco delle lavorazioni disponibili del laboratorio odontotecnico ognuna delle quali ha cinque prezzi differenti (listino1, 2, 3, 4, 5)
    - LISTINI è semplicemente l'elenco dei nomi dei listini (L1, L2, L3 etc9 con i rispettivi id

    dallo schema manca la collocazione del prezzo dei rispettivi listini perchè non mi è chiaro se devo inserire un'altra tabella per gestire una relazione molti a molti.

    mi scuso se mi sono dilungato, ma volevo esser sicuro che fosse chiaro che i costi appartengono alle lavorazioni che vengono richiamate dal dettaglio ordini 8o forse sarebbe il caso di chiamarlo dettaglio lavorazioni effettuate)
    grazie ancora per l'attenzione.
  • Re: Gestione di più listini

    Quando crei le relazioni nella finestra Relazioni, abbi cura di mettere SEMPRE il segno di spunta su "Applica integrità referenziale", in questo modo dai piena giustificazione alla relazione uno-a-molti.
    Un TipoLavorazione avrà molti PrezziListino nell'arco della tua vita lavorativa. Per questo motivo TipiLavorazioni uno-a-molti con Listini. Poi sarà Listini a entrare in contatto con DettagliOrdini. Immagino tu avrai un problema visivo e disorientante quando vorrai selezionare un TipoLavorazione dentro DettagliOrdini. Se crei una query che filtra soltanto i Prezzi rispetto alla Data più recente (Max di Data), e poi una casella combinata ben congeniata in DettagliOrdini.IDLavorazion, potrai stare tranquillo di associare contemporaneamente TipoLavorazione e suo Prezzo recente.
    Penso che Listini dovrebbe avere i seguenti campi:
    IDListino
    DataListino
    IDTipoLavorazione
    Prezzo
  • Re: Gestione di più listini

    I listini multipli in realtà non servono per aggiornare i prezzi ma per assegnarne uno specifico a uno o più clienti, quindi mi sembrerebbe che il campo data del listino possa essere superfluo. facendo in questo modo riesco ad assegnare ad ogni cliente (dentista) un determinato listino? se si, come?
    inoltre vorrei una visualizzazione con l'elenco delle lavorazioni nelle righe e le colonne con intestazione listino1, listino2 etc contenenti i prezzi delle suddette lavorazioni per i cinque listini che intendo creare. E' realizzabile?
    di nuovo grazie per le risposte.
  • Re: Gestione di più listini

    Quindi dovrebbe funzionare in questo modo:


    mi correggo...
    così certamente nn può fuzionare, giusto? possibile che debba inserire un id contatore nella tabella listini e assegnare IDListino come numerico?
  • Re: Gestione di più listini

    Forse qualcosa del genere?
    mi rendo conto di brancolare nel buio, nel we andrò a ripescare i vecchi manuali in soffitta...
  • Re: Gestione di più listini

    Ti mostro come la vedo io. Questo il mio scenario tabelle:

    Clienti
    IDCliente
    Cognome
    RagioneSociale
    ...altri campi...

    Ordini
    IDOrdine
    DataIngresso
    DataChiusura
    IDCliente

    TipiLavorazioni
    IDTipoLavorazione
    TipoLavorazione

    Listini
    IDListino
    DataListino
    IDTipoLavorazione
    Prezzo

    DettagliOrdni
    IDDettaglio
    IDOrdine
    IDListino

    Relazioni:
    Clienti.IDCliente uno-a-molti con Ordini.IDCliente
    Ordini.IDOrdine uno-a-molti con DettagliOrdini.IDOrdine
    TipiLavorazioni.IDTipoLavorazione uno-a-molti con Listini.IDTipoLavorazione
    Listini.IDListino uno-a-molti con DettagliOrdini.IDListino

    Probabilmente la denominazione di tabella Listini può fuorviare l'intuizione logica. Ma la devi considerare come una tabella che raggruppa tutti i TipiLavorazione associati ai singoli Prezzi che, volta per volta, nel corso del tempo, si ripeteranno (molti). Devi considerare che immaginiamo tu hai LavorazioneX, LavorazioneY, LavorazioneZ (questi li troverai scritti una volta sola nella tabella TipiLavorazioni). Nel 2010 LavorazioneX costava 100,00, nel 2012 110,00, nel 2014 120,00. Questo significa che nella tabella Listini, LavorazioneX comparirà 3 volte con 3 Prezzi diversi (idem vale per LavorazioneY e LavorazioneZ). Quando devi compilare i DettagliOrdini, dovrai essere scaltro nell'organizzare una apposita casella combinata che ti permetta di scegliere IDListino con la LavorazioneX associata al Prezzo più recente. Ecco perchè ti serve il campo DataListino. Se non crei una apposita query che filtra la data ultima, saresti costretto a leggere 3 volte LavorazioneX e (di fatto) scegliere la più recente...ma comprendi bene che ciò risulta alquanto scomodo.
  • Re: Gestione di più listini

    Ho paura che ci sia un fraintendimento (e mi dispiace perchè sono certo che è colpa mia..) sul significato che attribuisco ai 'listini' nel senso che, non sono delle entità che sono sottoposte ad aggiornamenti o modifiche. Semplicemente ogni lavorazione nell'elenco delle lavorazioni proposte dall'azienda odontotecnica non ha un unico prezzo ma ne ha ben cinque, tanti quanti sono i listini preimpostati. Il senso è quello di venire incontro all'esigenza di avere dei listini con prezzi su misura per uno o più clienti in ragione di differenti condizioni contrattuali.
    perciò ci dovrà essere una maschera di input dell'elenco lavorazioni e dei differenti prezzi attribuiti che popoli una o più tabelle che necessariamente deve essere compilata prima dell'utilizzo corrente del database. Qualcosa tipo questa:



    Naturalmente potrebbe essere risolta anche mettendo tutto in un'unica tabella 'listino lavorazioni' con le colonne codice lavorazione, nome lavorazione e con cinque differenti colonne corrispondenti ai differenti prezzi di ogni 'listino' naturalmente mi rendo conto che non è certo una soluzione logica e poi non saprei come collegare quella specifica colonna ad un determinato cliente
  • Re: Gestione di più listini

    operaseconda ha scritto:


    Ho paura che ci sia un fraintendimento (e mi dispiace perchè sono certo che è colpa mia..) sul significato che attribuisco ai 'listini' nel senso che, non sono delle entità che sono sottoposte ad aggiornamenti o modifiche.
    A) Questo significa che i prezzi non cambieranno mai, per sempre? Non credo...

    operaseconda ha scritto:


    Semplicemente ogni lavorazione nell'elenco delle lavorazioni proposte dall'azienda odontotecnica non ha un unico prezzo ma ne ha ben cinque, tanti quanti sono i listini preimpostati. Il senso è quello di venire incontro all'esigenza di avere dei listini con prezzi su misura per uno o più clienti in ragione di differenti condizioni contrattuali.
    B) E se cambiano le esigenze contrattuali per un nuovo cliente, che fai: aggiungi un nuovo campo LISTINOX alla tabella? E se un cliente chiede un sconto per quantità, come ti regoli? Crei un ulteriore listino?

    operaseconda ha scritto:


    perciò ci dovrà essere una maschera di input dell'elenco lavorazioni e dei differenti prezzi attribuiti che popoli una o più tabelle
    C) Perché?Quante tabelle servono per i listini?


    Direi che il caso di mettere un po' d'ordine sulla questione listini, perché è molto più complessa di quello che sembra, intendo dire se si vuole gestire i listini in modo professionale, il che significa senza intoppi o sorprese di sorta.
    Quanto segue non è comunque esaustivo dell'argomento, ma è solo il minimo indispensabile da implementare. Se non lo si fa, un domani ci si ritroverà 'in braghe di tela' (come si suol dire) e si rimpiangerà il non averlo fatto. Ma, come sempre, sarà troppo tardi.
    Una gestione oculata dei listini e prezzi è un fattore fondamentale e determinante per qualsiasi azienda, non importa quanto grande essa sia (dal singolo dipendente, all'azienda da 10.000 dipendenti) perchè la gestione di base è esattamente identica; poi ovviamente per grosse aziende la questione si complica perché entrano in vigore altri fattori (Valuta, ecc.).
    Da noi, in azienda, la gestione listini è ancora più complessa (circa il doppio) di come la descrivo sotto perché vi sono ulteriori parametri che concorrono a determinare il prezzo (ma questo è un'altro discorso).

    Servono 2 tabelle: LISTINI_ANAGRAFICA e LISTINI_PREZZI

    1) I listini devono essere gestiti cone le date di validità, Inizio e Fine, perchè i prezzi degli articoli (preferisco chiamarli così in quanto Lavorazioni dovrebbe essere un Categoria degli Articoli) variano ed è indispendabile poter gestire lo storico dei prezzi.
    Un esempio, a Luglio sono aumentati i prezzi, riapri una fattura del mese di giugno per correggere un errore di un articolo, o aggiungerne un'altro che avevi dimenticato, ecc.
    Se non gestisci le date di validità ti ritrovi automaticamente il prezzo nuovo nella fattura vecchia. Il Cliente si arrabbia.
    Grazie alle date di validità, il sistema va a prendere il prezzo di listino in vigore alla data della fattura, ecco perché la tabella LISTINI deve essere così composta:
    IDPrezzo (PK), IDListino, IDArticolo, IDCliente, DataInizValidita, DataFineValidita
    in cui la DataFineValidita dell'ultimo prezzo ha il valore predefinito di: 31/12/9999.

    Come si evince dalla struttura ciò permette di ottenere con precisione il prezzo in funzione del Listino, del Cliente, dell'Articolo e della Data selezionati.
    Infatti basta una query semplicissima per ottenere l'ultimo prezzo valido di tutti gli articoli di un determinato Listino per uno specifico cliente:
    SELECT * FROM Listini
    WHERE IDListini = 3
    AND IDCliente = 54
    AND DataFineValidita = #9999/12/31#

    N.B. Dal punto di vista programmatico, tutti gli IDxxx della tabella consentono di ricavare tutte le informazioni utili, esempio grazie all'IDArticolo posso ottenere tutte le informazioni dell'articolo dalla tabella Articoli, stessa cosa per il cliente, ecc...


    2) I listini devono essere dinamici, ovvero l'utente deve poter creare un nuovo listino in qualsiasi momento, per andare a coprire una qualsiasi esigenza o scenario vengano a prospettarsi a livello contrattuale, ma soprattutto la cosa più banale: l'aumento dei prezzi !
    Questo vuol dire che si dovrà avere una tabella ANAGRAFICA LISTINI :
    IDListino (PK), Listino, Nota

    Il primo listino dell'anagrafica LISTINI deve sempre essere quello aziendale, cioè quello che si chiama in gergo il Listino Base, ovvero quello che contiene i prezzi stabiliti dall'azienda sotto i quali non si dovrebbe scendere, perché l'azienda andrebbe in perdita se lo facesse.
    Il Listino Base è quello di riferimento da cui si parte poi per creare gli altri listini con le varie maggiorazioni stabilite dalla 'regole di business' che l'azienda si da.


    3) Nella tabella Clienti deve esserci il campo IDListino che serve ad impostare il listino specifico che sarà applicato al Cliente.


    4) Nelle tabelle di dettaglio (ordine/ddt/fattura/ecc..) nella riga vanno sempre riportati
    - IDListino , del listino il prezzo applicato all'articolo
    - Prezzo unitario applicato
    Questo permetterà anche la gestione dell'Ultimo Prezzo Applicato, con verifica rispetto al Lisitno Cliente ed al Listino base.

    5) per completare il quadro si dovrebbe prevedere anche una tabella SCONTI (con la stessa logica dei Listini), ma questo è un altro discorso...

    Suggerimento:
    di norma si aggiungono sempre i seguenti campi a tutte le tabelle:
    DataCreazione (Default = Now) DataModifica, Utente, UtenteModifica
    per poter individuare sempre CHI ha fatto COSA (auditing).
    Questa funzionalità è già presente nei database server (SQL Server, Oracle, DB2,...), ma manca completamente in Access. Invece è importante.

  • Re: Gestione di più listini

    #gibra
    molte grazie del chiarimento, mi è molto utile. ora provo a metterlo in pratica.
    Riguardo ai punti che hai evidenziato, l'aggiornamento dei prezzi può avere una frequenza annuale o biennale, in realtà io pensavo di sovrascrivere le celle dei prezzi. L'aggiornamento a catena del periodo pre-aggiornamento pensavo di scongiurarlo impostando una funzione (una query') che all'atto della chiusura della lavorazione mi sposti ogni record relativo all'ordine (la commessa del lavoro da effettuare) in una tabella non legata.
    Questo dovrebbe garantirmi anche la possibilità di intervenire manualmente per correggere un prezzo o un totale senza che abbia influenza sul resto.
    E' una strada praticabile?
  • Re: Gestione di più listini

    operaseconda ha scritto:


    #gibra
    molte grazie del chiarimento, mi è molto utile. ora provo a metterlo in pratica.
    Riguardo ai punti che hai evidenziato, l'aggiornamento dei prezzi può avere una frequenza annuale o biennale,
    Come fai a stibilirlo a priori?
    I prezzi che applica un'azienda sono influenzati dagli acquisti (materie prime, lavorazioni, ecc.) quindi come fai a stabilire con precisione ogni quanto aumenta o diminuisce il prezzo di un articolo. A mio avviso è impossibile.

    operaseconda ha scritto:


    in realtà io pensavo di sovrascrivere le celle dei prezzi.
    Sovrascrivere dove? Nel Listino assolutamente no.
    Ma nel documento (preventivo, offerta, commessa, ordine, ddt, fattura, ricevuta, ...) puoi modificare i prezzi quando e come vuoi.

    operaseconda ha scritto:


    L'aggiornamento a catena del periodo pre-aggiornamento pensavo di scongiurarlo impostando una funzione (una query') che all'atto della chiusura della lavorazione mi sposti ogni record relativo all'ordine (la commessa del lavoro da effettuare) in una tabella non legata.
    Questo dovrebbe garantirmi anche la possibilità di intervenire manualmente per correggere un prezzo o un totale senza che abbia influenza sul resto.
    E' una strada praticabile?
    Non ho capito niente di quello che intendi dire.
    Ma probabilmente non hai ancora fornito tutte le informazioni atte ad entrare nello specifico delle tue esigenze.
    Attività come Chiusura lavorazione, spostare record, tabella non legata, ecc. sono per me sconosciute e prive di senso.

  • Re: Gestione di più listini

    Mi scuso, provo a spiegare meglio, mi appello a tutte le mie capacità di sintesi:
    15 anni fa ho progettato da me il database di gestione della mia attività di laboratorio odontotecnico che ho utilizzato per oltre dieci anni tra aggiustamenti e interventi di 'manutenzione' .
    circa 3 anni fa l'ho sostituito con un software professionale proprio per questa caratteristica (assente nell'architettura del mio db) della assegnazione fissa di uno specifico listino ad un determinato cliente.
    Escludendo questa caratteristica che me lo rende indispensabile, per mille altri motivi, il passaggio ad un software specifico mi è sempre risultato indigesto, abituato come ero a gestire input e visualizzazione di dati nella massima libertà secondo le mie esigenze.
    Tutto questo per dire che il mio tentativo di oggi è quello di replicare con poche variazioni l'architettura di quel software 'chiuso' con il vantaggio dato dal poter progettare maschere, query e funzioni ad hoc per il suo utilizzo.
    Riguardo alle considerazioni di quanto sia difficile stabilire a priori le frequenze degli aggiornamenti di un listino, condivido in toto, ma quell'impostazione di sovrascrivere i dati viene proprio dall'uso di quel software che non prevede campi data abbinati ai listini (sempre che questo meccanismo nn avvenga in background, ma tenderei ad escluderlo)
    naturalmente anche io ho l'esigenza che sovrascrivendo i prezzi non mi vengano aggiornati a catena i recordset relativi ai dati già archiviati, ma pensavo di scongiurare questo evento con una funzione che mi consenta di prelevare il record specifico di un determinato ordine nel momento in cui lo stesso è stato effettuato e completato (a questo mi riferivo parlando di lavorazione chiusa) e trasferire per mezzo di una queri di accodamento i dati ad una diversa tabella che non avendo una relazione con le altre tabelle non subirebbe l'effetto degli aggiornamenti a catena.
    Poi, magari il mio è tutto uno sproloquio, d'altra parte sono passati molti anni e quelle tre nozioni apprese sulla progettazione di db, come ho già detto, sono ampiamente evaporate...
  • Re: Gestione di più listini

    Sicuramente la tabella proposta nel post del 18/7/2014 ore 23:50 è sbagliata. I Prezzi non devono essere disposti orizzontalmente così, ma devono poter cambiare nel tempo anche all'infinito. Quindi una apposita tabella Prezzari (o Listini come già detto).
    Il discorso di gibra mi appare troppo complicato. Non ho letto bene bene, ma non sono d'accordo nel mettere un campo IDListino in tabella Clienti. La mia proposta di scenario tabelle mi sembra la più semplice ed efficace per la causa richiesta da operaseconda.
  • Re: Gestione di più listini

    OsvaldoLaviosa ha scritto:


    Il discorso di gibra mi appare troppo complicato. Non ho letto bene bene, ma non sono d'accordo nel mettere un campo IDListino in tabella Clienti. La mia proposta di scenario tabelle mi sembra la più semplice ed efficace per la causa richiesta da operaseconda.
    Quindi tu come faresti ad impostare un listino specifico predefinito per un determinato cliente?
    Cerchiamo di essere costruttivi.
Devi accedere o registrarti per scrivere nel forum
28 risposte