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.