Gestione preventivi e listini

di il
22 risposte

Gestione preventivi e listini

Salve a tutti, sto cercando di realizzare un database che mi aiuti nella gestione dei commerciale dei miei clienti.
Nel dettaglio dello scopo del database sarebbe:
1. un contenitore per il\i listino
2. un contenitore per lo storico di assegnazione del listino ai clienti
3. dato che avrei nello stesso contenitore un minimo di anagrafica del cliente e il\i listino\i tornerebbe utile poter fare delle offerte da inviare ai clienti e archiviare.

La mia attività si svolge in varie aree geografiche italia\estero e i prezzi cmq sono sempre in euro ed esclusi IVA, la mia azienda opera con fornitore e subfornitore, i miei clienti sono rivenditori e produttori di macchinari ai quali a quest'ultimi vendiamo componenti che poi loro montano sulle loro macchine.

1. un contenitore per il\i listino
Più che listino i listini sono 11,
Listino PU Pubblico (prezzo di vendita consigliato al pubblico)
Listino DA - DB - DC sono listini dedicati ai rivenditori, con un prezzo che varia per fascia di sconto, la fascia di sconto l'assegno in base alle volumi di acquisto annuali espressi
Listino DX - MA - MB - MC - MD sono listini dedicati ai produttori, con un prezzo che varia per fascia di sconto, la fascia di sconto l'assegno in base alle volumi di acquisto annuali espressi.
Listino BA è il listino minimo sotto il quale non posso scendere di prezzo.
Aggiungo che potrebbe tornare utile anche poter avere la possibilità di poter assegnare ad un cliente uno dei suddetti listino ma per alcuni prodotti potergli assegnare dei prezzi netti magari più bassi del listino ma mai sotto il listino base.
Vorrei anche poter stampare i listini personalizzati da inviare sai clienti.

2. un contenitore per lo storico di assegnazione del listino ai clienti
Questo contenitore mi servirebbe per tenere traccia di quale listino è stato assegnato al cliente ed in quale data.

3. dato che avrei nello stesso contenitore un minimo di anagrafica del cliente e il\i listino\i tornerebbe utile poter fare delle offerte da inviare ai clienti e archiviare.
Data la registrazione dell'assegnazione del listino al cliente, quindi presenza nel database di listini ed anagrafica clienti, mi sarebbe utile poter produrre anche le offerte ed tenerle in memoria con un indicazione di stato attiva\chiusa in modo da estrapolare un report sulle offerte aperte o chiuse.

Iniziando a lavorare sulla struttura ho iniziato a costruire le tabelle.
TABELLE RIFERIMENTO CLIENTI

TAB: AnagraficaCliente
ID_Cliente - Azienda - NomeCognome - Email - AreaCliente - PaeseCliente - TipoCliente -
NoteCliente

TAB: TipoCliente
ID_TipoCliente - Tipo1 - Tipo2 - Tipo3 - Tipo4 - Tipo5 - Tipo6 - Tipo7 - Tipo8 - Tipo9 - Tipo10

TAB: AreaCliente
ID_AreaCliente - Area1 - Area2 - Area3 - etc.

TAB: PaeseCliente
ID_PaeseCliente - Paese1 - Paese2 - etc.

TABELLE RIFERIMENTO LISTINO

TAB: FamiglieProdotti
ID_FamigliaProdotti - Famiglia

TAB: Prodotti
Id_Prodotti - Nomeprodotto - ImmagineProdotto

TAB: Articoli
Id_Articolo - CodiceArticolo - DescrizioneArticolo - DimensioneArticolo - InstallazioneArticolo- QuantitàConfezioneArticolo

TAB: AnagraficaListini
ID_TipoLisitino - TipoListino

TAB: Listino
Id_Listino - Id_Articolo - Prezzo

TABELLE OFFERTE ASSEGNAZIONE LISTINO

TAB: ListinoCliente
ID_ListinoCliente - ID_Listino - Id_Cliente - InizioValidità - FineValidità

TAB: AnagraficaOfferteCliente
Id_AnagraficaOfferteCliente - Id_Offerte - Id_Cliente - DataOfferta - DataChiusura - Id_Listino - Riferimenti - Note

TAB: OfferteCliente
Id_OffertaCliente - Id_cliente - Id_Articolo - Quantità - Id_Listino - PrezzoUnitario - DataOfferta - ValiditàOfferta - Note


La struttura del DB l'ho pensata in questo modo chiaro che il secondo passo è creare le relazioni UNOaUNO UNOaMOLTI MOLTIaMOLTI, però prima vorrei capire se mi sono lasciato indietro qualcosa perchè ho dei dubbi sui listini sopratutto in quale tabella devo indicare i prezzi dei vari listini o se indicare una serie di sconti per famiglia prodotti? ho come la sensazione che sia incompleto e che così non giri.

Mi potete aiutare? grazie

22 Risposte

  • Re: Gestione preventivi e listini

    Ciao.

    Facciamo un passo alla volta e partiamo dalla prima parte che è anche la più semplice da realizzare e che può servire da esempio per poi sviluppare la seconda parte.

    A prima vista ci sono delle grosse inesattezze nella struttura del database, dettate dal fatto che hai ragionato come se stessi lavorando con un foglio di excel e non su una struttura diun database.

    Non ti preoccupare, quando avrai capito come funziona un database non incorrerai più in questo tipo di errori (ne verranno altri )

    Quello che ti presento è un mio suggerimento, come, naturalmente secondo me, dovrebbe essere in linea di massima strutturato.
    TAB: AnagraficaCliente
    ID_Cliente - Azienda - NomeCognome - Email - AreaCliente - PaeseCliente - TipoCliente -
    NoteCliente
    ID_Cliente - Azienda - Nome-Cognome - Email - idAreaCliente - idPaeseCliente - idTipoCliente - 
    NoteCliente
    Il nome ed il cognome devono essere due campi distinti perchè se in futuro avrai bisogno di far riferimento al cliente per nome o per cognome potrebbero crearsi dei problemi se il nome ed il cognome si trovano sullo stesso campo.
    Inizialmente pensavo che avessi deciso di archiviare Areacliente, paese etc etc, come dati ripetuti ogni volta, ma poi ho visto che hai deciso di usare invece delle tabelle a parte.
    Per riconoscere al volo quello che dovranno contenere e per semplicità di costruzione delle fasi successive del database, è bene che nel nome sia intrinsico anche il significato dei dati che dovranno contenere, quindi ho aggiunto il suffisso ID.
    TAB: TipoCliente
    ID_TipoCliente - Tipo1 - Tipo2 - Tipo3 - Tipo4 - Tipo5 - Tipo6 - Tipo7 - Tipo8 - Tipo9 - Tipo10
    ID_TipoCliente - Tipocliente
    L'approccio logico di come hai affrontato questa struttura tabella è tipico di excel.
    In realtà in Access e nei database in generale tipo1-tipo2- etc etc, sono i DATI che dovranno essere immessi in un unico campo contenitore e cioè Tipocliente.
    TAB: AreaCliente
    ID_AreaCliente - Area1 - Area2 - Area3 - etc.

    TAB: PaeseCliente
    ID_PaeseCliente - Paese1 - Paese2 - etc.
    Vedi spiegazione per il Tipocliente


    Le cose successive, più complesse le dovremo affrontare successivamente.

    Utilizzando questa prima parte, devi creare le relative relazioni, creare le tabelle ed i report e naturalmente far in modo che la tabella anagrafica cliente venga popolata nel modo giusto.

    se hai delle difficoltà, noi siamo qua.
  • Re: Gestione preventivi e listini


    DatabaseRelazioniCliente.JPG
    DatabaseRelazioniCliente.JPG

    Ti ringrazio ed in effetti mi sono accordo dell'errore macroscopico nell'approcciare la parte di anagrafica che prontamente o modificato come da immagine che qui posto creando inoltre le relazioni
    1. TAB: ClienteAnagrafica - campo IDPaese unoAmolti con TAB ClientePaese campo IDClientePaese
    2. TAB: ClienteAnagrafica - campo IDClienteArea unoAmolti con TAB Cliente_Area campo IDClienteArea
    3. TAB: ClienteAnagrafica - campo IDPClienteTipo unoAmolti con TAB ClienteTipo campo IDClienteTipo
  • Re: Gestione preventivi e listini

    Forse avresti dovuto postare il thread nella sezione "Progettazione database". Tuttavia vedo che è proseguita qui, continuiamo pure.
    Non vorrei sembrare pignolo, ma consiglio di nominare le tabelle sempre al plurale e con nomi semplici: Clienti, Aree, Paesi, Tipi. I campi al singolare semplice IDArea, Area, IDTipo, Tipo...
    Mi pare di capire che Area è una porzione geografica più piccola rispetto a Paese. Direi che è sufficiente avere solo IDArea in tabella Clienti. In verità, a voler fare un discorso più completo, solitamente si mettono i campi Indirizzo e poi semplicemente IDComune. Una tabella Comuni con tutti i campi Zonali tipici (Paese, Regione, Provincia, CAP...) assolvono automaticamente a conoscerne la collocazione geografica.
    Che significa Tipo? Se è una caratteristica strettamente legata alla RagioneSociale, va bene un campo IDTipo in tabella Clienti. Ma se si tratta di una connotazione "psicologica", direi che è destinata a variare nel tempo...spero di non travisare e/o andare fuori binario.
    Secondo me ci sono vari pro/contro nell'avere più campi Azienda, Cognome, Nome. Se hai 100 Clienti connotabili con il nome dell'Azienda e 100 connotabili con Cognome-Nome, rischi di avere una tabella con valori spostati qua e là con futuri problemi di indicizzazione/ordinamento ecc... Io ci vedrei un unico campo Cliente. Se si tratta di una RagioneSociale scrivi tale nome, se si tratta di una persona fisica, gli scrivi Cognome Nome.
    Quando crei una relazione nella finestra Relazioni, ricorda di mettere sempre il segno di spunta su "Applica integrità referenziale". Per le altre due opzioni è facoltativo, ma io lo consiglio ugualmente.
  • Re: Gestione preventivi e listini

    Grazie ai vostri contributi, spiego meglio alcuni aspetti che chiaro a me risultano famigliari ma a voi sicuramente no.
    ma consiglio di nominare le tabelle sempre al plurale e con nomi semplici: Clienti, Aree, Paesi, Tipi. I campi al singolare semplice IDArea, Area, IDTipo, Tipo...
    Ok grazie, prendo noto ed apporto le modifiche, domanda forse stupida ma te la faccio ugualmente, la distinzione plurarle per tabelle e singolare per i campi, incide poi sulle funzionalità del DB?
    Mi pare di capire che Area è una porzione geografica più piccola rispetto a Paese. Direi che è sufficiente avere solo IDArea in tabella Clienti.
    Per Area identifico più o meno il continente Europa - EXCIS - Middle East, questo mi serve per fare poi delle analisi sulle macro aree e non sulle singole nazioni.
    Che significa Tipo? Se è una caratteristica strettamente legata alla RagioneSociale, va bene un campo IDTipo in tabella Client
    I miei clienti possono essere Clienti Finali - Distributori in esclusiva - Tecnici - Assemblatori - Rivenditori per i quali avrò anche dei listini dedicati per la tipologia alla quale appartengono.
    Secondo me ci sono vari pro/contro nell'avere più campi Azienda, Cognome, Nome. Se hai 100 Clienti connotabili con il nome dell'Azienda e 100 connotabili con Cognome-Nome, rischi di avere una tabella con valori spostati qua e là con futuri problemi di indicizzazione/ordinamento ecc... Io ci vedrei un unico campo Cliente. Se si tratta di una RagioneSociale scrivi tale nome, se si tratta di una persona fisica, gli scrivi Cognome Nome.

    I clienti sono sempre Aziende quindi hanno una Ragione Sociale, ma solitamente posso avere diverse interlocutori all'interno della stessa azienda (sopratutto in aziende con ufficio acquisti) oppure l'offerta la invio ad un loro commerciale mentre il listino e l'ordine lo ricevo dall'ufficio acquisti.
    Quando crei una relazione nella finestra Relazioni, ricorda di mettere sempre il segno di spunta su "Applica integrità referenziale". Per le altre due opzioni è facoltativo, ma io lo consiglio ugualmente.
    Ok dovrei aver messo la spunta su questo, ma verifico.

    Grazie molte vi aggiorno con i progressi dati dai vostri interventi.
  • Re: Gestione preventivi e listini

    Ciao.

    Dunque ad occhio mi sembra che la struttura dovrebbe andare bene.

    Ora viene la parte più ostica.

    Per quanto riguarda Area e paese, che io intendo come nazione, penso che due distinzioni siano utili anche per il futuro.

    Non so se hai dei rappresentanti, ma di solito una stessa nazione viene coperta da più rappresentanti suddivisi per aree geografice o commerciali e di solito la stessa area potrebbe avere più rappresentanti in base al tipo di articolo, oppure due aree potrebbero essere coperte dallo stesso rappresentante, sempre in base all'articolo venduto, oppure addirittura a parità di articolo uguale potresti avere due o più rappresentanti che potrebbero accavallarsi tra di loro, oppure in un area un rappresentante vende il prodotto A e in un altra area vende il prodotto B

    A prima vista lo sviluppo di questo database potrebbe sembrare semplice, ma invece secondo me potrebbe essere abbastanza articolato e complesso.
    Bisogna vedere le esigenze che hai e come lo vuoi far funzionare.

    Quindi prima di gettarci sulla seconda parte, cioè quella dei listini e sulla terza parte cioè quella dei preventivi, prima di scrivere la struttura delle tabelle, devi avere bene in mente come lo vuoi far funzionare, sopratutto a livello di immissione dati, creazione dei listini e creazione dei preventivi.
    Cioè valutare tutte le possibili opzioni che avrai davanti una volta che lo utilizzerai.
    Perchè un conto è avere listini cartacei o fatti con excel dove usi carta e penna e calcolatrice, ed un conto è avere un database strutturato che lascia poco spazio alle personalizzazioni dell'ultimo minuto.
    Quindi se hai esigenze di uscire dai listini e proporre prezzi liberi e dettati da fattori che esulano dalla logica con cui crei i listini, dovremo prevederlo in anticipo.

    Detto questo, ci stavo pensando stanotte e sinceramente non ti nascondo che ad un certo punto mi è andato in palla il cervello, perchè pensando a come strutturare il tutto, ogni volta mi veniva in mente una possibile eccezione o imprevisto e quindi continuamente dovevo cambiare approccio al problema.

    Quindi per prima cosa immagina passo passo tutte le esigenze che hai e sopratutto tutte le possibili eccezioni che ti concedi quando fai un preventivo oppure presenti un listino prezzi ad un cliente.

    Da quello che ho capito:
    1- Per quanto riguarda i listini, immagino che ogni prodotto avrà 11 tipi di prezzo diverso in base al listino di appartenenza, più possibili varianti decise al momento.
    2- Immagino che avrai una logica basata su percentuali di sconto o di ricarico per creare ogni singolo listino.
    Cioè hai un listino base creato secondo i tuoi criteri e poi per creare i successivi applichi ad esempio il 20% su tutti i prodotti di quel listino.
    3- Immagino che non tutti gli articoli possano essere presenti in un listino, anche se appartenenti alla stessa categoria.
    4- I listini vengono presentati al cliente con tutti gli articoli che ne fanno parte, oppure fai un preventivo di volta in volta mettendo gli articoli che interessano al cliente e gli applichi il rispettivo listino?
    Se si, nel preventivo, potrebbe essere possibile che ad un articolo venga applicato un listino e ad un 'altro articolo venga applicato invece un'altro listino?

    Stanotte mi erano venute in mente altre eccezioni, ma comunque riconducevano tutte alle 3 o 4 soluzioni che mi sono venute in mente sul come far funzionare il tutto.
  • Re: Gestione preventivi e listini

    Comunque da quello che ho capito stiamo replicando il Northwind, ildatabase di esempio che ha in dotazione access.
    Dagli un'occhiata.

    Più ci penso e più sono convinto che è un lavoro complesso e bisognerà impegnarsi molto per avere un prodotto funzionante e funzionale.

    Ti faccio i complimenti in anticipo perchè è un lavoro da professionisti e se ci riesci risparmi un sacco di soldini. Non conosco i prezzi degli sviluppatori professionisti ma sicuramente per una cosa del genere ti presenterebbero una parcella abbastanza salata.
  • Re: Gestione preventivi e listini

    mypipe ha scritto:


    Comunque da quello che ho capito stiamo replicando il Northwind, ildatabase di esempio che ha in dotazione access.
    Dagli un'occhiata.
    Non mi pare proprio, visto le premesse iniziali.

    mypipe ha scritto:


    Più ci penso e più sono convinto che è un lavoro complesso e bisognerà impegnarsi molto per avere un prodotto funzionante e funzionale.
    Complesso non più di tanto, ma comunque è giustamente articolato, dato le esigenze richieste.

    mypipe ha scritto:


    Ti faccio i complimenti in anticipo perchè è un lavoro da professionisti e se ci riesci risparmi un sacco di soldini. Non conosco i prezzi degli sviluppatori professionisti ma sicuramente per una cosa del genere ti presenterebbero una parcella abbastanza salata.
    Quando ero sviluppatore in proprio (ora non più) prendevo 400,00€ + IVA + rimborso spese al giorno. Ma ho conosciuto sviluppatori che costavano anche fino 640,00€ al giorno (ma nelle 8 ore era incluso anche il viaggio).
    Però non mi riferisco ad applicazioni realizzate in MSAccess, parliamo di tutt'altri ambienti di sviluppo...

    marcolei ha scritto:


    La mia attività si svolge in varie aree geografiche italia\estero e i prezzi cmq sono sempre in euro ed esclusi IVA, la mia azienda opera con fornitore e subfornitore, i miei clienti sono rivenditori e produttori di macchinari ai quali a quest'ultimi vendiamo componenti che poi loro montano sulle loro macchine.
    Spiega in dettaglio la gestione delle AREE, perché se ho intuito bene non sembrerebbe molto articolata, ma se ho intuito male occorre sviscerarla bene.

    Se, e solo se, hai tuoi rappresentanti/agenti allora è determinante capire bene cosa intendi per area geografica, perché esistono anche aree che però sono delle entità astratte.
    Un esempio, riferendoci all'Italia:
    NORD EST, NORD OVEST, CENTRO NORD, CENTRO SUD, MERIDIONE, NORD (e chi più ne ha più ne metta) sono tutte aree geografiche astratte (ma un sistema dinamico deve anche dare la possibilità di creare di nuove).

  • Re: Gestione preventivi e listini

    Il mio lavoro è quello di Responsabile Commerciale e copro una vasta area del globo, il Db che sto cercando di realizzare ( vi cedo i diritti di divulgazione) mi deve servire alla mia gestione corrente dato che non sempre anzi quasi mai riesco a connettermi con il gestionale aziendale, inoltre dopo anni di attività vorrei avere un strumento che sia il mio scrigno del tesoro, e se un domani dovessi cambiare azienda invece di portarmi dietro i miei ormai scricchiolanti file excel mi porterei con me solo il db.

    Detto questo entriamo nel dettaglio del vostro aiuto.
    Zone o Area: queste sono vaste zone geografiche\continenti, EUROPA MERIDIONALE - MIDDLE EAST - EX CCCP, questa suddivisione mi serve per una visione della mia attività non sulle singole nazioni ma su macro aree.

    Northwind: ho dato un occhiata ma non ho trovato niente di quello che mi serve, per esempio non ho travato la gestione dei listini.

    Agenti non ho agenti per il momento e non credo che ne useremo, in ogni caso anche decidessi di averne in futuro sarebbe una gestione che lascerei al gestionale aziendale dato nel mio settore gli agenti sono solo di supporto e prendono un provvigione fissa solo sul fatturato espresso in una determinata area assegnata e gli ordini e trattative sono portate avanti dai responsabili commerciali, quindi son facili calcoli e non esistono enasarco etc.

    Con questo DB vorrei:
    1. Avere un archivio dei clienti attivi\non attivi cioè quelli a cui o mandato il listino o meno.
    2. sapere in una determinata area quali sono i clienti con determinata categoria di listino.
    3. recuperare velocemente quale listino ho inviato ad un cliente, quando lo inviato, e se dovessi avere un nuovo cliente nella stessa area inviargli un listino uguale o se diverso sapere subito da chi potrebbe avvenire una azione commerciale destabilizzante in quella zona.
    4. Avere uno storico delle offerte inviate, ed estrapolare quali sono ancora aperte, quali sono diventate ordine e quali sono perse o chiuse.
    In pratica uno strumento che mi eviti di aprire file excell con colonne e righe infinite
    In merito ai listini ed alle domande di MYpipe:
    Da quello che ho capito:
    1- Per quanto riguarda i listini, immagino che ogni prodotto avrà 11 tipi di prezzo diverso in base al listino di appartenenza, più possibili varianti decise al momento.
    2- Immagino che avrai una logica basata su percentuali di sconto o di ricarico per creare ogni singolo listino.
    Cioè hai un listino base creato secondo i tuoi criteri e poi per creare i successivi applichi ad esempio il 20% su tutti i prodotti di quel listino.
    3- Immagino che non tutti gli articoli possano essere presenti in un listino, anche se appartenenti alla stessa categoria.
    4- I listini vengono presentati al cliente con tutti gli articoli che ne fanno parte, oppure fai un preventivo di volta in volta mettendo gli articoli che interessano al cliente e gli applichi il rispettivo listino?
    Se si, nel preventivo, potrebbe essere possibile che ad un articolo venga applicato un listino e ad un 'altro articolo venga applicato invece un'altro listino
    1. Gli articoli sono 350 ed ogni articolo avrà il suo prezzo in base al listino di appartenenza, è anche possibile che alcuni prodotti possano avere un prezzo libero quindi non presente nei listini prestabiliti, quest'ultima è un eccezione.

    Per intenderci l'articolo PIPPO avrà come prezzo(nei vari listini) 10 - 15 - 20 - 25 - etc., il cliente che avesse PIPPO con listino il cui prezzo fosse 15 e per qualche ragione dovessi assegnargli un prezzo pari a 13 sarebbe una situazione temporanea e lo farei attraverso un offerta, alla successiva assegnazione di listino a quel cliente non creerei un nuovo listino ma al mantenersi delle condizioni per le quali il cliente ha chiesto un prezzo migliorativo lo sposterei nel listino con Pippo 10.

    2. la logica della creazione dei listini è la seguente:
    Io parto da un Listino con prezzo al pubblico da questo i listini vanno a scendere fino ad arrivare al listino base sotto il quale non posso scendere, il listino che ha in mano al cliente avrà un prezzo netto e il prezzo al pubblico, chiaro che i prezzi netti sono determinati in base a degli sconti a crescere sulla base dei volumi di acquisto stimati.
    Le percentuali di sconto sono differenti per famiglia di prodotto.

    3. Si ci sono clienti a quali invio un listino ridotto con solo una parte di prodotti, ma attualmente lo gestisco solo in fase di stampa
    4. la maggioranza dei clienti ricevono il listino completo, si posso verificare i seguenti casi:
    a. Cliente che è interessato solo ad alcune famiglie di prodotti, come detto sopra attualmente gli invio un pdf solo con i prodotti di suo interesse.
    b. nuovo cliente che mi fa richiesta di un prodotto specifico gli invio la parte di listino dedicata solo al quel gruppo di prodotti.
    c. cliente come i due precedenti casi solo che l'anno successivo o durante l'anno in corso invio il listino completo.
    Per questo classifico i listini, in modo che al cliente che ho inviato il listino1 per il prodotto PIPPO1 se mi richiederà l'invio del listino anche per gli altri prodotti evinco dal DB che il suo listino di riferimento è il LISTINO1 e quindi gli invierò l'integrazione al Listino1.
    Quello che non farò mai è mixare i listini cioè non invierò mai un listino composto dal mix dei vari listini con le famiglie prodotti dei vari listini ad esempio un listino composto dal prodotto PIPPO con i prezzi del Listino2, prodotto PINO con i prezzi del listino3 etc. etc.

    Ogni variazione del prezzo del listino assegnato per me è un offerta limitata nel tempo o per una specifica quantità, quindi ad esempio al cliente Marco è stato assegnato il listino 3, mi chiede un miglioramento del prezzo sul prodotto PIPPO che nel listino 3 e uguale a 15 euro, mi chiede un prezzo di 13 euro, valutata la fattibilità gli accordo il prezzo di 13 euro tramite offerta, il nuovo prezzo sarà condizionato ad un limite temporale ed una quantità specifica. Se poi l’anno successivo o durante l’anno in cui è in vigore il listino il cliente dovesse aumentare i quantitativi ordinati lo sposterei al listino con il prezzo di PIPPO più vicino a quello dell’offerta.
  • Re: Gestione preventivi e listini

    Ok.

    (Più o meno... intanto preparo corda e sapone e libro dei nodi scorsoi )

    A parte gli scherzi ora devo andare a cena e ti rispondo al volo.

    Prima proposta, poi vediamo se altri con maggiore esperienza della mia hanno soluzioni migliori, oppure tu hai soluzioni migliori

    Se avessimo a che fare con un cartaceo dovresti avere 11 listini stampati con tutti i prodotti ed i relativi prezzi.
    Si potrebbe fare una cosa anche con il DB, cioè ricreare tutti i listini con i relativi prezzi, ma ogni volta dovresti immettere a mano i prezzi per singolo articolo e avresti i dati ripetuti.

    Da quello che ho capito, possiamo creare un listino base e poi tutti gli altri listini farli creare direttamente al database?

    Cioè la creazione dei vari listini, sicuramente sarà fatta in base ad una logica ripetibile.

    del tipo
    articolo           listinobase   | listino 1  | listino 2   | listino 3
                                    |     -10%   |    -20%     |    +10%
    ---------------------------------------------------------------------------------
    Pere                    100     |   90        |    80         |  110
    mele                    200     |  180        |   160        |  220
    
    e così via.

    Se è applicabile una cosa del genere, la mia idea è quella di creare un listino base (o più listini base, esempio 2015/2016 etc etc cioè un archivio storico per anno) e poi quando devi mandare un listino ad un cliente, carichi il listino base ed applichi a questo listino base uno degli altri.
    Il database in fase di visualizzazione e di stampa applica le percentuali di sconto e di ricarico, senza archiviare o duplicare gli altri listini.

    ad esempio

    Cliente
    Anca sbilenca zona russia
    listino base 2015
    listino applicato Listino1
    sconto extra 1%
    ricarico 0%

    Il db applica il 10 percento di sconto a tutti i prodotti e ti li fa stampare.
    In questo modo potresti anche creare un listino specifico per ogni singolo cliente.

    Inoltre io metterei anche la possibilità di andare a modificare manualmente il prezzo del singolo articolo, oppure un ulteriore sconto extra da applicare a tutto il listino scelto.

    E' fattibile una cosa del genere?

    Attendo risposta anche dagli altri del forum.
  • Re: Gestione preventivi e listini

    marcolei ha scritto:


    Il mio lavoro è quello di Responsabile Commerciale e copro una vasta area del globo, il Db che sto cercando di realizzare ( vi cedo i diritti di divulgazione) mi deve servire alla mia gestione corrente dato che non sempre anzi quasi mai riesco a connettermi con il gestionale aziendale,
    Questo pone dei limiti, nel mantenere i dati aggiornati, dato che sicuramente lo strumento di riferimento in azienda è proprio il gestionale aziendale (anagrafiche, documenti, ecc.).

    marcolei ha scritto:


    inoltre dopo anni di attività vorrei avere un strumento che sia il mio scrigno del tesoro, e se un domani dovessi cambiare azienda invece di portarmi dietro i miei ormai scricchiolanti file excel mi porterei con me solo il db.
    Come ti capisco...
    Uno dei lavoro più frequenti che mi chiedevano le aziende era proprio quello di eliminare i file Excel!!!

    marcolei ha scritto:


    Detto questo entriamo nel dettaglio del vostro aiuto.
    Zone o Area: queste sono vaste zone geografiche\continenti, EUROPA MERIDIONALE - MIDDLE EAST - EX CCCP, questa suddivisione mi serve per una visione della mia attività non sulle singole nazioni ma su macro aree.
    OK, era quello che sospettavo.
    Realizzai per un azienda proprio un programma su questo tema, in cui l'azienda decideva quali macro-aree creare e quali sotto-aree creare ed assegnare relativamente alle prime (il tutto in modo dinamico e gerarchico, senza alcun limite di numero) poi quale erano le persone a gestite queste aree ovvero commerciali e/o agenti e/o rappresentanti (naturalmente anche questi in modo gerarchico e dinamico).

    Un Controllo di Gestione prevede anche di ottenere 'numeri' sui confronti tra Previsioni e Consuntivo, sia per quantità che per volume, sia numerici che percentuali e, cosa ancor più importante, il monitoraggio deve essere a ritmo costante, verificabile e valutabile anche dagli 'attori' in gioco.

    marcolei ha scritto:


    Northwind: ho dato un occhiata ma non ho trovato niente di quello che mi serve, per esempio non ho travato la gestione dei listini.
    Confermi quanto ho scritto.

    marcolei ha scritto:


    Agenti non ho agenti per il momento e non credo che ne useremo, in ogni caso anche decidessi di averne in futuro sarebbe una gestione che lascerei al gestionale aziendale dato nel mio settore gli agenti sono solo di supporto e prendono un provvigione fissa solo sul fatturato espresso in una determinata area assegnata e gli ordini e trattative sono portate avanti dai responsabili commerciali, quindi son facili calcoli e non esistono enasarco etc.
    OK, ma allora il Controllo di Gestione è a carico del gestionale aziendale? Se sì allora il discorso si chiude qui.

    marcolei ha scritto:


    Con questo DB vorrei:
    1. Avere un archivio dei clienti attivi\non attivi cioè quelli a cui o mandato il listino o meno.
    2. sapere in una determinata area quali sono i clienti con determinata categoria di listino.
    3. recuperare velocemente quale listino ho inviato ad un cliente, quando lo inviato, e se dovessi avere un nuovo cliente nella stessa area inviargli un listino uguale o se diverso sapere subito da chi potrebbe avvenire una azione commerciale destabilizzante in quella zona.
    4. Avere uno storico delle offerte inviate, ed estrapolare quali sono ancora aperte, quali sono diventate ordine e quali sono perse o chiuse.
    Queste sono fasi da attuarsi in un secondo momento.
    Però se devi farlo senza l'accesso al database del gestionale, la vedo dura.
    In fin dei conti, i dati sono tutti lì, basta 'leggerli' e magari integrarne con nuovi.

    marcolei ha scritto:


    In pratica uno strumento che mi eviti di aprire file excell con colonne e righe infinite
    So cosa intendi; soprattutto anche perché quando si vuole avere la situazione aggiornata si deve rifare tutto da capo!

    marcolei ha scritto:


    LISTINI
    Beh, dire che i listini non hanno grosse problematiche, se strutturati come si deve, ovvero:
    - possibilità di creare un numero illimitato di listini
    - possibilità di avere listini personalizzati (per cliente, per sconto quantità), ecc.
    - gestione dei listini con date di validità
    - ....
    poi per il resto è tutto nella norma (listino di costo, listino base, sconti, ultimo prezzo, ultima offerta, ecc...)

    Ad esempio, noi in azienda gestiamo i listini per: categorie, prodotto, valuta, nazione, cliente, listini personalizzati per cliente e/o per prodottoe per date di validità.
  • Re: Gestione preventivi e listini

    Ok allora cerco di rispondere sia a Mypipe che a Gibra.
    Allora prima di tutto di seguito potete vedere come sono strutturati gli sconti dei vari listini per tipologia di cliente e famiglia prodotto.
    famigliaprodotti_sconti.JPG
    famigliaprodotti_sconti.JPG

    In merito alla gestione con il Gestionale Aziendale e mantenere aggiornato i dati questo ahimè non avviene in quanto questo DB serve esclusivamente a mio uso per mio controllo, dato che il gestionale aziendale, per scelta non mia, viene aggiornato ed alimentato solo al momento dell'ordine, da quel momento il gestionale aziendale mi torna utile al fine di monitorare tutta la parte post ordine, fatturati budget, etc.

    Tutta la parte di scouting di mercati e primo contatto con ii clienti la devo gestire autonomamente con strumenti creati da me. per questo gestione di agenti e fatturati non mi servono in questo DB.

    Come da mio titolo del thread devo realizzarmi un DB di gestione Listini e archivio offerte.

    In merito alle aree la mia necessità per esempio è sapere che nell'area Europa Meridionale ho seguenti paesi con i seguenti tipologia di clienti che hanno questi listini o queste offerte ed hanno l'aggiornamento del listino o meno.
    Europa Meridionale:
    Spagna:
    1 cliente 1 listino aggiornato
    2 clienti con offerte attive
    1 cliente con offerta chiusa
    1 cliente con listino non aggiornato

    ripeto non ci sono agenti o altri commerciali a gestire o da gestire le aree di mio controllo.

    In merito ai listini come da immagine che ho postato è così suddivisa sicuramente la possibilità di poter gestire prezzi speciali è necessaria.
    La situazione proposta da Mypipe è corretta anche se non vorrei avere troppi listini personalizzati piuttosto vorrei normalizzare la situazione che attualmente abbiamo in essere dove ogni cliente ha il suo sconto, nella situazione attuale con una galassia di sconti e listini speciali il backoffice commerciale non lavora come dovrebbe.
  • Re: Gestione preventivi e listini

    Hm... no.

    Invece, dopo aver visto la tua tabella, ho l'impressione che il mio approccio sia sbagliato.

    Io sono partito dal presupposto che la percentuale di un listino si applicasse in egual misura a TUTTI gli articoli che facevano capo a quel listino, invece dalla tabella che hai postato, il prezzo di ogni articolo sembra avere percentuali di sconto (o di prezzo finale) diverso.

    Mi sfugge la logica della creazione del prezzo del singolo articolo nel listino specifico.

    Se la creazione del prezzo varia in base a criteri esterni, personali o che comunque variano di volta in volta per il singolo articolo, almeno io non vedo altra soluzione che ripetere per ogni singolo listino l'immissione di tutti gli articoli con il relativo prezzo, quindi il mio approccio di evitare di ripetere gli articoli per ogni listino, grazie al fatto di avere un solo listino base su cui poi calcolare tutti i listini semplicemente mettendo lo sconto da applicare a tutti gli articoli, risulta sbagliata.

    Aspetto altre opzioni di risoluzione da altri utenti che sicuramente io, ora, non vedo.
  • Re: Gestione preventivi e listini

    marcolei ha scritto:


    Ok allora cerco di rispondere sia a Mypipe che a Gibra.
    Allora prima di tutto di seguito potete vedere come sono strutturati gli sconti dei vari listini per tipologia di cliente e famiglia prodotto
    Stai parlando di sconti sui 'vari' listini.
    Non ci siamo.
    I listini sono una cosa, Gli sconti un'altra.

    Descrivi la tua tabella, nei dettagli, perché per me non è comprensibile in modo esaustivo.
    O per meglio dire, potrebbe esserlo, ma occorre essere chiari, per evitare di trovarsi poi ad aver frainteso.

    Ad esempio, potrei pensare che quelle percentuali sono la differenza (o l'aumento) rispetto ad un prezzo di costo. Se così fosse non parla di sconti, ma di percentuali (appunto).
    Non si può nemmeno definirli 'listini scontati del x%' (come avviene nel gergo comune) perché le % all'interno della stessa colonna (listino?) variano da articolo ad articolo.
  • Re: Gestione preventivi e listini

    La tabella pubblicata nel precedente post indica gli sconti sui quali calcoliamo il prezzo netto per le varie categorie di clienti e famiglie prodotto.

    Ai nostri clienti non indichiamo mai la percentuale di sconto che gli viene assegnata ma indichiamo sempre un prezzo netto a lui dedicato.

    il prezzo netto lo calcoliamo partendo da un prezzo consigliato di vendita al pubblico.
    vi metto una immagine di alcune righe di listino. quindi io posso caricare anche direttamente i prezzi senza aver bisogno di indicare nessuna percentuale, se non quella in caso di extra sconto in un offerta, inoltre nella trattativa con il cliente noi parliamo sempre di prezzo netto.

    Un esempio il cliente Gianni vuole comprare il nostro prodotto IRIS V, la nostra prima domanda è quale e il volume di vendita che prevede di avere per questo prodotto.
    Risposta di Gianni: alcuni pezzi da 1 a 3 circa.
    Il suo prezzo di acquisto che noi gli daremo sarà 4.333 euro contro un prezzo di vendita consigliato al pubblico di 6.190.

    Risposta di Gianni: 10 pezzi
    Il suo prezzo di acquisto che noi gli daremo sarà 3.700 euro contro un prezzo di vendita consigliato al pubblico di 6.190.

    e cosi via.

    Dite che sarà difficile anche così la gestione?
Devi accedere o registrarti per scrivere nel forum
22 risposte