Gestione documenti di acquisto

di il
50 risposte

50 Risposte - Pagina 2

  • Re: Gestione documenti di acquisto

    Mailman ha scritto:


    la commessa e' verso il Cliente , l'ordine e' verso il fornitore per cui sono due cose diverse.
    Tu hai le tabelle Clienti e Fornitori separate oppure unica tabella?
    Io credo che Clienti-Commesse-Fatture abbia un iter NON STRETTAMENTE LEGATO a Ordini-Fornitori, quindi potresti tracciarli separatamente.

    Mailman ha scritto:


    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).
    Mi piacerebbe sapere come sono fatti questi documenti Commesse, Ordini, Fatture (potresti allegare immagini), quali campi da compilare contengono e come li "archivieresti" tu se non ci fosse oggi l'informatica/Access a darti una mano.
  • Re: Gestione documenti di acquisto

    OsvaldoLaviosa ha scritto:


    Tu hai le tabelle Clienti e Fornitori separate oppure unica tabella?
    Per ora non ho anagrafica cliente (non mi occorre, scrivo il nome in commessa ma so che e' sbagliato...), ma in futuro quando implementero' anche la parte "clienti", potrei utilizzare la stessa aggiungendo un flag

    Grazie Osvaldo, ti rispondo piu' tardi che ora devo scappare...
  • Re: Gestione documenti di acquisto

    A me sovviene un altro ragionamento. Tu hai DocumentiCartacei che si susseguono giorno dopo giorno. Ogni Documento potrebbe avere suoi dettagli. Ignorando se si parli di Cliente o Fornitore, più in generale di RagioniSociali, io rivedrei la struttura tabelle così:

    RagioniSociali
    IDRagioneSociale (PK)
    RagioneSociale
    Indirizzo
    IDCittà
    ...altri campi tipicamente anagrafici...

    Documenti
    IDDocumento (PK)
    DataDocumento
    TipoDocumento (qui specifichi se si tratta di Commessa, Ordine, DDT, Fattura)
    Descrizione
    IDRagioneSociale (FK)

    DettagliDocumenti
    IDDD (PK)
    Campo1
    Campo2
    ...sai tu che campi potrebbero descrivere...
    IDDocumento (FK)

    Relazioni:
    RagioniSociali.IDRagioneSociale uno-a-molti Documenti.IDRagioneSociale
    Documenti.IDDocumento uno-a-molti DettagliDocumenti.IDDocumento
  • Re: Gestione documenti di acquisto

    Per come ragiono, ti sfuggono dei particolari.
    Dici che ci possono essere delle commesse, senza preventivi, o consegne senza ordini.
    Magari non hai una pezza di appoggio, magari è fatta a voce o telefonicamente, magari su accordi vecchi di anni. Però qualcosa hai sempre, altrimenti come fai a sapere che devi inviare un prodotto o che ti occorre una certa quantità di materiale in base ad una vendita? Anche se non hai una commessa diretta?
    Per questo ti dicevo di creare un protocollo tutto tuo.

    Inoltre non ho ben capito, ma di solito gli acquisti di materiale, non si basano sui documenti del venduto, ma sulla produzione effettiva. Primo perché i tempi sono molto diversi, secondo perche se ci fosse un annullamento di un ordine, ti ritroveresti un prodotto finito in magazzino, senza vendita e quindi non avresti bisogno di dover acquistare altro materiale in caso di un nuovo ordine, ma potresti vendere quelli già prodotti.
    E mi sembra che attualmente questa casistica non sia contemplata.
    Non devi ragionare con i documenti contabili, ma con i movimenti di magazzino. Quindi, la fattura ad esempio, non è determinante ai tuoi fini. Ti potresti fermare al ddt, che certifica l uscita fisica del prodotto dall azienda.

    Indipendentemente da questo, visto che stai ricostruendo il database, togli tutti quei check box e metti una combo con le varie opzioni.
    Se devi aggiungere una causale, con le check, saresti costretto a mettere mano ogni volta alla struttura e modificare le query.
    Con la combo invece potresti inserire millemila causali e sopratutto avresti solo una quesry parametrica che non modificheresti mai
  • Re: Gestione documenti di acquisto

    Buongiorno,
    credo di aver postato questo thread nel posto sbagliato. Forse sarebbe meglio spostarlo nella sezione Progettazione database per cui chiedo al moderatore di spostarlo se lo ritiene opportuno.
    Ri-posto di seguito le relazioni fra tabelle perché mi sono accorto di alcuni errori:
    TblCommesse:
    1-N con TblOfferte
    1-N con TblOrdini
    1-N con TblDDT
    1-N con TblFatture

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

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

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

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

    Rispondo sia Osvaldo che a fratac ringraziandoli per le considerazioni.
    Aggiungo ulteriori chiarimenti a riguardo: il DB è ad uso esclusivo mio (o di chi mi sostituira' raggiunta la pensione). Serve ESCLUSIVAMENTE per uso interno: di fatto non deve produrre documenti contabili ufficiali. Lo scopo è di monitorare le lavorazioni di officina per fornire alcuni strumenti a chi processa le lavorazioni e per ottenere il consuntivo a fine lavoro sia per le ore impiegate sia per i materiali e/o lavorazioni esterne. L'azienda si occupa di costruzione stampi, dime e piccole automazioni, nonché realizzare manutenzioni o modifiche su stampi dei clienti, o eseguire lavorazioni meccaniche conto terzi.
    Buona parte dei lavori vengono quantificati a consuntivo e possono durare dalla giornata fino al mese, mese e mezzo, quindi è importante avere disponibili tutte le informazioni subito a fine lavoro per poter inviare al cliente il consuntivo della lavorazione. Per il nuovo invece si lavora spesso a preventivo e per poterlo sottoporre prima al cliente a volte ci si basa su consuntivi di lavorazioni analoghe.
    Per cui, per esempio, la tabella Anagrafiche non mi interessa di avere inserita la partita iva, il telefono o l'indirizzo perché sono dati che non mi servono (li ho già nella rubrica di Outlook...). Ad ogni modo si possono comunque implementare dopo avendo la tabella dedicata.
    La procedura standard di lavoro è questa: arriva un nuovo lavoro da fare (stampo nuovo, dima, modifica, riparazione, ecc), apro la commessa cioè inserisco alcuni dati sull'anagrafica del tipo di lavoro, il cliente, il dettaglio del lavoro da fare, la data di scadenza e, se ci sono, l'offerta fatta al cliente, l'ordine del cliente e il DDT di consegna del bene. Stampo un paio di reports che sono la scheda di lavoro e la cartellina che contiene la scheda e che conterrà eventuali ulteriori documenti a corredo (disegni, mails, ecc) e la consegno all'officina. La commessa potrebbe richiedere l'acquisto di materiale e/o la realizzazione di lavorazioni esterne (la richiesta mi arriva dal Tecnico che ha in gestione la commessa) per cui, a richiesta, mi muovo verso i fornitori con telefonate o email. Il fornitore può rispondere con una offerta e/o una conferma d'ordine e/o uno o più Ddt e con la fattura finale.
    I dipendenti utilizzano inoltre il numero di commessa per quantificare le loro ore di lavoro su un modulo cartaceo mensile che mi preoccupo di ritirare settimanalmente per inserire le ore nel db.
    Finito il lavoro, faccio il consuntivo ma ovviamente non posso attendere di avere tutte le fatture dei fornitori per realizzarlo perché ci vorrebbe troppo tempo, per cui devo avere sempre una situazione aggiornata in tempo reale e, nel caso mancassero dei prezzi, chiamo i Fornitori e me li faccio dare per telefono.
    Tutta la parte dell'anagrafica commesse e delle ore di officina è già implementata anche se dovrò rivederla più avanti per normalizzarla in alcune parti e renderla più prestazionale.
    Troppo loquace??? Scusate...
    edit
  • Re: Gestione documenti di acquisto

    fratac ha scritto:


    Indipendentemente da questo, visto che stai ricostruendo il database, togli tutti quei check box e metti una combo con le varie opzioni.
    Se devi aggiungere una causale, con le check, saresti costretto a mettere mano ogni volta alla struttura e modificare le query.
    Con la combo invece potresti inserire millemila causali e sopratutto avresti solo una quesry parametrica che non modificheresti mai
    Per la prima parte dei quesiti spero di aver risposto con il mio post precedente. Ripeto: la parte che sto implementando riguarda la ESCLUSIVA gestione del materiale di acquisto, quindi non la parte verso i Clienti.
    Le check box sono solo 3 e saranno sempre e solo 3, servono per indicare se l'attività verso il fornitore riguarda l'acquisto di materia prima, o l'acquisto di componenti normalizzati, o la realizzazione di lavorazioni esterne. Non ci sono altre causali possibili per le attività verso i fornitori (o almeno in 12 anni di dati non è mai successo...).
  • Re: Gestione documenti di acquisto

    Quindi a mio modo di vedere, pensavo di configurare le tabelle così;

    TblOfferta-ordine (i campi sono indicati in un mio post precedente):
    1-N con TblOfferte
    1-N con TblOrdine

    TblOfferta-ddt:
    1-N con TblOfferte
    1-N con TblDdt

    TblOfferta-fattura:
    1-N con TblOfferte
    1-N con TblFatture

    TblOrdine-Ddt:
    1-N con TblOrdini
    1-N con TblDdt

    TblOrdine-fattura:
    1-N con TblOrdini
    1-N con TblFatture

    Per le relazioni con la commessa avevo pensato a queste due tabelle:
    TblCommessa-offerta-ordine:
    1-1 con TblCommesse
    0-N con TblOfferte
    0-N con TblOrdini

    TblCommessa-ddt-fattura:
    1-N con TblCommessa
    0-N con TblDdt
    1-N con TblFatture

    È questa ultima parte che non mi piace perché mi troverei con possibili campi vuoti...
  • Re: Gestione documenti di acquisto

    Secondo me la struttura corretta è quella da me proposta.
    Per tutto ciò che hai raccontato nel post 13 nov 2022, 08:57 si tratta di implementare molto altro a livello di query, maschere, codice VBA...ma il discorso diventa molto più complesso e non discutibile in un solo thread.
  • Re: Gestione documenti di acquisto

    OsvaldoLaviosa ha scritto:


    Secondo me la struttura corretta è quella da me proposta.
    Ciao Osvaldo, provo a seguire il tuo ragionamento per capire come, con la tua soluzione potrei risolvere le criticità che vedo.
    Ipotizziamo che faccio un ordine di componentistica ad un fornitore e lui mi manda la conferma d'ordine con i prezzi per ogni voce. Io registro il documento nel DB TblMovimenti con la causale "IDordine".
    Poi il fornitore mi consegna la merce, non tutta assieme, ma in più spedizioni quindi avro' più Ddt da registrare nella TblMovimenti con causale "IDddt". Ipotizziamo inoltre che le spedizioni arrivino una a fine mese ed una nel mese successivo. Mi trovo due fatture che andrò a registrare sempre nella stessa TblMovimenti con "IDFattura". Ti assicuro che questo esempio è MOLTO frequente...
    Ora, con un sistema del genere, come faccio a trovare con quali DDT ho evaso quell'ordine? O a quale fattura/e fa riferimento l'ordine?
  • Re: Gestione documenti di acquisto

    Mi stai dicendo che in qualsiasi caso ci troviamo, anche una vendita DIRETTA, vuoi sottoporlo sempre a un Ordine. Se sì, puoi correggere la struttura così:
    RagioniSociali uno-a-molti Ordini
    Ordini uno-a-molti Documenti
    Documenti uno-a-molti DettagliDocumenti

    (mi sembra la classica struttura del noto database NorthWind)
    Se ti capita una vendita diretta...crei comunque un Ordine al quale fai seguire un Documento DDT o Fattura...non importa che in questo caso si tratta di una situazione uno-a-uno.
  • Re: Gestione documenti di acquisto

    Osvaldo continui a confondere le vendite con gli acquisti ...
    È dall'inizio del thread che io parlo di gestione acquisti non vendite.
    Sono due cose totalmente separate (anche come uffici...). Io gestisco gli acquisti di produzione, un altro ufficio gestisce le vendite utilizzando un altro db con un altro gestionale. Spero di aver chiarito....
  • Re: Gestione documenti di acquisto

    Dal post 13 nov 2022, 08:57 leggo che parli anche di Clienti. In quest'ultimo post parli solo di "acquisti": boh!
    La tabella Ordini può avere un campo di discriminazione (bivalore) Acquisto/Vendita.
    Vuoi invece dirmi che vuoi focalizzare l'attenzione sulla situazione descritta nel post 13 nov 2022, 15:06?
  • Re: Gestione documenti di acquisto

    Mailman ha scritto:


    ...Ripeto: la parte che sto implementando riguarda la ESCLUSIVA gestione del materiale di acquisto, quindi non la parte verso i Clienti.
    A me sembrava di essere stato chiaro nel post che hai citato...
  • Re: Gestione documenti di acquisto

    Ho riletto più attentamente il primo posto: parli solo di acquisti da Fornitori. Bene...rileggendo questo con "spirito critico"

    OsvaldoLaviosa ha scritto:


    Mi stai dicendo che in qualsiasi caso ci troviamo, anche una vendita DIRETTA, vuoi sottoporlo sempre a un Ordine. Se sì, puoi correggere la struttura così:
    RagioniSociali uno-a-molti Ordini
    Ordini uno-a-molti Documenti
    Documenti uno-a-molti DettagliDocumenti

    (mi sembra la classica struttura del noto database NorthWind)
    Se ti capita una vendita diretta...crei comunque un Ordine al quale fai seguire un Documento DDT o Fattura...non importa che in questo caso si tratta di una situazione uno-a-uno.
    arrivi a pensare la stessa struttura con denominazioni diverse, ma uguale nella sostanza, cioè:
    Fornitori uno-a-molti Ordini
    Ordini uno-a-molti Documenti
    Documenti uno-a-molti DettagliDocumenti
  • Re: Gestione documenti di acquisto

    Ragionare su qualcosa di teorico è molto difficile perchè, non si conosce l'organizzazione aziendale, i metodi di lavoro e la gestione del magazzino.
    Quindi naturalmente si fa per parlare.
    Però continuo a ripetere che non sei sulla strada giusta. Vedo solo riferimenti a ddt, fatture, ma non vedo nessun riferimento ai prodotti da acquistare e vendere e nessun riferimento ai movimenti.
    Stai sviluppando la parte di gestione del carico/scarico del magazzino e di inizio produzione/fine produzione ed evasione degli ordini da parte dei reparti di produzione, con conseguente carico del magazzino con i prodotti finiti.
    Ti sei fossilizzato sulle relazioni con offerte, ordini, ddt, e fatture, ma non sono queste che ti occorrono.
    Questi sono solo riferimenti che non devono necessariamente essere in relazione tra di loro.
    Devi creare un gestionale con cui fai i movimenti di carico/e scarico del magazzino.
    Il caposaldo deve essere l'ordine, collegato con la tabella dei movimenti, collegata a sua volta con la tabella dei prodotti acquistati ed usati (carico/scarico) che ti permettono di gestire gli acquisti e la produzione.
    Tutto il resto sono semplici riferimenti che possono essere riportati solo come dati testuali.
Devi accedere o registrarti per scrivere nel forum
50 risposte