Newsgroup: it.comp.appl.access
Titolo: Diverse filosofie di gestione di un magazino

Sto riflettendo ora su alcune questioni.
Capisco dai messaggi che leggo che, normalmente, dovendo gestire un qualche
tipo di magazino... si hanno una tabella con le giacenze aggiornate ad una
certa data, ed una con tutte le movimentazioni/entrate/uscite.
Le giacenze attuali di solito vengono calcolate sum momento, per ogni record
del magazino calcolo le entrate/uscite totali e le sommo alle giacenze... ed
ottengo la giacenza atuale.
Ho detto giusto?
Io invece per gestire un magazino ho semplicemente una tabella con le
giacenze, sempre aggiornata, e la aggiorno continuamente, quando le cose
entrano/esco dal magazino.
Ed ho delle tabelle di "storico" con registrate tutte le operazioni fatte.
Io lo faccio così perchè è il primo modo che mi è venuto in mente.
Chiedo a voi esperti: Qual'è il modo migliore?
Quali sono i vantaggi/svantaggi di queste due filosofie?
La mia mi pare molto più semplice... ma se spesso si usa l'altra deve avere
dei vantaggi che ora mi sfuggono... :-|
Qualunque commento è gradito.
Ciao, Max

 ha scritto nel messaggio
news:iOe27.26905$q77.1...@news2.tin.it...

Secondo me dipende dal tipo di elaborazione che esegui; mi spiego meglio.
Supponi di avere una tabella articoli con la giacenza ad inizio giornata; se
la maggior parte delle procedure lavora con una situazione ad inizio
giornata, ti conviene aggiornare la giacenza in modalità batch (a fine
giornata). Se invece le procedure utilizzano una giacenza in tempo reale,
allora conviene aggiornare immediatamente tale valore. Facendo dei raffronti
in altri contesti, ad esempio la gestione dei c/c bancari, conviene gestire
una situazione aggiornata in tempo reale, in quanto ogni operazione
determina la liquidità, il saldo contabile e altri dati che autorizzano il
cliente ad eseguire o meno determinate operazioni.
Bye
LaLo

 wrote in message iOe27.26905$q77.1...@news2.tin.it...



La tua filosofia mi pare giusta, ma a volte è utile anche sapere le giacenze
ad una certa data,
quindi io di solito ho una tabella su cui memorizzo le giacenze progressive
per mese.
Ciao
Bolo

 per mese.
Mmmh... interessante... ci puoi fare un sacco di statistiche... bello! :-)
Ciao, Max

 ha scritto nel messaggio
news:iOe27.26905$q77.1...@news2.tin.it...

In generale si dice che in una tabella di un database relazionale non si
memorizzano mai delle informazioni (quindi campi calcolati) ma solamente dei
dati; e questo proprio per una semplificazione procedurale. Infatti
memorizzando il risultato di un calcolo in un campo di una tabella, occorre
fare in modo che, ogni volta che si interviene per inserire, cancellare o
modificare i dati che sono alla base di tale campo calcolato, si debba
contestualmente modificare anche il valore del campo calcolato.
Ritornando al problema da te messo in discussione, se in una tabella mi
memorizzo un campo calcolato con la giacenza aggiornata per un determinato
articolo, dovrò prevedere di aggiornare tale campo ogni volta che aggiungo,
cancello o modifico una entrata o una uscita; a mio avviso ciò sarebbe una
complicanza procedurale inutile. Molto meglio ottenere il valore della
giacenza attuale con una query di raggruppamento sul codice articolo basata
sul Left Join tra la tabella prodotti (contenente anche la giacenza ad una
certa data) e la/e tabelbella/e movimenti.
Comunque, se la gestione di magazzino fosse fatta solo a quantità, la scelta
procedurale potrebbe essere ancora discussa, ma se la gestione di magazzino
va fatta (come è norma) anche a valore, la valorizzazione della giacenza può
essere fatta solo in maniera dinamica. Quale prezzo unitario useresti per
valorizzare la giacenza memorizzata in una tabella? Se usi l'ultimo prezzo
di acquisto rischi quasi sempre di sovrastimare il valore del magazzino (i
prezzi normalmente aumentano nel tempo); le conseguenze possono essere
deleterie: rischi di pagare più tasse, visto che il valore di magazzino è
una posta attiva del bilancio di una azienda. L'alternativa sarebbe quella
di valorizzare le giacenze a prezzo standard; questo non è però accettato
fiscalmente; fiscalmente è richiesta la valorizzazione delle giacenza in
base ad un prezzo medio determinato con il criterio FIFO (First Input First
Output). Questa tecnica prevede una valorizzazione dei movimenti nello
stretto ordine cronologico in cui avvengono: le entrate vanno valorizzate al
prezzo di acquisto e le uscite al valore medio che la giacenza ha al momento
in cui avviene l'uscita.
A questo punto, se il valore della giacenza va calcolato in maniera
dinamica, tanto vale calcolare in maniera dinamica anche la sua quantità.
Questo è il mio punto di vista, che se vero, porta a "vincere" questo
criterio di tenuta del magazzino 2 a zero sull'altro. ;-)
--
Roberto
---------------------------------------------
il Sito Comune di it.comp.appl.access:
http://www.sitocomune.com
---------------------------------------------

 criterio di tenuta del magazzino 2 a zero sull'altro. ;-)
Il problema è che calcolare tutto dinamicamente ha un peso "mostruoso" sul
computer.
Cioè, metti che ho un magazino, nel magazino ho svariate decine di migliaia
di articoli, per, almeno 10'000 righe (nella tabella delle giacenze)
Ogni giorno arriva un tir di articoli che entrano, ed un tir di altri
articoli se ne escono.
Supponi che devi rispondere in tempo reale e velocemente alla domanda
"Quanti pezzi ho in magazino dell'articolo Q200L ?"
Devi prendere tutti i record di quell'articolo dalle giacenze (metti qualche
centinaio), e poi devi aplicarci tutte le movimentazioni (metti che siano
svariate migliaia perchè le tue giacenze sono aggiornate a 3 mesi fà).
Quanto ci metti a calcolare la giacenza? Secondo me ci vuole un sacco di
tempo.... troppo.
Oppure... 1000 volte peggio, pensa che vuoi vedere sullo schermo una banale
listga delle giacenze di tutti gli articoli a magazino, e vuoi poterla
scorrere/filtrare/stampare e cose simili...
Il sistema delle giacenze calcolate dinamicamente lo capisco.... mi sfugge
come riesca ad essere efficente.
Metti che devi fare una movimentazione... ogni volta devi ricalcolarti la
giacenza per vedere se puoi movimentare quell'articolo.
Altra domanda, diversa: prima parlavi di valorizzare il magazino, come lo
faresti?
Metti che oggi prendi 10   Q200 a 2000£ l'uno
tra un mese prendi 30    Q200 a 2100£ l'uno
tra 3 mesi prendi 5   Q200   a 1950£ l'uno.....
Per ogni acquisto crei un record nuovo se il prezzo è diverso da quelli già
presenti. Mi sembra l'unico modo...
Terresti conto anche delle date di entrata? e se si... dove? nella tabella
delle giacenze? od in quella delle movimentazioni (entrate/uscite)?
Ciao, Max

 presenti. Mi sembra l'unico modo...
Tra l'altro mi sovviene un altro problema.... per poter fare quanto sopra
devi avere negli articoli Q200 a magazino qualche rifrimento che ti permetta
di distinguere quelli che hai pagato 2000 da quelli 2100 da quelli 1950.
Però.... non so, se devi solo valorizzare il magazino non conta... però se
devi, metti, vendere i Q200 in base a quanto li hai pagati... allora devi
poterli distinguere.
Però continuando a pensarci se i Q200 sono identici è inutile fare
distinzioni(a livello di magazino), anche se li hai pagati un prezzo
diverso. L'importante è ter conto del costo complessivo quando fai il prezzo
di vendita (10x2000+30x2100+5x1950) così poi i conti tornano.
Ciao, Max (con questo messaggio mi sa che ho sprecato della banda :-)

 ha scritto nel messaggio
news:Obj27.17923$eB4.6...@news.infostrada.it...
Dimenticavo un'altro vantaggio: puoi calcolarti le giacenze ad una qualsiasi
data.


 ha scritto nel messaggio
news:9ic017$9a0$1...@pluto.news.dsi.unimi.it...

Perdonami, ma è proprio nella gestione di un c/c bancario che non andrei mai
a registrare in una tabella il saldo liquido ed il saldo contabile, ma me li
andrei appunto a determinare (e non a leggere) con un calcolo in tempo
reale, per evitare le complicanze di cui accennavo nel mio precedente
messaggio.
Nella tua ipotesi non potresti inoltre determinare in tempo reale gli
interessi attivi e passivi maturati; per far questo devi tenere conto
dell'estratto conto scalare con i saldi per valuta al livello di giornata,
tenendo anche conto delle antergate e delle postergate e delle commissioni
di massimo scoperto; se le cifre in gioco sono consistenti, in un conto
corrente in rosso l'importo degli interessi passivi e delle commissioni di
massimo scoperto possono risultare determinnti nel determinare la
disponibilità.


 Ciao, Max


 ha scritto nel messaggio
news:mRj27.33624$q77.2...@news2.tin.it...

In prima istanza la valorizzazione del magazzino non serve a determinare il
prezzo di vendita di un prodotto; il valore di magazzino va determianto in
base al valore medio di acquisto; poichè tale valore ha implicazioni
fiscali, deve rispettare leggi e regolarmenti fiscali ben precisi.
Invece il prezzo di vendita di un prodotto è determinato, oltre che dal
prezzo medio di acquisto anche dalle leggi di mercato, dalle politiche
commerciali e dalle risultanze della contabilità generale di una azienda
(ancora meglio se è stata meccanizzata una contabilità industriale analitica
a livello di prodotto).
Insomma la gestione di magazzino è un sottosistema di un sistema aziendale
integrato più complesso; all'ufficio acquisti serve solo le giacenze a
quantità, ma ad altri enti aziendali serve essenzialmente il valore delle
giacenze calcolate secondo criteri ben precisi.


 > news:iOe27.26905$q77.1...@news2.tin.it...
[CUT]

Ho fatto un paragone con una realta' che conosco bene ma che c'entra poco
con l'ambiente relazionale (per lo meno nella mia modesta esperienza)!! Hai
ragione tu se si gestisce il tutto con un DBMS, ma le cose variano se si
passa ad altri paradigmi.
Bye
LaLo

 data.
Ganzo, a livello statistico è una cosa potente :-)
Max

 entrate sarà memorizzato il numero d'ordine.
Mmm... non capisco una cosa... metti che hai le giacenze aggiornate ad
oggi... i quantitativi in giacenza devono pur avere un prezzo, essendo
giacenze non hanno più un corrispettivo nelle tabelle delle entrate/uscite,
quindi devono avere un loro prezzo.
Cioè, la vedo così:
Inizio) ho il magazino vuoto, nessuna giacenza....
Compro/vendo) aggiungo tanti record alle tabelle di entrate/uscite, con
quantità e prezzi di entrata/uscita, calcolati come dicevi tu prima
Aggiorno le giacenze) calcolo tutte le giacenze, ogni articolo ha il suo
prezzo medio, aggiorno la tabella delle giacenze con le quantità ed i prezzi
calcolati, storicizzo e svuoto le tabelle di entrata/uscita (così velocizzo
il sistema)
Calcolo giacenze) Calcolo le nuove entrate/uscite, le sommo alle vecchie
giacenze in tabella(facendo la media pesata dei prezzi), ed ho le
quantià/prezzi aggiornati.
Funziona così?
Grazie, Max

 passa ad altri paradigmi.
Ad esempio?
Max

 ha scritto nel messaggio
news:3Px27.40496$q77.2...@news2.tin.it...

Reticolare, gerarchico, sistemi proprietari (vedi Bull).
Bye
LaLo

 necessario a determinare il valore delle uscite.
Grazie, mo ho capito :-)
Domanda... c'è in rete o da qualche parte qualche esempio... qualche
documentazione... per imparare a gestire bene i DB in queste situazioni?
Ciao, Max

 Mmmh... interessante... ci puoi fare un sacco di statistiche... bello! :-)
Credo sia funzione anche del tipo di magazzino da gestire.
Prendo come esempio un'applicazione che ho sviluppato per un cliente.
Il cliente deve applicare la gestione dei movimento per un sistema
multimagazzino (Magazzino delle materie prime, magazzino dei prodotti finiti
e quello di 'n' terzisti, per il conto lavorazione).
L'azienda effettua un inventario annuale e 10 inventari mensili (saltano il
mese successivo a quello annuale e quello di chiusura dell'azienda).
Visto il numero di articoli movimentati e il numero di movimenti quotidiano,
č impensabile memorizzare i saldi giorno per giorno.
Il magazzino, quindi, contiene l'esistenza iniziale (dell'anno precedente o
di apertura saldi), un progressivo dei vari carichi e scarichi e un totale
del mese precedente.
La somma di questi tre valori permette di avere l'esistenza attuale.
E' stata prevista anche una funzionalitą per ottenere le esistenze
corrispondenti ai vari movimenti, giocando con i saldi di magazzino e i
movimenti (ricalcolando tutto, insomma, in una tabella temporanea, a partire
da una certa data 'A', arrivando alla data 'B').
Sinceramente, avrei preferito gestire un record per ogni mese inventariato,
ma sono entrato a lavoro gią iniziato, quindi mi sono dovuto adattare :-)

 ha scritto nel messaggio
news:BxS27.44823$cd.2...@news1.tin.it...

Non so darti una risposta.
Se però non hai approfondito ancora i due database di esempio Northwind e
Ordini, comincia da lì: vivisezionali e vedrai che.....
--
Roberto
---------------------------------------------
il Sito Comune di it.comp.appl.access:
http://www.sitocomune.com
---------------------------------------------

 Ordini, comincia da lě: vivisezionali e vedrai che.....
Obiettivamente non li honeppure mai aperti... :-))))))))
Li guardo appena ho tempo!
Grazie, Max

clicli For ... Next, provi e poi decidi.
No, Roberto, sei fuori strada.
Finora non ho visto un solo programma di magazzino "serio"
che calcoli le giacenze in tempo reale.
Il problema e' complesso, non si tratta solo di sommare
quantita' positive o negative in un solo campo, ma di
applicare formule anche molto complesse su svariati campi,
che vanno interpretati sulla base delle impostazioni delle
causali di movimentazione.
Nessuno si accontenta di sapere che del prodotto xyz sono
stati caricati 100 pezzi e scaricati 80, per cui la giacenza
e' 20: so che ho acquistato 80, 10 mi sono stati omaggiati,
5 sono stati resi da clienti e 5 erano la giacenza iniziale;
poi ne ho venduti 60, rottamati 2, inviati in riparazione
18.
E questo e' solo un esempio banale. 
Ad ogni causale di magazzino corrispondono determinati modi
di movimentazione di, diciamo, una decina di campi "carichi"
e una decina di "scarichi"; la giacenza va quindi calcolata
considerando le formule applicate a tutti questi campi.
E senza contare il multimagazzino: pensa se dovessi passare
tutte le righe di movimentazione dei miei, diciamo, 30
magazzini, per calcolare la giacenza consolidata!
Eppoi, come dice giustamente Max, pensa ad una
valorizzazione di magazzino a costo medio, per esempio, con
quella dozzina di migliaia di articoli...
Ebbene si', ammettiamolo, un db di magazzino e' quanto di
piu' denormalizzato si possa concepire ;-) ma e' l'unico
modo di gestire la cosa.
Tutto quanto sopra e' rigorosamente IMHO.
--
Lorenzo Coronati
--
<<Ragazzi, sapete indicarmi una utility in 
internet che sia in grado di recuperare le 
password da un database access e da un system mdw?
intendevo, gratuita...>>
(Marco Tullio Bisoli, 27/04/2001)
--

 E questo e' solo un esempio banale.
Interessante...
La tua soluzione quindi qual'è?
Calcoli le giacenze dinamicamente? o le tieni sempre aggiornate in tempo
reale?
Il tuo esempio mi fa supporre che sia praticamente impossibile avere in
qualche secondo (al massimo) la giacenza/stato/disponibilità di tutto un
magazino (o tutti i magazini di un'azienda).
Quindi se le prestazioni soo basilari forse vale la pena di fare tutto
aggiornato in tempo reale...
Tu che ne pensi?
Ciao ,Max

 --
--


 E poi come dice MegaMax si sta facendo solo  un pò di "filosofia". :-)
Sarà anche filosofia... ma però credo che per il prossimo DB che progettero
prenderò in considerazione l'idea di struttirarlo in modo dinamico,
piuttosto che a giacenze statiche. Quantomeno per fare esperienza
(ovviamente se la cosa risulta sensata)
Ciao, Max (grazie di tutto :)

 quella dozzina di migliaia di articoli...
La gestione di magazzino che ho sviluppato, ha grandi pecche (più che altro
eprchè l'ho sviluppata io), ma, per ora, ti permette di sapere in tempo
reale diverse informazioni:
Esistenza Iniziale
Disponibilità
Ordinato
Vendita per omaggio
Venduto
Conto Lavorazione
Corso Lavorazione
E non ricordo cos'altro.
E si tratta di una gestione multimagazzino con gestione del costo medio.
Gli articoli sono sia semilavorati, sia materie prime, sia prodotti finiti.
I primi due gestiti con una sola anagrafica, il terzo gestito in maniera
distinta per diversi motivi che non sto ad elencare.

Purtroppo illavoro non l'ho iniziato io, ma credo che avrei come minimo
tentato di utilizzare in maniera intensiva i trigger, sia per calcolare i
saldi in funzione delle causali, sia per tenerli aggiornati (che poi sarebbe
la stessa cosa).
Più in tempo reale di così non credo si possa fare :-)
Inoltre, questo sistema dovrebbe garantire una buona gestione degli utenti
concorrenti che, al limite, possono essere gestiti anche tramite
l'applicazione, con l'utilizzo di semafori.

 del debito). Sedici società, oltre 30 depositi (proprietari e terzi),
oltre
Ah, giusto, dimenticavo. Il mio sistema adotta un sistema di tipo LIFO

 la stessa cosa).
Cosa sono i trigger?
Ciao, Max


--


E poi come dice MegaMax si sta facendo solo  un pò di "filosofia". :-)
Questi sono i 3d che mi piacciono di piu'!
Bai


aggiornato in tempo reale...
Avrai visto nel resto del 3d come la penso.
Cmq bisogna prima di tutto avere chiaro in mente l'ambito di
applicazione e le esigenze del/dei cliente/i.
Se la mia esperienza (distribuzione) ti puo' interessare,
chiedi pure.


 --
Ciao, e al prossimo piacevole confronto: anche a me piacciono questi thread!
