Newsgroup: it.comp.appl.access
Titolo: consiglio su calcolo esistenze di magazzino

ciao a tutti...
ho un dubbio e vorrei alcuni pareri.
devo gestire le esistenze di magazzino, secondo voi č meglio calcolarle
runtime in base a bolle distinte di carico e scarico fatture accompagnatorie
(come faccio ora)
oppure ad ogni emissione, variazione, cancellazione di questi documenti
salvare l'effettiva esistenza sull'archivio articoli (che risulterebbe molto
piů veloce quando si apre l'elenco esistenze)
ciao, AEOM

 ciao, AEOM
La logica di un database relazionale presupporebbe che venisse adottato il
metodo di calcolare la giacenza on-the-fly in base a quanto contenuto
solamente nella/e tabella/e dei movimenti, naturalmente sempre che i tempi
di risposta risultino accettabili.
Per evitare un progressivo deterioramento della performance
dell'applicazione a causa del continuo aumento dei record movimento,
potresti adottare una via di mezzo: con una elaborazione batch annuale (o
con altra periodicità da te stabilita, dipende dalla quantità dei movimenti)
potresti mettere i movimenti precedenti all'inizio periodo off-line e
calcolarti una giacenza di inizio periodo da memorizzare nella tabella
prodotti; quindi il computo della giacenza risulterà dalla sommatoria
algebrica tra la giacenza di inizio periodo e i movimenti successivi alla
data di inizio periodo che avrai appunto lasciati in linea.
Questo ti darebbe comunque la possibilità di aggiornare i record della/e
tabella/e movimenti senza preoccuparti dell'aggiornamento in tempo reale del
valore della giacenza memorizzata nell'archivio prodotti.
-- 
Roberto
---------------------------------------------
il Sito Comune di it.comp.appl.access:
http://www.sitocomune.com
---------------------------------------------


Questa tecnica ibrida mi sembra un'ottima idea...grazie
AEOM


Buongiorno Roberto,
questa soluzione appare comoda.
In realtà a me piace anche dare lo storico della movimentazione.
Invece di consolidarlo come valore sommatori, potrei "spezzare" la tabella
fino ad una certa data
e unirla poi quando mi serve.
Grazie, ti devo chiamare l'uomo del Faro...
MAssimiliano

 ha scritto nel messaggio
news:7b4nb.13937$uv4....@news.edisontel.com...

Non ho capito la tua considerazione.
Se per determinare la giacenza devi comunque leggere tutti gli "spezzoni"
dei movimenti (visto che non ti memorizzi la giacenza ad inizio "spezzone")
è del tutto inutile spezzettare la/e tabella/e movimenti.
La mia ipotesi è quella di avere memorizzata nella tabella prodotti la
giacenza ad una certa data, quindi tenere i movimenti con data maggiore di
quella in una tabella dei movimenti correnti, mentre memorizzerei i restanti
movimenti (data <= a quella dell giacenza memorizzata) in una tabella
storica; in ogni momento sarò in grado di ricavarmi la giacenza ad una certa
data: se la data della giacenza cercata è maggiore alla data della giacenza
memorizzata nella tabella prodotti, la nuova giacenza lo otterrò SOMMANDO
algebricamente alla giacenza memorizzata i movimenti della tabella corrente
con data <= alla data della giacenza da calcolare; se invece devo
determinare una giacenza ad una data precedente alla data della giacenza
memorizzata, la otterrò SOTTRAENDO algebricamente alla giacenza memorizzata
i movimenti della tabella storica aventi una data >= alla data della
giacenza da calcolare.
In effetti, periodicamente, cancello i movimenti dalla tabella corrente e li
copio nella tabella storica dopo aver aggiornato la giacenza memorizzata
nella tabella prodotti (normalmente tale "travaso" viene efetuato alla fine
di un esercizio economico, quando le giacenze sono sacre ed intoccabili,
visto che sono finite a bilancio).
Visto che al 99,99% si deve calcolare la giacenza attuale, ci si troverà ad
usare per il calcolo solo la tabella prodotti e la tabella movimenti
correnti; si ricorrerà ai movimenti storici (quindi elaborazione più lenta)
solo per determinare una giacenza dell'esercizio precedente.
-- 
Roberto
---------------------------------------------
il Sito Comune di it.comp.appl.access:
http://www.sitocomune.com
---------------------------------------------



Non so dove cuttare.
Allora tu hai ribadito ciò che pedestremente ho tentato di fare io.
La mi a esigenza era solo quella che se io in questo momento muovo il codice
MAX123
voglio sapere quel codice come l'ho venduto in precedenza a quel cliente.
Quindi non posso conslidare 100 pz ma voglio avere 20+30+50pz venduti in
data diversa.
Queste movimentazioni posso averle prima e dopo la data di archiviazione.
MAssimiliano

MA ha scritto:


Dato che la tabella storica avrà la stessa identica struttura di quella
corrente ti basta mettere nella form uno switch con cui scegli se
visualizzare i movimenti correnti o quelli dello storico, e modifichi il
recordsource della form per passare da una tbl all'altra (mettendo la
maschera in sola lettura quando vai su storico).
Namor
-- 
 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it


Non è un problema, come dicevo prima mi creo una query di unione.
Uso questa archiviazione perchè in una casellacombinata ho il riepilogo di
tutto il magazzino
usando molte query di aggregazione.
Così non ce n'è bisogno
MAssimiliano

 MAssimiliano
Ovviamente bisogna considerare le esigenze degli utenti. Di solito una
volta chiuso l'esercizio finanziario non c'è più interesse nel vedere i
movimenti vecchi. Comunque invece che i soli movimenti dell'ultimo anno,
si possono lasciare in linea quelli degli ultimi due-tre anni, a seconda
delle necessità. E rimane sempre valida la query di unione per
visualizzare la situazione completa (con filtro che escluda i record con i
riepiloghi dei movimenti precedenti).
Se invece i movimenti sono pochi ti puoi anche azzardare a lasciare tutto
in linea, contando sul fatto che le prestazioni dei sistemi sono in
continuo aumento, per cui fra 5 o più anni quando il db sarà cresciuto
probabilmente starà girando su un PC 5 volte più veloce di quello
originale.....
