Newsgroup: it.comp.appl.access
Titolo: Ho sentito parlare di magazzino da SittingHorse

Spett.le NG,
ho letto i precedenti msg che riguardano i db per la gestione magazzino.
Anch'io, nel mio piccolo, sto realizzando una semplice applicazione per un
amico che ha un negozio di alimentari. Mi sono inchiodato su un problema che
tuttora non so come risolvere, non tanto per mancata conoscenza di Access
(anche se in sostanza sono un novellino), ma più per come impostare il
discorso : diciamo che quando ordino del materiale, i prodotti vengono
acquistati a un certo prezzo, e con il ricarico in percentuale viene
conteggiato il costo al pubblico. Perciò, ogni sera, quando si ricarica il
magazzino e si registrano le nuove fatture fornitori i prezzi
automaticamente cambieranno. Peccato che la merce in giacenza (ovvero tutta
la merce meno quella inserita la sera) verrà venduta ad un prezzo al
pubblico non giustamente appropriato. Infatti se una prodotto scende di
prezzo, la giacenza viene venduta ad un prezzo più basso, quando
proporzionalmente è stata acquistata ad un prezzo più basso.
Nella speranza di essere stato sufficientemente chiaro, chi ha avuto una
simile "esperienza"? C'è qualcuno che ha pensato ad un modo alternativo di
come risolvere la faccenda.
Ringrazio per l'ascolto!
Saluti
Sergio Della Giora

 ha scritto nel
messaggio news:9tjcsn$305v2$1...@ID-84518.news.dfncis.de...

Perdonami, ma se devi realizzare la gestione di un magazzino a quantità e
valore, non vedo che cosa c'entri la determinazione del prezzo a cui il tuo
amico poi rivende i salumi che acquista.
La determinazione del valore delle scorte di magazzino va fatta solo in base
al prezzo di acquisto delle merci; fra l'altro la valorizzazione va fatta,
in base alla legislazione fiscale vigente (in questo momento il valore medio
delle scorte di magazzino va determinato in sintonia con il sistema
F.I.F.O.: First Input First Output).
La determinazione del prezzo di vendita il tuo amico la dovrà fare oltre che
in base alla dinamica dei prezzi di acquisto anche, e soprattuto, tendendo
alla massimalizzazione dell'utile complessivo di gestione, che, visto
l'attività che esplica è fortemente influenzata dalle leggi di mercato;
l'utile complessivo è rappresentato da una gaussiana che raggiunge il suo
massimo con il prezzo ottimale di vendita: se il prezzo di vendita è
maggiore di quello ottimale l'utile complessivo diminuisce perchè
diminuiscono le vendite più di quanto aumenta il prezzo di vendita.
A mio avviso la gestione di magazzino va fatta, anche per legge, in base al
prezzo di acquisto e nulla ci azzecca il prezzo di vendita; il valore di
magazzino poi confluirà, insieme alle strategie di marketing,  verso una
procedura di controllo di gestione all'interno della quale si verificherà se
il confronto costi e ricavi garantiscono l'utile che il tuo amico si è
prefisso; è dall'esito di questo tipo di elaborazione che deciderà se è
necessario aumentare, diminuire o lasciare invariati i prezzi di vendita.
Non per niente la grande distribuzione alimentare vende alcuni prodotti
sottocosto (leggi vendite promozionali) per usarli verso la clientela come
specchietto delle allodole per poi venderle anche altri prodotti più
remunerativi.
--
Roberto
---------------------------------------------
il Sito Comune di it.comp.appl.access:
http://www.sitocomune.com
---------------------------------------------

 F.I.F.O.: First Input First Output).
Ok, ma questo solo se la valorizzazione va fatta a fini fiscali, giusto?
Io sconsiglierei a chiunque di fa re un qualsiasi tipo di programma di
gestione che contempli la parola "fiscale"; quando lo si fa "per un amico",
o tanto per fare.... si rischia di fare casini immani.
Dove lavoro abbiamo fatto un prog di gestione magazzino + barcode, gestisce
anche valorizzazioni e prezzi di acquisto/vendita, ma tutto č tranne che
fiscale.
Cosě facciamo tutto come pare a noi e come torna comodo a noi :-)
Ma sei sicuro che atualmente le valorizzazioni fiscali DEBBANO per forza
essere fatte col sistema FIFO? e non con un piů sensato e comodo da gestire
(imho) "prezzo medio pesato"?
Noi, per la gestione non fiscale, ricalcoliamo il prezzo medio di acquisto
ogni volta che entrano pezzi nuovi, la media ovviamente tiene conto dei
quantitativi :-) Inoltre non cambiamo il prezzo di vendita, e quindi
ricalcoliamo la percentuale di ricarico per far tornare i conti.
Il magazino viene gestito a singola riga, non a "carico/scarico"; era piů
semplice da realizzare... specie dato che non avevamo mai fatto DB simili
:-)
In effetti se dovessi rifarlo probabilemnte lo farei a "carico/scarico"....
saperlo prima.... :-)
Ma tanto le dimensioni sono piccole (sulle 3000-5000 righe tin totale), per
ora funziona bene cosě :-)
Idee? Consigli? Critiche? (cerco di imparare qualcosa di un mondo che
conosco ancora poco :-)
Max

 Max
--


Forse ho suscitato una polemica su problemi ben più alti di quelli che ho in
realtà io.
Come dice giustamente MegaMax, il db è per un amico, quindi una cosa
casalinga, niente di fiscale dunque.
L'applicazione semplicemente dovrebbe dare il valore del prezzo al pubblico
di un determinato articolo richiesto, ottenuto dal prezzo fornitore + la
percentuale di ricarico.
Questo lo fa già, ma l'unico problema, su cui mi piacerebbe avere una
piccola illuminazione, è il seguente :
al variare del prezzo di acquisto, i prezzi per la merce acquistata nella
fattura precedente, verranno venduti con un rapporto diverso da quelli
caricati nell'ultima. Mi aiuto con un esempio.
Fattura 201 del 11-11-2001
Articolo            Quantità      Prezzo acquisto
---------------------------------------------
Pasta barilla         10                ? 20
ne vendo 6.... e ne ordino altre 10, ma il prezzo fornitore è aumentato.
Fattura 202 del 20-11-2001
Articolo            Quantità      Prezzo acquisto
---------------------------------------------
Pasta barilla         10                ? 21
Ipotizzando che il ricarico sia del 50%
mi troverei a vendere la pasta a ? 210 + 50%, ma io ho ancora 4 scatole in
giacenza (caricate a ? 200).
In questo caso ci guadagno, ma se il prezzo fornitore diminuisce il mio
amico vende la giacenza a basso costo...
Tutto qui....
Mi piacerebbe risolvere la cosa semplificando al massimo la faccenda. Per
adesso cambio il prezzo al pubblico solo se la merce aumenta di prezzo, ma
non mi sembra giusto nei confronti dei consumatori .
Sergio Della Giora

 ha scritto nel
messaggio news:9tltp3$3gsa9$1...@ID-84518.news.dfncis.de...

La soluzione è tra le righe dei precedenti messaggi.
Devi gestire le giacenze del negozio sia a quantità che a valore (in base al
prezzo di acquisto), ricavandoti anche il prezzo medio ponderato di acquisto
di ogni prodotto; sarà su quest'ultimo che farai la ricarica del 50% e
quindi determinerai il prezzo di vendita il quale varierà in maniera equa in
più o in meno al variare del prezzo di acquisto in più o in meno.
Le entrate le valorizzerai in base al prezzo puntuale di acquisto, mentre le
uscite le valorizzerai in base al prezzo medio ponderato della giacenza; da
ciò si desume che il prezzo medio ponderato di acquisto varierà solo quando
effettuerai un movimento di carico, qualora il prezzo di acquisto della
nuova merce entrata sia diverso dal prezzo medio ponderato della giacenza
precedente.
Secondo quanto sopra scritto, il tuo esempio va così modificato:
Prima entrata
--------------
Articolo:                Pasta Barilla
Quantità:                10
Prezzo Acquisto:    200
Valore:                  2000
Giacenza
---------
Articolo:                             Pasta Barilla
Quantità:                            10
Valore:                               2000
Prezzo medio ponderato:    200
Prezzo di vendita: 300 (200+50%)
-----------------------
Uscita
------
Articolo:                             Pasta Barilla
Quantità:                            6
Prezzo medio ponderato:    200
Valore:                              1200
Giacenza
---------
Articolo:                             Pasta Barilla
Quantità:                            4
Valore:                               800
Prezzo medio ponderato:    200
Seconda entrata
--------------
Articolo:                Pasta Barilla
Quantità:                10
Prezzo Acquisto:    210
Valore:                  2100
Giacenza
---------
Articolo:                             Pasta Barilla
Quantità:                            14
Valore:                               2900 (800+2100)
Prezzo medio ponderato:    207 (Valore/14)
Prezzo di vendita: 310 (207+50%)
-----------------------
A mio avviso 310 è un prezzo equamente aumentato, mentre 315 (210+50%) è il
prezzo che a te non sembra giusto per i consumatori.
Naturalmente, con questo sistema, quando cala il prezzo di acquisto,
diminuisce (o almeno lo dovrebbe) anche il prezzo di vendita.
Spero di essere riuscito a spiegare il mio concetto.


 diminuiscono le vendite più di quanto aumenta il prezzo di vendita.
CUT
Lezione molto interessante, in effetti l'aveva detto che il suo problema non
era Access.
Come capita con la maggior parte dei clienti, il problema e' che egli stesso
non sa come funziona la propria gestione dal punto di vista manuale, cosa
che rende sorprendentemente difficile traspondere in sw qualcosa che il
cliente non riesce a definire.
La procedura FIFO non sapevo si dovesse applicare per legge, anche se e' la
piu' ovvia.
E qui ti faccio una domanda io:
Il calcolo lo fai risalendo all'indietro sulle fatture d'acquisto fino ad
esaurire la giacenza o come?
Sib
--
----------------------------------------------------
la mia home:
http://digilander.iol.it/syb
----------------------------------------------------
il sito comune di it.comp.database.access:
http://www.sitocomune.com
----------------------------------------------------
4000 anni fa', il saggio egizio Ptahhotep scrisse:
"... perche' non esistono saggi per nascita."
------------------------------------------------------
Saturiamo ECHELON:
bomba saddam attentato medio oriente

 ha scritto nel messaggio
news:YyyL7.160772$sq5.7...@news.infostrada.it...

Come ho precisato a Sergio nei messaggi successivi non deve essere il
F.I.F.O. ma deve essere "in sintonia con il sistema F.I.F.O."; il metodo di
valorizzare le scorte con il prezzo medio ponderato di acquisto è accettato
normalmente; visto che si ritiene che i prezzi tendenzialmente crescono,
quello che potrebbe essere contestato è un criterio di valorizzazione delle
scorte che sottovaluta la giacenza (ad esempio un sistema di valorizzazione
ispirato al sistema F.I.L.O.): essendo il valore della giacenza di magazzino
una posta attiva del bilancio, significherebbe diminuire l'imponibile
fiscale, e ai tempi che l'inflazione galoppava, erano bei soldini in meno di
tasse da pagare per una azienda in attivo.
Ciao
Roberto

 l'ipotesi di evasione fiscale.
Ribadisco che il programma in questione non ha nulla a che fare con la roba
fiscale :-)
Non fa bolle, non fa fatture....
Ovviamente tenendo lista del venduto e dei prezzi di vendita può fare dei
resoconti.... ma di fatto non anno alcuna validita fiscale.
Anche perchè non vi è certezza sulla veridicità dei dati inseriti.
Per le questioni fiscali ci sono i registratori di cassa e le gestioni
apposite.
Ma un eventuale ispezionatore può dire che un dato SW è fiscale quando è
esplicitamente dichiarato che non lo è?
Max

 ha scritto nel messaggio
news:r2nM7.17583$BA4.6...@news1.tin.it...

Caro Max,
Sergio ci ha detto che non doveva rispettare alcun vincolo fiscale solo con
il messaggio delle 17:30 del 23/11/2001, mentre tu stai discutendo mie
risposte inviate ai messaggi precedenti.
Ciò chiarito, visto che Sergio ha deciso di realizzare una contabilità di
magazzino sia a quantità che a valore, non vedo il motivo per cui non usare
un criterio di valorizzazione che gli permetta, oltre che a definire il
prezzo di vendita, anche di tenere i suoi libri contabili, sempre che ne
abbia bisogno naturalmente.
Inoltre mi sembra di capire che la ricarica è "equa" (senza fregare i
consumatori, come dice Sergio) solo a condizione che il montante del prezzo
di vendita sia il prezzo medio ponderato di acquisto, che puta caso è
accettato dal sistema fiscale vigente per la valorizzazione delle scorte.
Oppure sbaglio?


 risposte inviate ai messaggi precedenti.
Più che altro volevo capire cosa pensava sergio della situazione di un SW
che ho sviluppato io, e che ho prevemente descritto in una delle mie
risposte.
Max :-)