Newsgroup: it.comp.appl.access
Titolo: Come fare la gestione carico/scarico di magazzino?

Parlando dei classici sistemi di gestione vendite/ordini/magazzino, 
verificando su diverse procedure software ho visto che ognuno fa a suo 
modo, alcuni mantengono le esistenze/disponibilita' dei singoli articoli 
su tabelle separate tipo 'contabile articoli', altri visualizzano 'al 
volo' le quantita per ogni articolo come somma dei carichi meno le 
vendite, altri ancora aggiornano scrivendo direttamente sulle 
anagrafiche articoli, il campo esistenza (o simile) dopo ogni carico per 
acquisto ed ogni vendita (ddt/fattura)
In definitiva ogni sistema ha i suoi pro e contro
Voi come fareste per mantenere una corretta gestione delle quantita' dei 
singoli articoli?
Ciao e grazie
RobertoA
 


personalmente calcolo sempre il magazzino calcolando al volo carichi 
meno scarichi.
in più ho implementato la funzione di storicizzazione che mi permette di 
cancellare tutti i movimenti precedenti a una certa data e storicizzare 
direttamente sull'articolo l'esistenza di partenza sul quale ricalcolo 
carichi + scarichi. ogni 5-10 anni torna buona.
parlo di magazzini con 200.000 articoli e circa 1500 movimenti di 
carico/scarico al mese.
BE sql server
 
 
 


Si, visualizzare facendo i conti 'al volo' e' sicuramente la procedura 
piu' precisa perche' mostri sempre quanto risultante dal venduto/acquistato
E' pero' la piu' pesante dal punto di vista computazionale
1500 x 12 sono circa 20.000 righe/anno sulle quali operare per trovare 
l'esistenza del singolo articolo
Se devi visualizzare una griglia con codice/descrizione/esistenza 
articoli immagino non sia immediata la visualizzazione
Come fai in questo caso?
 
 

>>>>  
http://www.bb2002.it
 :)  <<<<<
........... [ al lavoro ] ...........

 
"RobertoA"

Entrambe le cose:
 
- Registrazione Saldi Articoli su Anagrafiche (con utility di Ricostruzione 
Saldi per correggere eventuali anomalie)
- Uno Storico Statistico creato sui movimenti che, tra le tante cose, 
permette di visualizzare vita/morte/miracoli di un articolo, compreso il 
Saldo Finale (esistenza).
 
Saluti 
 
 


io ragiono sempre con il concetto del "non mostrare quello che non viene 
richiesto"
quindi non ha senso mostrare una griglia con 20.000 articoli...e non ne 
vedo l'utilità. che senso ha scorrere una griglia di 20000 righe?
faccio sempre filtrare per descrizione o famiglia articoli per limitare 
i risultati
poi tieni conto che la velocità di sqlserver è imparagonabile a quella 
di un mdb
 
ciao
 
 


Si, certo, e' inutile mostrare quello che non viene chiesto
Ma se viene chiesto di stampare le rimanenze di magazzino?
Non ho ben capito "la velocita' di sqlserver e' imparagonabile vs un 
mdb"  intendi dire che su sqlserver e' molto piu' veloce rispetto a 
lavorare su un mdb?


ovvio che la stampa ci mette un po'...
ma parlavamo di una griglia e quella è velocissima.
 
cmq ad esempio io stampo l'inventario di magazzino selezionando le 
categorie da stampare.
se mi cambiano articoli di una data categoria è inutile ristampare tutto.
 
 
 
le prestazioni di un database client-server (sql server)  vs un file 
server (mdb) in ambienti con parecchi client e moli di dati corpose è 
imparagonabile
 
ciao
BFS
 
 
 
 
 
 

RobertoA was thinking very hard :

Una tabella Anagrafica Articoli con tutto quel che serve (Codici,
Scorta Minima, Tempi di Consegna, etc) relazionata 1-->oo con la
tabella Movimenti contenente data e tipo movimento (entrata/uscita,
fornitore/cliente, quantità e poch'altro).
A nuovo esercizio trasferimento elementi vecchio esercizio allo
storico calcolando nel nuovo le rimanenze iniziali per quantità
e valore.
 
Le esistenze calcolate per quantità e valore da
RI + Carico - Scarico.
 
Bruno


Quindi quando fai un ddt vendita, oltre alle righe ddt vai a creare 
anche delle righe corrispondenti sulla tabella Movimenti ?
Non ti sembra un doppione di roba da memorizzare?
Ma soprattutto, quando devi visualizzare una lista articoli con 
esistenza a fianco, visualizzi 'al volo' la somma 
rimanenze+carico-scarico dei movimenti di quell'articolo oppure tieni 
memorizzato da qualche parte il valore Esistenza e visualizzi quello, 
modificandolo quando viene venduto/acquistato l'articolo ovviamente
Insomma il dubbio e' se visualizzare le esistenze all'instante della 
richiesta calcolandone ogni volta il valore sui movimenti articolo 
(sistema piu' impegnativo ma esente da sempre perfettamente coerente) o 
mantenere memoria dell'esistenza attuale e modificarla solamente quando 
viene movimentato l'articolo (sistema piu' rapido ma soggetto a 
disallineamenti tra valore memorizzato ed esistenze reali)
Ciao e grazie
RobertoA
 
 


mi intrometto..
una tabella movimenti è indispensabile se vuoi una gestione seria del 
magazzino.
ti serve per memorizzare molti altri dati sia di carico che di scarico 
che nei ddt non avresti.
esempio quando si fa un carico, in certe realtà si memorizza anche il 
magazzino, lo scaffale, il ripiano, la posizione di dove l'articolo 
viene messo.
senza poi tirare in ballo distinte base etc
 
ciao
BFS
 
 
 
 
 
 
 

 valore memorizzato ed esistenze reali)
Generally speaking, nessun calcolo viene riportato sulle tabelle.
I calcoli si fanno al volo via codice da Form o da Query che
servono per la visualizzazione dati e/o la creazione di report.
 
Bruno