Gestione documenti di acquisto

di il
50 risposte

50 Risposte - Pagina 3

  • Re: Gestione documenti di acquisto

    È vero, riuscire ad entrare nella logica di una azienda per trovare soluzioni idonee è difficile, però se si deve dare un consiglio bisognerebbe quantomeno attenersi alle specifiche richieste concentrandosi sul problema di dettaglio. Io sono stato sicuramente prolisso e a volte impreciso, ma credo di avere esplicato quello di cui ho bisogno, per cui:
    1) non ho mai parlato di gestione carichi scarichi di magazzino anche perché non abbiamo magazzino....
    2) acquistiamo a commessa per cui tutto quello che entra, viene lavorato e/o assemblato per poi essere rivenduto al cliente.
    3) non ho mai parlato di tabella prodotti ne per quelli di vendita (tutto ciò che facciamo è univoco e prototipale, non facciamo prodotti "di serie"), né per quelli di acquisto (ci sono oltre 10.000 potenziali voci solo per i normalizzati), voglio ridere a creare anagrafiche, inserire i carichi, gli scarichi i prezzi di listino che cambiano più volte all'anno....ci vogliono 10 persone... Noi siamo una realtà di 13 persone in tutto....di cui solo due in ufficio a seguire la parte amministrativa, produttiva e commerciale.
    La mia richiesta verteva su come poter gestire gli acquisti a commessa in modo da avere sempre sotto controllo, per commessa, ciò che deve essere consegnato da cio' che è già arrivato ed i relativi costi collegati.
  • Re: Gestione documenti di acquisto

    Mailman ha scritto:


    È vero, riuscire ad entrare nella logica di una azienda per trovare soluzioni idonee è difficile, però se si deve dare un consiglio bisognerebbe quantomeno attenersi alle specifiche richieste concentrandosi sul problema di dettaglio. Io sono stato sicuramente prolisso e a volte impreciso, ma credo di avere esplicato quello di cui ho bisogno, per cui:
    1) non ho mai parlato di gestione carichi scarichi di magazzino anche perché non abbiamo magazzino....
    2) acquistiamo a commessa per cui tutto quello che entra, viene lavorato e/o assemblato per poi essere rivenduto al cliente.
    3) non ho mai parlato di tabella prodotti ne per quelli di vendita (tutto ciò che facciamo è univoco e prototipale, non facciamo prodotti "di serie"), né per quelli di acquisto (ci sono oltre 10.000 potenziali voci solo per i normalizzati), voglio ridere a creare anagrafiche, inserire i carichi, gli scarichi i prezzi di listino che cambiano più volte all'anno....ci vogliono 10 persone... Noi siamo una realtà di 13 persone in tutto....di cui solo due in ufficio a seguire la parte amministrativa, produttiva e commerciale.
    La mia richiesta verteva su come poter gestire gli acquisti a commessa in modo da avere sempre sotto controllo, per commessa, ciò che deve essere consegnato da cio' che è già arrivato ed i relativi costi collegati.
    Capisco perfettamente quello che vorresti realizzare.
    Lavoro in un ambito dove si fanno circa 2000 modelli di campionario ogni anno, con prodotti composti da centinaia di materiali, colori e forme e dimensioni diverse e con diversi fornitori per ogni singolo materiale. E poi c'è naturalmente la produzione del campionario venduto, con circa un milione di pezzi, realizzati solitamente con materiale che proviene da fornitori diversi da quelli del campionario.
    Prodotti che a volte sono prodotti interamente a mano, ed a volte in modalità industriale, molte volte personalizzati.
    Nella realizzazione del tuo database, stai dimenticando una cosa importante.
    Ogni operazione che tu fai in modo manuale, oppure semplicemente a memoria, oppure che lo segni su un post it, o lo dici a voce all'operaio, nel database, devi avere la relativa replica, altrimenti è più efficiente segnare le commesse su un quaderno.
    Capisco che non hai magazzino fisico, ma in realtà, nel momento in cui entra un materiale in azienda, automaticamente hai un carico di magazzino. Stesso discorso per l'aspetto commerciale.
    Quando arriva una commessa sicuramente la segretaria ti porta a mano la commessa. Tu alzi il telefono, chiami i fornitori, che poi ti invieranno un preventivo dei materiali che vuoi acquistare. Da questi preventivi, poi sceglierai i fornitori, che possono essere diversi per lo stesso materiale.
    In una struttura aziendale di qualsiasi dimensione, queste operazioni in realtà, sono presa in carico della commessa da parte dell'ufficio commerciale, passaggio all'ufficio acquisti, richiesta di preventivi, ricezione delle offerte di vendita, ordine di acquisto.
    Quando arriva il materiale hai un carico di magazzino, quando lo mandi in produzione, hai uno scarico di magazzino ed automaticamente un carico sulla linea di produzione.
    Quando finisci il prodotto, hai uno scarico dalla linea di produzione ed automaticamente hai un carico di magazzino prodotti.
    Tracciando ed archiviando questi dati è l'unico modo in cui puoi controllare da quale fornitore hai acquistato la materia base e per quale prodotto sono state usate. Così poi da poter anche imputare i costi di produzione e di vendita.
    Scommetto che ora, quando leggi un riferimento ad un ordine sul video, sottomano hai il cartaceo, dal quale vedi il materiale che hai ordinato, poi ricontrolli a chi l'hai ordinato, prendi il cartaceo dell'ordine e da li ricontrolli che il materiale ti sia arrivato. Poi prendi la calcolatrice, carta e penna e fai i relativi calcoli.
    Ora naturalmente tutti questi passaggi li fai a voce, o a memoria, quindi ricordi che hai acquistato della sabbia per produrre un bicchiere per quel negozio.
    Con un database non puoi ragionare in questo modo. Devi avere una replica nel database degli ordini e dei materiali che hai ordinato, dal quale andrai a immettere le quantità arrivate, così che il database ti faccia tutti i calcoli per verificare se è tutto a posto. Con un semplice click.
    Se non crei una situazione del genere come detto è più agevole usare carta e penna, oppure excel.
  • Re: Gestione documenti di acquisto

  • Re: Gestione documenti di acquisto

    Forse se alleghi un'immagine della finestra delle relazioni si riesce a capire meglio quale è l'attuale impostazione della struttura del database e quindi darti eventuali consigli.
  • Re: Gestione documenti di acquisto

    Stifone ha scritto:


    Forse se alleghi un'immagine della finestra delle relazioni si riesce a capire meglio quale è l'attuale impostazione della struttura del database e quindi darti eventuali consigli.
    Appena lo completo lo posto
  • Re: Gestione documenti di acquisto

    Mailman ha scritto:


    Grazie fratac, hai descritto abbastanza bene la realtà, ti confesso che mi piacerebbe gestire il carico e scarico di magazzino, per cui mi tengo sicuramente "la porta aperta" nella nuova impostazione del DB. In questa prima fase però non ho né il tempo né le risorse per implementarlo. Considera che sto "cambiando le ali all'aereo mentre sono in volo".
    Nel nostro settore la flessibilità e la rapidità di risposta al Cliente è ancora una caratteristica premiante: formalizzare eccessivamente certi passaggi (e il DB lo esige...) potrebbe comportare problemi e noi non siamo al momento strutturati per questo, soprattutto con le maestranze... Ma con un passo alla volta, probabilmente ci arrivero'. Importante è strutturare il tutto per l'implementazione.
    Grazie ancora e a presto con altri thread
    Vi aggiorno a lavoro impostato Infatti quello che dico, non è di creare tutto e subito, ma avere le idee chiare su quello che vorresti realizzare e di creare almeno le tabelle e la struttura "completa" che vorresti realizzare. Una volta che tutto è in relazione nel modo giusto, poi piano piano, implementerai, aggiungendo campi e funzioni.
    Ma un conto è aggiungere funzioni su un database, dove già ad ogni record immesso, hai i riferimenti id presenti nelle tabelle, ed un conto è aggiungere delle parti con un database già popolato.
    Nel primo caso, ti basterà aggiungere campi alla tabella, ed il lavoro grosso sarà solo quello di riempire i campi con i dati giusti.

    Nel secondo caso invece dovresti rimettere mano integralmante al database, con l'aggiunta del fatto che i record presenti non sono collegati con le aggiunte. E con il pericolo di creare un carrozzone pieno di toppe per risolvere determinate situazioni.
    Un po come facevano i nostri genitori, che ogni volta che potevano costruire qualche metro quadro di casa, lo costruivano, ritrovandosi poi abitazioni scollegate tra di loro, ambienti poco funzionali ed inguardabili.
    Inoltre, per esperienza, ti dico che una volta che avrai terminato il lavoro, dovrai continuare a lavorare almeno per un anno, usando il sistema vecchio e quello nuovo, per evitare errori.
    E lo schema che hai presentato, praticamente non rispecchia quello che vorresti realizzare nel futuro.

    Ritornando al discorso della struttura, ora il tuo pensiero gira intorno ai numeri delle commesse e delle fatture.
    In realtà, come già detto, questi dati, sono i riferimenti.

    Tutto gira intorno al pezzo che devi realizzare.

    Quindi (secondo me e potrei sbagliarmi) il vero elemento principale e dove tutto ruota, è il pezzo che devi produrre.
    Partendo dal pezzo che devi produrre, devi individuare gli elementi che saranno sempre presenti, e basandomi su quello che hai scritto ad esempio, il materiale, i fornitori, la produzione ed il cliente finale. (ed altri che a me sfuggono, ma che tu conosci)
    Questi a mio avviso dovrebbero essere gli elementi collegati con relazioni dirette tra di loro perchè sono imprescindibili nella realizzazione del pezzo. Se ne manca uno, il pezzo non esisterebbe.

    Tutto il resto devono essere riferimenti, perchè da come dici, preventivi e bolle, a volte mancano.

    Per quanto riguarda la formalizzazione aziendale, in realtà non cambierà niente. Non dovrai creare nulla di fisico, ne magazzini, ne nuove procedure. Sarà solo un'altro modo per fare quello che già fai, ma in modo misto.
    L'unica differenza sarà che invece di controllare continuamente il cartaceo, lo controllerai a video.
    L'unico passaggio in più, sarà quello di riscrivere i dati delle commesse nel database, con la conseguenza però, che poi con una semplice schermata, vedrai morte e miracoli di un determinato pezzo prodotto, il suo stato di avanzamento ed il suo costo, in tempo reale, con un semplice click.
    Inoltre, quando avrai inserito nel database, le materie prime ed il prezzo e le ore necessarie, potrai sviluppare un sistema che ti permetta di fare un preventivo, semplicemente selezionando gli elementi necessari.

    In realtà, anche a livello base, di quello che vuoi realizzare, viene un lavoro abbastanza complesso, infatti, al dilà della struttura e delle relazioni, poi c'è molto da fare a livello di query e visualizzazione dei dati.
    Quindi, entrano in gioco anche le tue effettive competenze e conoscenze di access.

    Personalmente anni fa creai per divertimento un database per la gestione della mia casa in campagna, dove ho animali e terreni coltivati e che uso per avere traccia dei vari fornitori di prodotti agricoli, becchime e materiale da costruzione e riparazione, e con il quale faccio anche dei preventivi, quando ad esempio devo costruire nuove gabbie e pollai, confrontando i prezzi dei vari articoli, tra i vari rivenditori.
    La struttura è molto simile a quella che ti occorre.
    Ti posto lo schema delle relazioni a titolo informativo.



  • Re: Gestione documenti di acquisto

    Buongiorno,
    rileggendo i post di fratac ho trovato il tassello mancante che non riuscivo a vedere (eppure era lampante...). Ho sempre considerato come "ordine" la conferma d'ordine chi mi inviano i fornitori. Quello che non consideravo era invece il mio ordine che, come giustamente mi faceva notare fratac, non viene gestito perché spesso e' fatto telefonicamente, o con email (chi stampa le proprie emails??) o spesso con acquisto diretto dal rivenditore.

    Per cui penso che farò:
    tblmioordine con:
    IDordine (PK),
    Commessa (FK) da tblanagraficacommesse
    IDtipoordine (FK) es.email, telefono, acquisto diretto, ecc.
    Dataordine
    IDdettagli (FK) da implementare con la gestione delle righe d'ordine
    IDfornitore (FK) da tblanagraficafornitori

    In relazione 1 a N con tblordinato con i campi:
    IDordinato (PK)
    IDmioordine (FK) da tblmioordine
    IDofferta (FK) da tblofferte
    IDconfermaordine (FK) da tblconfermaordini
    Importoordinato (per ora mi limito ad inserirlo manualmente poi, quando avro' implementato la gestione delle righe d'ordine, diventera' un campo calcolato)

    e 1 a N con tblconsegnato con i campi:
    IDconsegnato (PK)
    IDmioordine (FK) da tblmioordine
    IDddt (FK) da tblDDTfornitore
    IDfattura (FK) da tblfatturefornitore
    Importoconsegnato (per ora mi limito ad inserirlo manualmente poi, quando avro' implementato la gestione delle righe d'ordine, diventera' un campo calcolato)

    I nomi poi li perfeziono...
    Con questa configurazione potrei forse utilizzare il suggerimento di Osvaldo della tabella unica per documenti dei fornitori con un campo che discrimina il tipo di documento.
    Ci ragiono ancora un po'...
  • Re: Gestione documenti di acquisto

    Ciao.
    Piano piano si costruiscono le città.
    Anche se nel tuo caso non indispensabile, visto che lavori su pezzi unici, se crei un codice articolo parlante da dare ad ogni prototipo, secondo me ti si semplificano le cose, potresti creare un catalogo con le foto e le specifiche da presentare ai clienti e gli operai in fase di lavorazione, saprebbero immediatamente a cosa ti riferisci e sopratutto se dopo anni, ti richiedono lo stesso pezzo o pezzi simili, invece di andare a memoria, potresti trovarlo agevolmente.
  • Re: Gestione documenti di acquisto

    Sto procedendo nella realizzazione delle varie tabelle e mi trovo con questi interrogativi:
    tbldocumentifornitori
    IDdocumento (PK)
    Numerodocumento
    Datadocumento
    IDTipodocumento (FK da tbltipidocumento)
    IDfattura (FK di tblDocumentifornitori)

    tblordini
    IDordine (PK)
    Numeroordine
    Dataordine
    IDfornitore (FK da tblanagrafichefornitori)
    IDofferta (FK da tblDocumentifornitori)
    IDordine (FK da tblDocumentifornitori)

    Il primo quesito e' se ci sono problemi ad inserire una FK che fa riferimento alla stessa tabella. Spiego la necessita': quando inserisco una fattura in tabella, vorrei associare il suo IDdocumento al campo IDfattura dei soli records relativi ai DDT (in modo da collegare la fattura con i rispettivi DDT). Nella form di inserimento renderei poi questo controllo visibile solo quando il tipo documento e' DDT.
    Il secondo quesito riguarda la seconda tabella in cui ci sono i due campi FK IDofferta e IDordine che fanno riferimento entrambi alla PK della tbldocumentifornitori. Nelle relazioni ho collegato il campo IDofferta con IDdocumento con un inner join (1-N) e integrita' referenziale, quando eseguo anche il secondo inner join mi trovo con un duplicato della prima tabella.
    E' normale o ho fatto qualcosa di errato?
  • Re: Gestione documenti di acquisto

    Hm.... scusa il francesismo, ma.... non c ho capito una fava.
    A parte il fatto che mi sto confondendo con tutti i campi documento diversi tra di loro, che sicuramente per te sono chiarissimi e quindi va bene, però ho l impressione che stai creando tabelle che gestiscono le stesse cose, per inserire campi o valori che potrebbero essere aggiunti a tabelle già esistenti. Se per te non è un problema,p otresti postare lo schema delle tabelle e delle relazioni?

    Inoltre ho l impressione che molte delle cose che vorresti realizzare, si potrebbero fare costruendo una maschera ben strutturata.
    Hai sempre postato maschere in visualizzazione tabellare.
    Usi solo la visualizzazione tabellare, oppure posti le immagini per cercare di farci capire meglio?
    Perché se usi solo la visualizzazione tabellare, oltre che scomoda da usare, questa ti impedisce di fare molte cose, come gestire contemporaneamente le modifiche su un numero infinito di tabelle.
  • Re: Gestione documenti di acquisto

    Scusa fratac, colpa mia che non ho ancora le idee completamente chiare. Ho cambiato impostazione rispetto a quanto volevo fare nei post precedenti. Ho deciso di rifare tutto da zero anche seguendo quanto da te suggerito che sicuramente dovrò viaggiare in parallelo con vecchio e nuovo db. Per cui, facendo tesoro dei vostri consigli, stavo impostando il db (per ora solo la parte verso i fornitori) in questo modo:
    una tabella per gli ordini che invio ai fornitori associata ad una tabella di dettaglio con le righe d'ordine, a sua volta collegata alla tabella dei documenti dei fornitori (siano le offerte che ricevo, le conferme d'ordine, le bolle e le fatture).
    Quindi nel mio post precedente, volevo collegare il mio ordine con l'offerta e/o la conferma d'ordine del fornitore salvando il loro id nella tabella ordini. In questo modo, per es., dal mio ordine posso facilmente risalire all'offerta del fornitore
  • Re: Gestione documenti di acquisto

    Allego immagine relazioni, alcuni campi sono purtroppo di difficile comprensione (come ho gia' scritto in altri post, utilizzo un metodo particolare di codifica...); ho evidenziato i due campi FK che fanno riferimento alla stessa PK. Probabilmente se avessi utilizzato tabelle diverse, una per le offerte fornitori, una per le conferme d'ordine fornitori, una per le bolle fornitori ed una per le fatture fornitori, probabilmente non avrei avuto questi dubbi...

  • Re: Gestione documenti di acquisto

    Di seguito allego anche un esempio d'ordine che inviamo attualmente ai fornitori di componenti normalizzati; e' di fatto una distinta base che il nostro programma di progettazione CAD espone al completamento del progetto: io volevo replicarne i dati per averlo all'interno del DB (tabella tblDOdettaglioordine).

  • Re: Gestione documenti di acquisto

    Dunque.
    Per analizzare a fondo la struttura serve tempo, quindi riporto ad occhio le imprecisioni più grossolane, sempre naturalmente a mio avviso.
    La prima è che sicuramente l'introduzione della stessa tabella ripetuta due volte è un errore, sia a livello di struttura che di ragionamento.
    la seconda è che secondo me il tipo di documento non dovrebbe avere relazioni dirette con le altre tabelle, ma solo come fonte dati per popolare le combobox e che la relazione per collegare ordinistamp, dovrebbe essere diretta con documenti fornitori.

    Invece sto ragionando sul fatto che dici che dovresti usare tabelle diverse per ordini, conferme d'ordine etc etc.
    Effettivamente dovrebbe essere così. Ognuna di queste è un elemento distinto che ha una vita propria, naturalmente collegata per riferimento o con relazione diretta, da cui vai a prendere i dati che ti occorrono per popolare altre tabelle.
    Però, secondo me si deve considerare il soggetto che genera questi documenti e di dividerli di conseguenza.
    Mi spiego. La richiesta di preventivo, la generi tu, quindi è un documento della tua azienda. L'azienda fornitrice ti invia un preventivo in risposta, ed è un documento esterno di terze parti.
    Tu valuti il preventivo, e generi la conferma d'ordine.
    Per come è strutturato il tutto, al momento mi sembra che l'accettazione del preventivo è per tutto quello che contiene.
    Che cosa accade se da questo preventivo accetti una parte dei materiali e gli altri li acquisti da un altro fornitore perchè più convenienti?
    Non hai modo di discriminare ne i prodotti, i preventivi ed i fornitori.
    Quindi a mio avviso dovresti avere una tabella dei tuoi ordini, dove inserisci il materiale ordinato, con il riferimento ai preventivi che hai accettato.
    Questa però è una mia riflessione fatta in fretta, quindi da valutare.

    Per quanto riguarda la seconda immagine. Non ho capito bene.
    E' quella che hai creato tu? oppure è quella del CAD?
    Perchè dalla tipologia dei dati che vedo, è una maschera generata con al massimo 3 tabelle dati come fonte dati. (forse anche 2)
  • Re: Gestione documenti di acquisto

    Aggiungo una cosa che mi ero dimenticato .
    Ho l impressione che tu stia cercando di ottenere il risultato finale usando la struttura.
    Se cosi fosse, bob è l approccio giusto.
    La struttura serve solo per dividere ed archiviare i dati grezzi in modo ordinato ed in base alla tipologia di appartenenza. Tutto il testo, cioè, visualizzazione e manipolazioni, si fanno con le query e creando maschere che ti permettono di visualizzare e modificare i dati in base alle tue esigenze.
    Paradossalmente, volendo, in un database le relazioni potrebbero anche non essere presenti, ma create virtualmente di volta in volta dal programmatore, in base all esigenza del momento e tramite query e maschere apposite.
    L importante è avere tra le tabelle campi in comune a cui far riferimento.
Devi accedere o registrarti per scrivere nel forum
50 risposte