Newsgroup: it.comp.lang.visual-basic
Titolo: Sw Gestionale e Magazzino

Ciao a tutti..
da qualche anno gestisco la mia contabilità con un piccolo sw
gestionale creato da me e man mano che le mie esigenze crescevano
implementavo il tutto con nuovi moduli , nuove funzioni.
Mi trovo ora a dover realizzare la parte del magazzino....
Ho già la sezione dell'anagrafica prodotti  che però consta di :
codiceprodotto,descrizione,nomeprodotto,quantità,prezzo,prezzoivato,costo.
Vorrei capire da chi è + esperto di me come strutturare il magazzino in
quanto
ho un'idea ma , essendo poco esperto in materia, mi piacerebbe avere un'idea
.
Poi mi chiedevo....se per gestire un magazzino era sufficiente aggiungere
capi tipo,
quantità, giacenza, etc etc già nella tabella prodotti oppure se sarebbe
meglio
gestire il tutto da una nuova tabella...
accetto qualsiasi tipo di aiuto ;-)
grazie
fab

fab
ciao
Aran Banjo
<math> 2 + 2 = 5 for sufficiently large values of 2</math>

 Poi dipende da cosa vuoi gestire realmente.
ok, butto lě anchio i miei due cent... perň di domanda :)
Premessa: non ho mai seriamente sviluppato un gestionale di magazzino, ma una
volta mi ero messo a progettarne uno, a scopo di "allenamento", e mi sono
trovato di fronte ad un "dilemma": come ricavare la giacenza di un determinato
articolo?
La domanda, posta cosě, č abbastanza banale... proviamo a specificarla
meglio....
Quando faccio un movimento a magazzino, prelievo o versamento, č il caso di
aggiornare immediatamente un campo in una tabella che contiene la giacenza
"attuale" dell'articolo, o č il caso di memorizzare semplicemente il movimento,
ricavando di volta in volta la giacenza come "giacenza iniziale - prelievi +
versamenti" ogni volta che serve. Oppure ancora č il caso di implementare un
misto tra queste due tecniche: memorizzazione dei movimenti e loro
consolidamento periodico (spero che sia chiaro ciň che intendo)?
Salutoni
Sergio

 consolidamento periodico (spero che sia chiaro ciò che intendo)?
Io faccio una cosa di questo tipo:
Ho una tabella dei movimenti possibili, ognuno dei quali caratterizzato da
un segno (+, -, 0 quando si tratta di una rettifica della giacenza assoluta,
e non di una variazione).
Ad ogni movimento, archivio il codice del movimento, la quantità
movimentata, la giacenza precedente e quella successiva al movimento.
Questo, per quanto ridondante, consente un efficientissimo debug e la
possibilità di ricostruire il dato in caso di problemi di sistema.
Contestualmente, aggiorno la quantità assecondando il segno del movimento.
Siccome, però, di un articolo potrei anche avere giacenza zero, e quindi non
avere un record nella tabella delle giacenze, mi troverei a dover scegliere
se fare un Insert o un Update.
Ho risolto tutto creando una mia Stored Procedure, a cui passo, come
parametri:
Id Articolo
Id Movimento
Id Utente
Id Ubicazione di prelievo (per movimenti di spostamento fra ubicazioni)
Id Ubicazione di destinazione
Quantità movimentata
La stored procedure apre una transaction, va nella tabella movimenti,
individua il segno, effettua l'aggiornamento giacenza, elimina il record
della giacenza se la quantità è andata a zero, archivia il movimento nel
journal, e chiude la transaction.
Ciao
Alberto

Non so se servono per la tua attività ma nell'anagrafica articolo
aggiungerei due campi: gruppo merceologico e sotto gruppo merceologico che
potranno esserti utili per interrogazioni successive.
Per la gestione del magazzino, ho creato una tabella MovMag con i campi:
Codice magazzino, data movimento, causale movimento, codice articolo,
quantità, segno, prezzo, sconto1, sconto2, sconto3, sconto4, Numero, Serie,
Descrizione movimento.
In questa tabella, vengono scritti i movimenti che vengono emessi quando si
genera una bolla/fattura o un carico di magazzino in modo da poter
ricostruire la storia di un determinato articolo.
Ho poi creato una tabella SaldiMag composta dai campi: Magazzino, Articolo,
Saldo, Disponibilità.
Quest'ultima viene aggiornata insieme a MovMag ma serve per avere sempre
disponibile la giacenza reale senza dover fare query su MovMag che è molto
più grande come mole di dati; in più se gestisci gli ordini puoi utilizzare
la disponibilità che sarebbe il saldo alla data - l'ordinato.
Spero di essere stato abbastanza chiaro anche perchè ho scritto tutto molto
velocemente. Se hai dubbi o altri quesiti puoi anche ricontattarmi in
privato all'indirizzo: 
vinc...@tiscali.it
Ciao, Vincenzo.

 se fare un Insert o un Update.
Io, banalmente, avrei avuto una tabella di titti gli articoli, giacenti o no,
con relativa quantità che potrebbe naturalmente essere pari a 0 (per le quantità
negative stiamo studiando una nuova release :)).
Quale ragionamento sta alla base della soluzione da te implementata?
Salutoni
Sergio

 ha scritto nel messaggio
news:b0159v$kpa5f$1...@ID-173193.news.dfncis.de...

Dunque...
Gli articoli sono elencati, con le loro caratteristiche principali, in una
tabella che generalmente si chiama Anagrafica_Articoli o qualcosa del
genere.
Le giacenze non possono stare nella medesima tabella, secondo logica di buon
design di un DB, visto che tu potresti avere duecento magazzini, e quindi
dovresti mettere duecento campi Giacenza_Mag1, Giacenza:_Mag2, ecc.., nella
tabella anagrafica_articoli.
Quindi, rimane una sola soluzione: una tabella dei magazzini, una tabella
degli articoli, ed una tabella [relazione] Giacenze che fa riferimento a
Id_Articolo e Id_Magazzino.
Per il momento, dimentichiamoci della questione plurimagazzino, diciamo che
ne abbiamo solo uno.
Ad un certo punto, la nostra azienda decide di gestire un nuovo articolo.
Non è ancora a magazzino, è semplicemente esistente in anagrafica, perchè
qualcuno ne ha inserito la descrizione, ad esempio proprio per farne
l'ordine.
Le possibilità sono due:
1) contestualmente alla creazione in Anagrafica_Articoli, crei anche un
record in Giacenze, con il medesimo Id_Articolo e giacenza 0. Funziona
benissimo, ma in questo modo sei andato a 'cablare' nel tuo codice che hai
solo un magazzino. Se domani ti chiedono, che so, di gestire le ubicazioni
di magazzino, o più magazzini, o comunque di modificare un campo della
tabella delle giacenze, devi modificare il codice anche nel modulo di
gestione delle anagrafiche.
2) Nella tabella delle Giacenze, non crei alcun record. Questo significa
giacenza zero. L'unica accortezza, è che nel momento in cui 'entra' in
magazzino una quantità di quell'articolo, anzichè un Update dovrai fare un
Insert, ma con una minima gestione delle Transaction (che comunque è
d'obbligo sempre), la cosa è del tutto indifferente.
Il grosso vantaggio dell'approccio che suggerivo (che è questo secondo
caso), è che il modulo delle anagrafiche e il modulo della gestione di
magazzino sono assolutamente indipendenti.
Il caso che mi si è verificato di recente, è stato quello di una azienda per
la quale abbiamo sviluppato un sistema di gestione delle distinte base,
delle anagrafiche dei semilavorati, e di altre cosine.
Poi, ma solamente poi, hanno deciso di affidarci anche il magazzino.
Il software di gestione delle anagrafiche continua a consentire di creare
articoli e semilavorati in maniera indipendente dalla gestione del
magazzino. L'eliminazione di un articolo giacente a magazzino è comunque
impedita dalle regole di integrità referenziale gestite da Sql-Server
direttamente.
Ciao
Alberto

Albe V° ha scritto:
...
La gestione degli articoli di magazzino può apparire molto semplice (e in
effetti, se le esigenze sono limitate, lo è).
A lungo andare (affrontando cioè le realtà più varie e non volendo avere
8000 programmi diversi) si scoprono differenze/esigenze che, di fatto,
"costringono" a scelte strutturali, pur nelle varie alternative, quasi
obbligate.
Un esempio "castrante" l'ha fatto Albe, riferendosi alla gestione dei
magazzini, che io chiamo depositi: il magazzino gestionale è unico, ma gli
articoli sono distribuiti, per questioni logistiche (ma anche
concettuali/virtuali) in più depositi, supponiamo 10. Non penso sia il caso
di avere lo stesso articolo creato 10 volte, ovviamente con codice diverso.
L'articolo quindi (inteso come "anagrafica" e codice) è uno solo e,
ipotizzando, per semplicità, di gestirne solo la giacenza reale, dovremmo
avere 10 campi per le 10 possibili giacenze sui 10 possibili depositi. Poco
comodo, specialmente pensando alla possibile estensione del numero dei
depositi. Meglio prevedere quindi una tabella che contenga, per ogni record,
la giacenza di ogni deposito, ben caratterizzata da codice articolo e codice
deposito. Ovviamente la stessa tabella può disporre di tutti gli altri campi
necessari, come, ad esempio, carichi, scarichi, resi, etc., ma anche scorta
minima, massima, etc., e, perchè no?, prezzo di vendita (che magari può
essere diverso da deposito a deposito, in funzione della dislocazione fisica
e del mercato locale).
Per ogni articolo vi sono poi altre informazioni "dinamiche" che tendono ad
essere trascurate inizialmente: l'elenco dei fornitori (ciascuno con il
costo di acquisto praticato diversificato, magari una codifica e una
descrizione propria da citarsi negli ordini, etc.), ma anche l'elenco dei
clienti coi quali si è concordato un prezzo particolare che nulla ha a che
fare col normale prezzo di vendita, magari spesso ritoccato nel tempo.
Vi sono poi altre informazioni, sempre "dinamiche", quali immagini e media
vari allegati, disegni e documenti, tutte riferite a un singolo articolo
Quindi, sintetizzando, io preferisco prevedere una tabella per le semplici e
comuni anagrafiche dell'articolo, una per i fornitori, una per i clienti,
una per i media, una per i "totali" a quantità e valore.
A proposito di quest'ultima, faccio un'ulteriore precisazione, ovviamente
relativa alla struttura che ho adottato: Fermo restando che le "coppie di
quantità e valori" progressive possono essere molte (io sono arrivato a 32),
preferisco non fissarne il significato e mi spiego. Io non so, a priori e al
volo, se la coppia numero 1 riguarda la giacenza, piuttosto che gli scarichi
o i resi da cliente. Ho una tabella (questa valida per tutti gli articoli)
che specifica la descrizione che l'operatore vuol dare a ciascuna coppia
gestita (eh, già, perchè mica posso imporre di gestire, e anche solo di
vedere, la quantità prodotta se quello produzione non fa), l'ordine secondo
il quale la stessa viene elencata fra le varie informazioni dinamiche
dell'articolo (una griglia, per intenderci) e tante altre cosine del tipo:
concorre a comporre la giacenza, in + o -, concorre a comporre il totale
carichi, in + o -, il valore medio, etc. Le varie coppie vengono gestite da
un tot (quanti? tanti!) di parametri nelle causali dei movimenti, tabella
anch'essa gestibile liberamente dall'operatore, con i quali si dice "tutte
le volte che usi questo tipo di causale/movimento devi aumentare la coppia
25 e ridurre la coppia 13, solo per la quantità o anche per il valore.
Perchè questo? Un solo esempio: Alcuni intendono i resi (per esempio da
clienti) come storni di scarichi (vendite), altri come carichi.
Personalmente preferisco la seconda (perchè più aderente alla realtà), ma
non entro nel merito fiscale, me ne strabatto, ognuno faccia come meglio
crede o come il suo consulente (che io non sono, nè voglio assumermi più
responsabilità di quante già me ne regalano le semplici indicazioni che
spesso mi trovo a dover dare ... perchè il consulente non lo sa), quindi,
uno gestirà in sottrazione una certa coppia di qtà/valore, altri in somma
un'altra coppia.
Il sistema, ovviamente per questioni di immediatezza, ha tutti i totali
conseguenti delle varie operazioni, aggiornati in tempo reale, ma può
(ovviamente riaggiornando tutta la movimentazione) ricostruirli in
automatico in caso di ... incidentali interruzioni. Naturalmente molte
informazioni sono ottenibili anche dall'analisi dei singoli movimenti, per
esempio per vedere gli analoghi totali per un certo periodo parziale.
Da questa breve descrizione, credo si possa capire (e magari giustificare)
perchè a volte "rimprovero" coloro che scrivono "dovrei fare un programmino
di un magazzinino che gestisce pochini articolini..." ;-)

 di un magazzinino che gestisce pochini articolini..." ;-)
beh... dipende: ovvio che il sistema da te disegnato è complesso, ma perchè il
tuo è un gestionale "vero", che vendi ad un cliente, anzi a molti clienti, e hai
dovuto costruirlo in modo tale da essere facilmente adattabile alle più
disparate richieste....
Ad esempio a me non era mai venuta in mente la possibilità/necessità di dover
gestire più "sedi" fisiche e/o virtuali, anche se in effetti, in una
implementazione c'era una cosa del genere, che non ricordo neanche più come ho
risolto...
La gestione di un magazzino "semplice", costruito ad hoc per un unico
utilizzatore è una cosa (imvvvvho) un po' più facile di come la dipingi, anche
se, per altro, mi sembra un ottimo esempio didattico di come una cosa
all'apparenza elementare può diventare, molto velocemente, ingestibile.
Salutoni
Sergio

 utilizzatore è una cosa (imvvvvho) un po' più facile di come la dipingi...
Sì, ecco perchè dicevo "capire" e "giustificare". :-)

 ha scritto nel messaggio
news:b01cjq$kbasm$1...@ID-174464.news.dfncis.de...

Esempio a mio sfavore:
Estrazione elenco giacenze (ubicazioni, unità di misura e tipologia sono in
tabelle apposite)
select TG.ID_semilavorato, TG.ID_Ubicazione, TG.Quantita,
 isnull(CS.descr_breve,'') as Descr_Semilavorato,
 isnull(CTS.descr_breve,'') as Descr_Tipo,
 isnull(TU.Descr_breve,'') as Descr_Ubicazione,
 isnull(CUM.Descr_Breve,'') as Descr_UM,
 isnull(CUM.ID_UM,cast('00000000-0000-0000-0000-000000000000' as
uniqueidentifier)) as ID_UM
from tabella_giacenze as TG
 left outer join catalogo_semilavorati as CS
 on tg.id_semilavorato=cs.id_semilavorato
 left outer join catalogo_tipi_semilavorati as CTS
 on cs.id_tipo=cts.id_tipo
 left outer join tabella_ubicazioni as TU
 on TG.id_ubicazione=TU.ID_ubicazione
 left outer join catalogo_um as CUM
 on TG.ID_UM=CUM.ID_UM

 consolidamento periodico (spero che sia chiaro ciò che intendo)?
Io ho avuto la possibilità di utilizzare i sorgenti di due grossi programmi
di contabilità...
uno ha scelto la prima scelta e uno la seconda...
Io personalmente preferisco aggiornare anche la Qtà così in fase di lettura
è + veloce...
secondo me dipende anche quanti movimenti di magazzino si fanno...
Alex

 >
cut
Io credo che Fabry abbia si sottovalutato la cosa ma in generale per il suo
contesto qui sicuramente la si sia sopravalutata spaventandolo.Credo che per
lui le cose possano essere abbastanza semplici se si accontenta di una
gestione minima, ma se effettivamente aspira a creare nel tempo qualcosa di
ampio un attenta progettazione è indispensabile.
Se ad esempio il nostro amico ha un solo deposito e non si vuole curare di
un eventuale aumento di questi perchè magari è impossibile...1 problema
risolto...e così via.
Per essere io salverei le giacenze, carichi e scarichi ecc... in una tabella
separata dagli articoli e la aggiornerei in tempo reale, però deve esistere
un programma che le ricalcola quando voglio dai movimenti.

Sergio
Ciao


 ma perchè il tuo è un gestionale "vero", che vendi ad un cliente
Esistono anche altre problematiche che non avete sviscerato (ma che immagino
Lupo abbia dovuto gestirle nel suo programma): il conto lavorazione, il
conto vendita, e la data di scadenza.
Nel primo caso si tratta di un magazzino (tipicamente quello del fornitore
del semilavorato) che deve essere gestito come una fase intermedia di
lavorazione della distinta base, e deve entrare nella gestione del
sottoscorta (collegata ai tempi fisici di trasferimento della merce tra i
magazzini e alla quantità di merce in produzione).
Il secondo caso è quello della tentata vendita, o del rappresentante
itinerante. E' in pratica un magazzino perché finché non vendi la merce è
ancora tua, ma siccome la merce resterà fuori per un certo tempo non puoi
contarla quando consideri il sottoscorta. Può essere gestita come un conto
visione, ma in questo modo ti tocca gestire i tuoi agenti come dei clienti,
e questo non è fiscalmente corretto.
Il terzo caso è quello delle merci deperibili. Non basta sapere quante ne
hai, ma ciascuna deve avere una data di avviso, e una di scadenza. La
procedura di consegna deve prendere le merci dai diversi magazzini in base
alla data di scadenza, ma deve poter essere possibile modificarne la
modalità quando risultasse più conveniente far fare ai camion un unico
viaggio da un solo magazzino piuttosto che due da magazzini diversi.
Poi ci sono i magazzini di abbigliamenti, dove l'articolo non ha solo il
modello, ma anche la taglia.
Insomma, il magazzino genera un sacco di grattacapi per gestire tutte le
casistiche, e Lupo ha tutta la mia comprensione ;-)
Ciao
*Roby*

 conto vendita, e la data di scadenza.
In realtà, l'approccio con la tabella delle ubicazioni, a cui accennavo,
consente numerosissimi escamotage che consentono di gestire queste cose:
il conto lavorazione può essere visto come un magazzino
il conto vendita pure
la data di scadenza può essere definita come una ubicazione. Quando un
articolo entra a magazzino, viene 'immesso' nell'ubicazione 20030225, che
significa che al 25 Febbraio 2003 scadrà, ecc...
Ovviamente può convenire anche gestire la cosa con tabelle apposite, ma se
ci si tarpa le ali fin dalla partenza, inserendo la giacenza come un campo
dell'anagrafica, tutte queste cose ce le scordiamo.
Ciao
Alberto