Newsgroup: it.comp.appl.access
Titolo: Gestione Vendita Tappeti

Ciao a tutti,
qualcuno ha avuto occasione di realizzare un db per la gestione della
vendita di tappeti? Vorrei scambiare un paio di idee e avrei bisogno di
un parere.
Paolo

In che zona č?
Quanti punti luce?
Mi dici la metratura del locale?
Il canone per la Gestione č compreso il fisso??
-- 
_ _
Ciao
MAssimiliano Amendola            
www.accessgroup.it
Cisa - Conferenza Italiana per Sviluppatori Access
Info:  
www.donkarl.com/it

Ti spiace spiegarmi la battuta? :-)

Vorrei scambiare un paio di idee e avrei bisogno di un parere.
Vai... spara...
-- 
Ciao
----------------------------------------------------------
:: Pablitomf (Maurizio Facciuti)
:: Access : Ver.97 - 2K
----------------------------------------------------------
http://www.accessgroup.it/
http://www.sitocomune.com/
http://www.napolisoccer.it/
----------------------------------------------------------
La mia tesi :
"Non mi fido molto delle statistiche, perchč un uomo con la testa nel forno 
acceso e i piedi nel congelatore statisticamente ha una temperatura media." 

 Ti spiace spiegarmi la battuta? :-)
Seeeeeeee....!!!! e che siamo inglesi noi? :-D 

 Ti spiace spiegarmi la battuta? :-)
Sì scusa.
Su questo NG si usano subject esplicativi del tenore del post.
In realtà come l'hai posto tu sembra più un annuncio commerciale di offerta
di gestione di un punto vendita che una richiesta tecnica.
Ci sono molti modi per enunciare un post del genere ma tutti dovrebbe essere
segnati da un OT.
se vuoi leggere qualcosa su come postare puoi leggere
www.accessgroup.it/notiquette.htm
Attieniti e mi offro sin d'ora a iscutere con te su come impostare il db


Vabbè, poi capirò
Tornando al mio problema, avrei bisogno di qualche idea su come
registare le infinite azioni che si svolgono attorno alla vendita di un
tappeto.
Un tappeto ha questo iter:
Entra in magazzino
Viene venduto o dato in conto vendita o è un reso o va in manutenzione
Devo registrare ogni singola azione come se dovessi costruire una
"vita" del tappeto.
Per ora il db consente di immettere i dati cliente, per ogni cliente
infinite transazioni e per ogni transazione le varie modalità di
pagamento.
Come è strutturato adesso, quando un tappeto viene venduto, è in
relazione alla rispettiva transazione ed ha un suo stato (venduto, reso
etc...), se modifico lo stato con quello attuale, perdo il suo stato
precendente.
L'idea è quella di aggiungere altre cifre/lettere al suo codice (che
è pure chiave primaria) in modo da poter duplicare ogni tappeto con un
nuovo stato.
Es:
codice 12345   nuovo codice 12345V1 dove V=Venduto 1 numero progressivo
Altre idee?

Ah, pardon hai perfettamente ragione.
Avevo fretta di postare e non sono stato preciso, sorry! :-)

Altre idee?
Allora mettiamo dei paletti fissi... una cosa è l'articolo, una cosa è la 
movimentazione dello stesso.
Quindi la prima cosa da avere chiara è tale distinzione, che di fatto si 
riversa in una distinzione fisica della posizione dei dati, infatti vi deve 
essere una Tbl_Articoli e una Tab_Movimentazioni
Nella Tbl_Articoli dovrai inserire tutte le informazioni che ritieni 
necessarie, inerenti alle sole caratteristiche fisico/tecniche dell'articolo 
stesso
Nella Tbl_Movimentazioni collegata alla Tbl_Articoli magari dal Codice 
Articolo (che presumo non duplicabile) inserirai tutte le informazioni 
inerenti alla movimentazione dell'articolo di riferimento.
Partendo da tale base tu avrai per ogni articolo una storia della sua 
movimentazione sia in entrata che in uscita... ovviamente la 
Tbl_Movimentazione potrà essere corredata dalle più svariate notizie che ti 
faranno muovere liberamente nella gestione completa del magazzino... potrai 
infatti distinguere le movimentazioni in ENTRATA e USCITA, potrai 
eventualmente collegare la movimentazione a un ID_ClienteFornitore per 
risalire da chi lo hai acquistato o a chi lo hai venduto...ecc. ecc.. ecc..
Perplessità? 

Già provato! Il fatto è che il cliente vorrebbe evitare, se
possibile, di inserire manualmente ogni nuova movimentazione.
L'idea di aggiungere altre cifre/numeri al già esistente codice era
questa:
transazione numero 1A
codice tappeto: 123   tralascio gli altri campi (prezzo, dimensioni
etc..) Stato: Venduto (lo stato si seleziona da una casella combinata)
transazione numero 1A
codice tappeto 123R1            Stato: Reso
transazione 1A
codice tappeto 123C1         Stato: In Conto vendita
Alla fine si potrebbe utilizzare una query del tipo " 123** " per
filtrare tutta la movimentazione del tappeto
Commenti?


Scusa ma non inserisce lo stesso le info
Le chiami in maniera diversa ma sempre una transazione è.
Concordo con Pablitomf solo che nel tuo caso aggiungerei un campo nella
tabella articoli
in cui denunci lo stato (ven-In conto ven- in magazzino)
in cui versa il tappeto


 in cui versa il tappeto
Certo... questo era una di quelle tante possibilità di cui parlavo nel post 
precedente... puoi effettivamente poi sbizzarrirti nel monitorare quanti più 
processi tu possa intendere monitorare... magazzino, fatturazione, 
contabilità e chi più ne ha più ne metta.
Concordo con MA per l'inserimento di Info... alla fine come le chiami le 
chiami, sempre notizie sono... per la gestione delle cose, c'è sempre 
bisogno di un archivio... alla fine se non sai come vanno le cose 
analizzando la storia delle stesse, come fai a gestirle in maniera 
ponderata?... E' vero che ognuno decide il cosa fare in relazione al cosa 
necessita fare, ma il cliente va comunque esortato a seguire anche i 
consigli di un consulente/programmatore più che un esecutore e basta. 
Scusami ma al tuo cliente non interessa sapere dell'Articolo XY in data XX 
quanti pezzi erano in magazzino, o quanti ne sono arrivati o quanti ne sono 
ritornati indietro e perchè? Sono notizie utili per una gestione di 
magazzino... anzi vitali, altrimenti non è un magazzino, ma un cassetto del 
proprio guardaroba. ;-)

Grazie per le idee!
Purtroppo i tappeti sono diversi dai comuni prodotti "industriali",
ognuno è un prodotto a sè e il cliente vuole un sistema che tenga
traccia di tutto. E voi direte "ovvio"! Si, però non è facile tenere
traccia delle sue azioni, ecco un problema tipo (cifre reali):
Il cliente X compra 2500 tappeti, 1000 li paga (e qui si deve dividere
per metodi di pagamento, se in caso di assegni il db deve pure gestire
gli assegni tramite numero, data emissione data incasso, banca etc);
500 li prende in conto vendita, 1000 li paga a rate (e qui va il
sistema completo di gestione delle rate).
Ora, questa è la parte facile, poi viene la difficile:
dei 500 in conto vendita, il cliente ne riporta 100 perchè non li
vuole, gli altri 400 li paga a rate. Dei 1000 pagati in contanti,
tornano come reso 150 tappeti e il cliente vuole che i soldi gli
vengano detratti dal pagamento rateale di tappeti diversi etc etc
Si va avanti così all'infinito e si deve tenere traccia di
tutto...credo di essere il 3° o 4° che si cimenta nell'impresa


E questo è tutto???
non ti preoccupare gestiamo casini più complessi...
se ti va di lavorare su questo progetto è fattibilissimo
Tenendosi largo... due giorni di lavoro


Ah, vabbè!
A me risulta che hanno mandato in crisi parecchia gente (almeno 3).
I miei predecessori avevano optato per il codice a barre, soluzione
andata in fumo per via del numero abbastanza elevato di prodotti, ci
sarebbe voluta una squadra solo per etichettare i tappeti
Fattibile è fattibile, non sono daccordo sul tempo totale che credo
sarà più lungo
Dimenticavo, per ora sto facendo tutto in Access


Tutto in Access come dici tu
Ti do i volumi di una mia applicazione
130MB
10 utenti che fanno di tutto (comprano, vendono, danno in conto visione,
imputano pagamenti, fanno fatture, prima nota cassa, ordini etc..)
In questo momento
record delle Ricevute di vendite 50147
Record della vendita 246410
record tabella Acquisto 65442
record tabella  articoli diversi per quantitativi impressionanti 17948
record di una tabella che verifica che fa un carico scarico differenziato
(come riprova delle eventuali castronerie che fanno gli utenti alla vendita)
275367
soli 19078 record per la tabella ordini...
continuo???



Ah, dimenticavo 4 anni 6 mesi di esercizio del mio db
6 programmatori provati in precedenza per raddrizzare il workflow
Prima di me solo carta e penna e un magazzino di 2000 articoli (inventario
fatto quando abbiamo cominciato)


Carta e penna? Loro stanno meglio: tutto in excel!!
Il problema è proprio l'inventario, dovremo farlo anche noi ma qui
parliamo di circa 25.000 ognuno con tutti i dati diversi (non esistono
stock o partite dello stesso prodotto)
Altra richiesta, proprio a causa del numero degli articoli, è stata di
fare l'inventario (dei prodotti presenti) all'incontrario : aggiungerli
man mano che si vendono sennò ci vorrevvero due mesi di chiusura totale

man mano che si vendono sennò ci vorrevvero due mesi di chiusura totale
Che caos così... e che magazzino è?!!!!! il magazzino ha delle regole, e una 
disciplina... e se non si rispettano come è giusto che sia, risulta 
ingestibile. 

 ha scritto nel messaggio news:1126805052.9...@z14g2000cwz.googlegroups.com...



[risposta]
Non avrai mai in tempo utile le giacenze; allora inizia ad inserire gli "ultimi arrivi" e vai a ritroso, oppure quelli che sai già 
se saranno venduti non quelli che sono venduti...
Ciao.
-- 
Sergio MAZZA 

 chiusura totale
Io ti consiglio l'ambiente misto.
Codificare man mano che vengono venduti e di fianco iniziare con quelli che
potenzialmente puoi vendere prima.
Mettiti l'animo in pace, bisogna lavorare molto


Avevo postato un altro messaggio ma sembra sparito, ricomincio:
Loro sanno perfettamente cosa hanno in magazzino e cosa no, se è per
questo sanno pure trovare un tappeto preciso in mezzo ad altri
ventimila! Per questo ho optato per dargli la possibilità di "fare
inventario" anche durante una vendita, cioè inserendo i dati degli
articoli che stanno vendendo, oltre ovviamente la classica maschera
inventario.
Le tabelle sono già tutte al minimo possibile, per ora
Anagrafica Clienti
Magazzino --> dati articoli
MovimentazioneArticoli --> vita morte e miracoli degli articoli
Contabilità
Pagamenti -->c'era la necessità di scorporare soldi in assegni da
contanti etc...
GestioneAssegni
MovimentazioCliente --> quanto compra, quando renstituisce etc..
In excel loro hanno dei dati che poi importerò ma i loro codici
articolo possono avere dei duplicati e non li posso eliminare per cui
dovrò costruire un nuovo codice pk
Un altra domandina: esiste la possbilità di seguire questo processo
(mi serve per una sola tabella)
1) Apro una maschera collegata alla tabella "Secure"
2) La compilo
3) Salvo i dati crittografandoli sulla tabella
     Questo è il problema, a me servirebbe una crittografia vera e
propria, minimo 128bit, non una funzione di     trasposizione! O
meglio, sti dati devono essere veramente sicuri
4) I dati possono essere decrittati e visti solo dalla maschera
Follia?