gabri ha scritto:
creare un listino prezzi generale , e per ogni singolo cliente viene fatto un listino prezzi personalizzato , che può dipendere probabilmente dalla quantità di prodotti richiesti dal cliente o altri fattori.
Fin qui, tutto normale, nel senso che è una normalissima gestione dei listini (normale perché la fa ogni azienda).
Quello che non capisco è:
a) se stai già gestendo questo scenario (e non riesci a farlo come vorresti) oppure
b) se questa è solo una 'dichiarazione di intento' (cioè cosa vorresti fare.
gabri ha scritto:
preciso che l'unica differenza tra i diversi listini non sono le tipologie di prodotti venduti , ma i singoli prezzi.
Certo, è normale che sia così.
gabri ha scritto:
ovviamente vorrebbero un programma in cui non debba essere necessario andare a controllare, ogni volta che si riceve un ordine, quale dei listini viene applicato per quel cliente e che prezzo ha quel prodotto , ma desidererebbero un database abbastanza automatico , almeno sotto questo punto di vista.
Hanno perfettamente ragione, ovviamente.
Per ottenere questo è importante creare la struttura giusta (tabelle) ed aggiungere una gestione corretta.
Ad esempio, in un gestionale che ho creato per un azienda il prezzo viene stabilito in base a vari parametri: bisogna di tutto occorre definire un Listino di Costo (per non rischiare di vendere sotto-costo), Listini Clienti personalizzati, Listini Clienti per quantità, posso avere anche Listini per singolo articolo di un singolo Cliente, e così via...
Infine, ognuno dei listini deve essere gestito con le Data di Validità.
Tanto per fare un esempio, nel nostro gestionale c'è anche il listino per Classe articolo, e per Valuta.
Come vedi la gestione la si può rendere anche molto complessa.
Partiamo quindi dai listini:
Prima di tutto quali sono le
chiavi primarie di
ogni tabella?
Ad esempio, la tabella Clienti dovrebbe avere la chiave primaria IDCliente.
La tabella Listini dovrebbe avere la chiave primaria IDListino.
In alcune li vedo, ma vedo anche poca omogeneità e un tantino di confusione nel nominarle.
In linea generale, per evitare future difficoltà di lettura e gestione dei campi, è sempre meglio mantenere una certa linearità nel chiamare gli oggetti, esempio:
Tabella ChiavePrimaria
Clienti IDCliente
Listini IDListino
Ordini IDOrdine
OrdiniRighe IDOrdineRiga
Sinceramente trovo deleterio usare un nome campo come "ID DISP", "ID STATO", primo perché contengono uno spazio (assolutamente sconsigliato !!!) poi ID DISP è usato dappertutto, e questo genera confusione, secondo costringe a usare le parentesi quadre nelle query, aumentando solo confusione.
Evitare anche gli underscore nei nomi, gli accenti e qualsiasi altro simbolo che non siano esclusivamente lettere.
Lo stesso vale per tabelle.
Non c'è alcuna ragione valida per utilizzare quanto sopra! Quindi perché complicarsi la vita per niente?
Se io scrivo IDListino, so già di cosa parlo, se scrivo ID DISP a cosa mi riferisco? Boh! Devo andare a controllare qual'è la tabella!
Dovresti spiegare BENE come hai relazionato le tabelle sugli Ordini e Prodotto, perché sono tutt'altro che chiare.
Intanto partiamo da qui.