Gestione documenti di acquisto

di
Mailman
il
50 risposte
M
Mailman
Utente Attivo
Iscritto da
mag, 2022
Messaggi:
244

Gestione documenti di acquisto

Buongiorno,
premessa: spero con questo thread di avere rispettato i criteri del forum.
ritorno a voi con una ulteriore richiesta di consiglio/aiuto. Sto riprogettando una parte di un database che gestisce gli acquisti di materiale e le prestazioni esterne della mia ditta. Il contesto e' questo: ogni attivita' di lavoro in officina e' gestita da una commessa (numero univoco incrementale), la commessa potrebbe richiedere l'acquisto di materiale o l'esecuzione di lavorazioni esterne all'azienda. I fornitori possono inviare un'offerta e/o un ordine a cui puo' seguire la bolla di consegna e sicuramente una fattura. Non sempre pero' ci sono tutti i documenti (ad eccezione della fattura), estremizzando potrebbe arrivare solo questa (a seguito magari di un contatto telefonico o email). Inoltre i documenti potrebbero essere collegati a piu' commesse oppure un ordine potrebbe essere evaso da piu' DDT perche' la merce arriva in piu' tranches, per cui le relazioni tra le singole tabelle (TblCommesse, tblOfferte, TblOrdini, TblDDT e TblFatture) sono di tipo N-M (unica eccezione TblFattura e TblDDT 1-N).
Ho quindi creato una serie di ulteriori tabelle per avere tutti i documenti collegati fra loro con relazioni 1-N. Siccome ho bisogno di tenere monitorato in tempo reale la situazione delle singole commesse con gli importi di offerte/ordini per il materiale da ricevere e DDT/fatture per il materiale ricevuto, chiedo un Vostro consiglio su come strutturereste le tabelle. Io stavo pensando ad una tabella per il materiale da ricevere in cui inserisco Commessa-IDofferta-IDordine-Importo da ricevere ed un'altra con Commessa-IDddt-IDfattura-Importo ricevuto. Pero' non mi convince molto perche' mi troverei con valori vuoti in entrambe le tabelle: per es. nel caso di ordini senza offerte o fatture senza DDT.
Voi come la vedete?
Grazie in anticipo

50 Risposte

  • O
    OsvaldoLaviosa
    Super Famoso
    Iscritto da
    apr, 2012
    Messaggi:
    7493

    Re: Gestione documenti di acquisto

    Mailman ha scritto:

    relazioni tra le singole tabelle (TblCommesse, tblOfferte, TblOrdini, TblDDT e TblFatture) sono di tipo N-M (unica eccezione TblFattura e TblDDT 1-N).
    Puoi esplicitare tutti i campi (almeno quelli più significativi) di queste tabelle? Puoi indicare le relazioni con i nomi propri di PK e FK?
  • M
    Mailman
    Utente Attivo
    Iscritto da
    mag, 2022
    Messaggi:
    244

    Re: Gestione documenti di acquisto

    Provo a dettagliare campi e tabelle, tutti i nomi sono esempi per rendere l'idea:
    TblCommesse: Commessa (PK, Long), altri campi non influiscono
    TblOfferte: IDofferta (PK, Long), IDfornitore (FK, Long), Offerta (String), Dataofferta (Date), Importo (Currency)
    TblOrdini: IDordine (PK, Long), IDfornitore (FK, Long), Ordine (String), Dataofferta (Date), Importo (Currency)
    TblDdt: IDddt (PK, Long), IDfornitore (FK, Long), DDT (String), Dataofferta (Date), IDfattura (FK, Long)
    TblFatture: IDfattura (PK, Long), IDfornitore (FK, Long), Fattura (String), Dataofferta (Date), Importo (Currency)

    Poi ho messo in relazione ogni tabella con le altre per evitare di perdere il tracciamento di tutti i documenti, quindi:
    TblOfferta-ordine: IDoffertaordine (PK, Double), IDofferta (FK), IDordine (FK)
    TblOfferta-ddt: IDoffertaddt (PK, Double), IDofferta (FK), IDddt (FK)
    TblOfferta-fattura: IDoffertafattura (PK, Double), IDofferta (FK), IDfattura (FK)
    TblOrdine-DDT: IDordineddt (PK, Double), IDordine (FK), IDddt (FK)
    TblOrdine-fattura: IDordinefattura (PK, Double), IDordine (FK), IDfattura (FK)

    Infine stavo definendo le relazioni con la commessa e avevo pensato a queste due tabelle:
    TblCommessa-offerta-ordine: IDcommessaoffertaordine (PK, Double), Commessa (FK), IDofferta (FK), IDordine (FK), Importodaricevere (Currency)

    TblCommessa-ddt-fattura: IDcommessaddtfattura (PK, Double), Commessa (FK), IDddt (FK), IDfattura (FK), Importoricevuto (Currency)

    Troppo farraginoso??
    Come dicevo sopra, questa soluzione comporta possibili valori vuoti in queste due ultime tabelle perche' potrei avere nella prima tabella IDofferta senza IDordine o viceversa e nella seconda tabella IDfattura senza IDddt. Inoltre dovrei correggere ogni volta l'importo da ricevere in base agli arrivi di merce.
    Pero' non riesco a trovare una strada migliore...
  • O
    OsvaldoLaviosa
    Super Famoso
    Iscritto da
    apr, 2012
    Messaggi:
    7493

    Re: Gestione documenti di acquisto

    Mailman ha scritto:

    TblOfferte: IDofferta (PK, Long), IDfornitore (FK, Long), Offerta (String), Dataofferta (Date), Importo (Currency)
    TblOrdini: IDordine (PK, Long), IDfornitore (FK, Long), Ordine (String), Dataofferta (Date), Importo (Currency)
    TblDdt: IDddt (PK, Long), IDfornitore (FK, Long), DDT (String), Dataofferta (Date), IDfattura (FK, Long)
    TblFatture: IDfattura (PK, Long), IDfornitore (FK, Long), Fattura (String), Dataofferta (Date), Importo (Currency)
    Queste 4 tabelle hanno sostanzialmente gli stessi campi. Ti basta una sola tabella Movimenti con l'aggiunta di un campo di discriminazione TipoMovimento.
  • M
    Mailman
    Utente Attivo
    Iscritto da
    mag, 2022
    Messaggi:
    244

    Re: Gestione documenti di acquisto

    OsvaldoLaviosa ha scritto:

    Queste 4 tabelle hanno sostanzialmente gli stessi campi. Ti basta una sola tabella Movimenti con l'aggiunta di un campo di discriminazione TipoMovimento.
    In questo modo pero' perdo il concatenamento dei documenti: devo sempre risalire dall'offerta al DDT all'ordine ed eventualmente all'offerta e, molto spesso, questi riferimenti non vengono riportati nei documenti.
  • M
    Mailman
    Utente Attivo
    Iscritto da
    mag, 2022
    Messaggi:
    244

    Re: Gestione documenti di acquisto

    Aggiungo a quanto descritto precedentemente le varie relazioni:
    TblCommesse:
    1-N con TblOfferte
    1-N con TblOrdini
    1-N con TblDDT
    1-N con TblFatture

    TblOfferte:
    1-N con TblCommesse
    1-N con TblOrdini
    1-N con TblDdt
    1-N con TblFatture

    TblOrdini:
    1-N con TblCommesse
    1-N con TblOfferte
    1-N con TblDdt
    1-N con TblFatture

    TblDdt:
    1-N con TblCommesse
    1-N con TblOfferte
    1-N con TblOrdini
    1-1 con TblFatture

    TblFatture:
    1-N con TblCommesse
    1-N con TblOfferte
    1-N con TblOrdini
    1-N con TblDDT

    edit
    scusate ho modificato le relazioni...
  • fratac
    fratac
    Molto attivo
    Iscritto da
    lug, 2022
    Messaggi:
    707

    Re: Gestione documenti di acquisto

    Hm....
    In realtà dovresti gestire tutto applicando un tuo codice di protocollo con il quale cataloghi ed archivi i documenti e non basarti sui codici dei documenti esterni, altrimenti non ci cavi più i piedi. Con un tuo codice di protocollo avresti solo un id da gestire. Tutto il resto sarebbe solo dati archiviati.
    Inoltre secondo me hai dimenticato la parte piu importante.
    Non vedo nessun riferimento alle aziende, o ai fornitori o ai clienti.
    Va bene archiviare tutto quello che hai postato, ma di solito ci si basa sul nome del cliente o del fornitore per gestire i documenti.
  • O
    OsvaldoLaviosa
    Super Famoso
    Iscritto da
    apr, 2012
    Messaggi:
    7493

    Re: Gestione documenti di acquisto

    Mailman ha scritto:

    OsvaldoLaviosa ha scritto:

    Queste 4 tabelle hanno sostanzialmente gli stessi campi. Ti basta una sola tabella Movimenti con l'aggiunta di un campo di discriminazione TipoMovimento.
    In questo modo pero' perdo il concatenamento dei documenti: devo sempre risalire dall'offerta al DDT all'ordine ed eventualmente all'offerta e, molto spesso, questi riferimenti non vengono riportati nei documenti.
    Da quello che ho capito io, tutto fa capo alla tabella Commesse. La tabella Movimenti è figlia di Commesse, quindi dovrebbe avere un campo FK IDCommessa e la relazione Commesse.IDCommessa uno-a-molti Movimenti.IDCommessa
  • M
    Mailman
    Utente Attivo
    Iscritto da
    mag, 2022
    Messaggi:
    244

    Re: Gestione documenti di acquisto

    fratac ha scritto:

    Hm....
    In realtà dovresti gestire tutto applicando un tuo codice di protocollo con il quale cataloghi ed archivi i documenti e non basarti sui codici dei documenti esterni, altrimenti non ci cavi più i piedi. Con un tuo codice di protocollo avresti solo un id da gestire. Tutto il resto sarebbe solo dati archiviati.
    Inoltre secondo me hai dimenticato la parte piu importante.
    Non vedo nessun riferimento alle aziende, o ai fornitori o ai clienti.
    Va bene archiviare tutto quello che hai postato, ma di solito ci si basa sul nome del cliente o del fornitore per gestire i documenti.
    Il DB che sto realizzando e' ad uso esclusivo della produzione, non tanto per la parte amministrativa per la quale abbiamo gia' un applicativo dedicato (ndr. Adhoc); nello specifico questa parte che sto implementando riguarda solo la gestione del materiale di acquisto a commessa.
    I protocolli vengono assegnati a DDT e fatture a livello contabile dopo arrivo fatture (quindi verso il 20-25 del mese successivo alla data fattura) e vengono utilizzati come indice per archiviarli nel server. Io mi limito a copiare il link dei singoli files nell'apposito campo in ogni tabella, ma lo faccio con almeno 40-45 giorni dl ricevimento dei DDT. Rimangono fuori poi ordini e offerte che non vengono ne protocollati ne salvati nel server, per cui dovrei inventarmi un nuovo protocollo; a quel punto tengo l'ID automatico con i singoli dati dei documenti.
    Per quanto riguarda le Aziende Fornitori in ogni tabella e' presente IDAzienda come FK, e i dati Azienda sono in una tabella dedicata.
    La parte Clienti ha una sua struttura con tabelle dedicate e preferisco tenerle separate da queste. Il collegamento fra le due e' la Commessa.
    Spero di avere chiarito
  • M
    Mailman
    Utente Attivo
    Iscritto da
    mag, 2022
    Messaggi:
    244

    Re: Gestione documenti di acquisto

    OsvaldoLaviosa ha scritto:

    Da quello che ho capito io, tutto fa capo alla tabella Commesse. La tabella Movimenti è figlia di Commesse, quindi dovrebbe avere un campo FK IDCommessa e la relazione Commesse.IDCommessa uno-a-molti Movimenti.IDCommessa
    Si' Osvaldo la commessa e' la parte trainante. Ma il suggerimento che hai dato di fare una tabella Movimenti non la vedo molto pratica; faccio un esempio per spiegare meglio: una commessa puo' contenere per lo stesso fornitore 10 ordini diversi, ogni ordine puo' essere evaso con 15-20 DDT a cui segue per ogni DDT la sua fattura. Nel Db da te suggerito come faccio per esempio a risalire dalla fattura a quali DDT fa riferimento, o eventalmente dal DDT a quale ordine? Dovrei portarmi dietro tutti gli ID di ogni documento in cascata. Mi ritroverei con un tabellone con tanti ID ma anche con tanti valori vuoti (per esempio se ho un ordine ma non l'offerta, il campo ID offerta risulterebbe vuoto...).
    Non so se ho inteso bene cio' a cui ipotizzavi
  • O
    OsvaldoLaviosa
    Super Famoso
    Iscritto da
    apr, 2012
    Messaggi:
    7493

    Re: Gestione documenti di acquisto

    Allora la struttura tabelle deve essere questa:
    Fornitori uno-a-molti Commesse
    Commesse uno-a-molti Ordini
    Ordini uno-a-molti DDT
    Siccome per un DDT corrisponde una Fattura, prevedi i campi Fattura nella stessa tabella DDT. Se DDT prevede poi altri "dettagli voci", devi avere una tabella DettagliDDT.

    Comunque a me suona strano che Commessa e Ordine non abbiano lo stesso significato.
  • M
    Mailman
    Utente Attivo
    Iscritto da
    mag, 2022
    Messaggi:
    244

    Re: Gestione documenti di acquisto

    Gusto per farvi un po' ridere, questa e' la situazione che ho adesso e che sto trasformando in qualcosa di piu' pratico (classica impostazione da Excel... )

  • O
    OsvaldoLaviosa
    Super Famoso
    Iscritto da
    apr, 2012
    Messaggi:
    7493

    Re: Gestione documenti di acquisto

    Excel devi metterlo da parte perchè non ha la potenza delle relazioni che ha Access. Il foglio finale di esposizione di tutti i dati verrà fuori da una query che includerà tutte le tabelle relazionate coinvolte e tutti i campi che a te interessa visualizzare.
  • M
    Mailman
    Utente Attivo
    Iscritto da
    mag, 2022
    Messaggi:
    244

    Re: Gestione documenti di acquisto

    OsvaldoLaviosa ha scritto:

    Allora la struttura tabelle deve essere questa:
    Fornitori uno-a-molti Commesse
    Commesse uno-a-molti Ordini
    Ordini uno-a-molti DDT
    Siccome per un DDT corrisponde una Fattura, prevedi i campi Fattura nella stessa tabella DDT. Se DDT prevede poi altri "dettagli voci", devi avere una tabella DettagliDDT.

    Comunque a me suona strano che Commessa e Ordine non abbiano lo stesso significato.
    Infatti e' l'impostazione che ho strutturato sopra, non vedo a che serva collegare la tabella fornitori alle commesse se gia' lego i singoli documenti alle commesse.
    Dovrei avere anche Commesse 1-N con DDT perche', come descritto sopra (ma capisco che non sia facile entrare al 100% nella logica della mia situazione), posso avere un DDT senza ordine e/o offerta ed anche Commesse 1-N con fatture perche' anche in questo caso potrebbe arrivare materiale solo con Fattura quindi senza DDT (e/o ordine e/o offerta).

    Per quanto riguarda il discorso di "...a me suona strano che Commessa e Ordine non abbiano lo stesso significato...": la commessa e' verso il Cliente , l'ordine e' verso il fornitore per cui sono due cose diverse.
    Grazie per i consigli sempre molto utili
  • M
    Mailman
    Utente Attivo
    Iscritto da
    mag, 2022
    Messaggi:
    244

    Re: Gestione documenti di acquisto

    OsvaldoLaviosa ha scritto:

    Excel devi metterlo da parte perchè non ha la potenza delle relazioni che ha Access. Il foglio finale di esposizione di tutti i dati verrà fuori da una query che includerà tutte le tabelle relazionate coinvolte e tutti i campi che a te interessa visualizzare.
    No, non e' Excel e' la foto della tabella di Access che ho adesso. Ma quando la creai circa 10 anni fa gli diedi una impostazione di "tipo Excel" come metodo di archiviazione (non avevo ancora idea di cosa fossa la normalizzazione e la reale potenzialita' di Access)


    E' per questo che sto riprogettando il tutto: perche' non posso piu' vedere una struttura cosi denormalizzata...
Devi accedere o registrarti per scrivere nel forum
50 risposte