+ Rispondi al Thread
Visualizzazione dei risultati da 1 a 5 su 5

Discussione: Creare distinta vendite

  1. #1
    PennaBiro non è in linea Novello
    Post
    2

    Creare distinta vendite

    Ciao
    Premetto che "arrivo" da un DB Works, molto semplice. Una pulce nei confronti di un elefante.
    Mi sono letto dei libri ma notte fonda... ho incominciato un po a giocherellare..... spero di aver capito qualcosa in più.

    Vengo al dunque:
    Voglio creare una distinta vendite. Ho creato:

    tre tabelle, Articolo (ID, Codice, Nome articolo)
    Acquisti (ID, CodiceArticolo, Quantità, Costo, Prezzo Vendita)
    Vendite (ID, Codice, Quantità, Costo, IncassoTot)

    Ho creato una relazione uno>molti tra Codice e CodiceArticolo e pensavo di poter creare una query di accodamento (con campi calcolati) in modo da poter aggiungere i dati nella TabellaVendite. Qui mi sono arenato.

    grazie, spero di essere chiaro ed il meno possibile prolisso

  2. #2
    L'avatar di @Alex
    @Alex non è in linea Very Important Person
    Post
    15,219
    I campi ID secondo te a cosa servono...?
    Le Relazioni tra le Tabelle vanno create tra Chiavi che sono Univoche e Primarie nella Tabella lato(1) ed Indici nelle Tabelle lato(M).
    Se hai dei Campi PK(ID) che poi non usi non so bene perchè li hai inseriti... e se il campo Codice non viene definito ChiavePrimaria non potrai aggiornare nulla...
    Altra cosa è che i Campi Calcolati sono tali se rimangono calcolabili... e di solito non si FISSANO in Tabella...

    Sei poi sicuro che servano 2 Tabelle Acquisti e Vendite...? Che differenza c'è tra le 2 Operazioni o Movimenti... oltre al segno del Flusso di Danaro ed al segno della Giacenza di Magazzino(eventualmente)...?
    @Alex
    Il CROSSPOST è VIETATO
    Mirror al vecchio sito WEB(salvare i Demo riassegnando l'estensione (.Zip/.Rar/.Exe in base all'icona...):
    http://mirror.masterdrive.it/alessandrobaraldi/
    Leggi il
    Regolamento del Forum e nel comprenderne la filosofia rispettalo.

  3. #3
    L'avatar di gibra
    gibra non è in linea Amanuense
    Luogo
    Breganze (VI)
    Post
    5,850

  4. #4
    PennaBiro non è in linea Novello
    Post
    2
    Quote Originariamente inviato da @Alex Visualizza il messaggio
    I campi ID secondo te a cosa servono...?
    Le Relazioni tra le Tabelle vanno create tra Chiavi che sono Univoche e Primarie nella Tabella lato(1) ed Indici nelle Tabelle lato(M).
    Se hai dei Campi PK(ID) che poi non usi non so bene perchè li hai inseriti... e se il campo Codice non viene definito ChiavePrimaria non potrai aggiornare nulla...
    Altra cosa è che i Campi Calcolati sono tali se rimangono calcolabili... e di solito non si FISSANO in Tabella...

    Sei poi sicuro che servano 2 Tabelle Acquisti e Vendite...? Che differenza c'è tra le 2 Operazioni o Movimenti... oltre al segno del Flusso di Danaro ed al segno della Giacenza di Magazzino(eventualmente)...?

    Ciao Alex e gibra grazie del vostro interessamento

    ho sempre usato DBWorks. Vi spiego come la utilizzavo: il DB ha solo un foglio, una maschera ed 8 report, pertanto per più operazione devo avere più file.

    1) file "Acquisti" dove sono segnati tutti gli articoli acquistati con relativo fornitore e le varie voci legate all'articolo (codice, peso, unità di misura, gruppo(x5), IVA, quantità acq., dati fattura, ecc.
    Quando devo fare un ordine utilizzo un report che: filtra i dati per fornitore raggruppa i singoli articoli e somma le singole quantità acquistate.

    2) files "Ordine" dove incollo il risultato del report "Acquisti" e lo salvo con nome e data. In questo file riesco a vedere, del singolo articolo, i suoi "movimenti" e decidere le quantità di un nuovo acquisto, con un report (salvato in pdf) creo l'ordine da spedire. all'arrivo della merce devo segnare: dati fattura, quantità e l'effettivo costo pagato. Da un report ricavo (copio incollo) i dati da accodare (griglia/scheda) del file "Acquisti".

    Non so se sono riuscito a spiegarmi, sono a vostra disposizione

    ps. non è finita a "cascata manuale" ci sono altri file ..... per "Listino Prezzi", "Vendita Giornaliera", "Fattura". Io vorrei fare un unico file perchè, finchè lo uso io, è tutto ok ma se è un altra persona sono guai ..... sto cercando di destreggiarmi con Access ma non è facile...

    Grazie ancora del vostro aiuto e tempo dedicato

  5. #5
    L'avatar di +m+
    +m+
    +m+ non è in linea Scribacchino
    Post
    922
    Allora qualche "flash" generale (in realtà non molto utile per Access, ma per lavori "veri").
    Comunque...
    1) se non hai vincoli di prestazioni (e generalmente non li hai) allora NON usare chiavi primarie autoincrementanti, bensì chiavi "parlanti" o derivate o generate come vuoi. Questo rende estremamente più facile backup, restore, e merge di archivi
    2) un campo autoincrementante generalmente ci va sempre (ad esempio in mysql con engine innodb è necessario, se non lo metti te ne mette uno lui "nascosto", tanto vale usarlo), ma per usare come SER, o identificazione univoca delle righe (per ad esempio cancellare quella corrente eccetera)

    Venendo ad aspetti più relativi alla logica, c'è l'annoso problema del collassamento delle entità (e relazioni) verso l'alto o il basso.
    "Una volta" aveva un senso effettuare una sorta di shard logico (cioè di partizionamento orizzontale a fini prestazionali), oggi dove anche un smartorologio ha potenza smisurata, tipicamente, ti consiglio di andare con una singola tabella, dove avrai un campo flag che distinguerà acquisti da vendite

    Qui si apre tutto lo spiegone sui vantaggi di usare i segni (+ e -) per differenziare acquisti da vendite.
    Il pregio è la comodità di fare i saldi (basta una SUM), il dramma è sia l'instabilità numerica, in prossimità di piccoli valori, quindi dovrai porre attenzione particolare alla codifica dei campi "money", sia al rischio degli arrotondamenti (cioè l'inserimento di righe di valore negativo/positivo per che so arrotondare un movimento da 999,99 a 1.000)

    Personalmente andrei di sempre positivo, campo flag, e nel caso delle SUM dovrai fare due query (anche se formalmente ne fai una l'ottimizzatore te ne farà due).

    Infine c'è il "pippone" sui campi calcolati (normalizzati) o meno, in sostanza il prodotto quantita*prezzo.
    Di nuovo ci sono pregi e difetti, io però ti consiglio caldamente di denormalizzare (cioè non usare campi calcolati, ma proprio stoccare il valore del prodotto), sia perchè lato applicazione potrai fare una bella funzione euroarrotonda (cosa fondamentale, altrimenti di nuovo parte il pippone di controllare che il tuo sistema db arrotondi bene, cosa non banale per le valute), sia per rendere mooolto più agevole i report, sia per rendere mooolto più rapide le SUM.

    Nulla ti vieterebbe di fare query (non so se esistono in Access) con dentro IF, praticamente IF(campoflag=vendita then...), IF(campoflag=acquisto then...) in modo da ottenere risultati raggruppati con singola operazione.
    Ma sono fullscan.

+ Rispondi al Thread

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi