Newsgroup: it.comp.lang.visual-basic
Titolo: [OT] Movimentare un articolo ... non è solo la qtà

Scrivo questa cosa perchè troppo spesso si tende alla semplificazione di
cose che, concettualmente, sono effettivamente molto banali, ma,
realisticamente, rappresentano una delle maggiori complicazioni che io abbia
mai incontrato e che, nemmeno ora, sono convinto di aver risolto
definitivamente.
Va tutto benissimo quando quel che scriviamo soddisfa pienamente le
specifiche richieste. Ma, giustamente, tendiamo a riutilizzare
quell'importante
programma in diverse realtà, con pochi interventi di personalizzazione.
Non dico guadagnarci a sbafo, ma a recuperare, più che lecitamente,
l'investimento iniziale.
Ci risulterebbe difficile (anche per variazioni di tipo fiscale/legislativo)
avere e
mantenere più versioni o, peggio, programmi distinti.
Accade però che alla prima apparente "anomalia" scattiamo (convinti di aver
risolto egregiamente e per tutto il mondo un problema banale) e, in quel
momento, rischiamo di apparire supponenti e/o, molto più probabilmente, di
prendere una toppa micidiale. Se il nostro interlocutore ha la possibilità
di esprimere alcuni concetti (nemmeno, semplici esigenze) e se siamo
sufficientemente "aperti" alle "novità" (leggasi "lo lasciamo parlare"),
molto spesso scopriremo che lui ha ragione e i nostri tentativi di
convincerlo a fare altrimenti sono destinati a fallire miseramente e che,
soprattutto, saremo costretti a rivedere una gran parte delle cose che
abbiamo date per scontate e definitivamente risolte. Insorgerà un momento
altamente depressivo della serie "ma io non so far niente", "ma quelli sono
pazzi" o, dopo molti altri dubbi del genere, "come ho fatto a non pensarci
io, prima?". E' normale. Occorre metterlo in conto, specialmente se non si è
mai provato nulla del genere.
La cosa che troppo spesso si dà per scontata o, se si preferisce, che si
prende sotto-gamba, è che un articolo sia movimentabile a quantità.
Vero, verissimo, ma qual è il _vero_ significato (e/o utilizzo, eccezione,
peculiarità, varianti, concezioni, etc.) di "quantità"?
Siamo abituati a dire "vendo 3 pezzi di cioccolato, oppure 3 Kg di
formaggio". In questa ipotetica affermazione, più che realistica, è
racchiusa un'enormità di "stranezze" che mi picco di evidenziare.
Un mio cliente produce e vende cioccolato (non è vero, ma prima o poi
capiterà anche questo). Bene, primo terremoto, a volte lo vende a pezzi,
altre a Kg. Perchè? Perchè questa è la realtà: Al piccolo negoziante a
pezzi/stecche/tocchi/quadroni/etc., mentre alla grande distribuzione (che mi
garantisce un fatturato importante) lo vendo a Kg, pur confezionati a
pezzi/stecche/etc.
Un articolo può essere misurato con diverse unità di misura e il sistema
deve, attraverso coefficienti moltiplicatori/divisori adeguati e variabili,
accettare "quantità" dipendenti da tali possibili unità di misura.
Presumibilmente l'articolo avrà una unità di misura
"standard/privilegiata/normale", ma deve essere possibile poter esprimere
tutte le "quantità" totali (carichi, scarichi, ordini, giacenza, etc.) con
tutte le diverse UM previste dall'articolo.
Lo so, la prima cosa che vi viene in mente è di creare "n" articoli diversi
quante sono le UM previste.
Rassegnatevi, appena gli direte che per movimentare a Pezzi deve indicare un
codice, per Kg un altro, anche promettendo un programma che somma un
articolo all'altro (pensate che sia davvero semplice?), nessuno lo accetterà
e, se ci pensate bene, non piace nemmeno voi.
Certo, in alcuni casi, per lo stesso articolo può essere impossibile
prevedere dei coefficienti di conversione fra UM diverse. Si pensi, ad
esempio, alla necessità di misurare il numero di polli venduti e, nel
contempo, il loro peso. Impossibile, perchè ogni pollo pesa diversamente e
il massimo che si può ottenere è un peso medio. Non c'è soluzione, se non
quella di separare i movimenti per peso identico
(impossibile/impraticabile). L'utente non potrà che concordare e rinunciare
a qualcosa (o registrare una riga per ogni singolo pollo).
Poi, piccola ma realistica variante, ci sono le confezioni. Anche questa
appare una banalità, risolvibile semplicemente ... ignorandola. No. Se vendo
confezioni da sei lattine di birra ciascuna, devo poter indicare, con
praticità, il numero delle confezioni vendute. Il sistema banalmente farà
una moltiplica del numero delle confezioni indicate per il numero di lattine
per confezione. Quest'ultimo dato è un po' meno scontato in fase di
progettazione. Ma, io, produttore di birra, quanta birra ho venduto? Bene,
1000 confezioni pari a 6000 lattine, ma quanta birra, ho detto? Serve un
altro dato: la quantità per unità di misura. Per esempio 33 cl. Ora,
tornando alle varie UM, come misuro la mia birra? Beh, non ci si scappa:
Confezioni, Lattine e Litri. Perchè lattine? Perchè (bastarde eccezioni!)
devo poter vendere anche due lattine di birra. Non devo essere obbligato a
vendere confezioni "intere" da 6.
Un'altra realtà, particolare, se volete, ma affatto eccezionale.
Io costruisco strumenti di misura lineare in ferro. Sì, sono il solo al
mondo, ma faccio questo: Stecche di ferro graduate e tagliate a 1 metro o a
2 metri. Con un po' di fantasia, ammetterete che l'esempio non è poi così
strano (barre lavorate, tubi, trafilati, etc.). Giusto qualche nota:
Acquisto le barre di ferro grezze a Kg (è la realtà), vendo le barre finite
a pezzi. Alcuni da 1000 mm, altri da 2000 mm.
Facile? Affatto! Ogni movimento per uno _stesso_articolo_ deve disporre del
numero dei pezzi, della loro dimensione unitaria e dell'unità di misura. Dal
tutto si può pervenire (magari sempre attraverso i coefficienti citati, da
confermare da parte dell'operatore movimento per movimento) alla generica
"quantità". Tralascio, volutamente, i problemi che nascono in fase di
produzione. Eggià, perchè per produrre quel pezzo finito, parto dalla barra
grezza e la devo tagliare. La lama (che ha una sua dimensione,anch'essa da
prevedere) provoca sfrido e le
finiture presumono una dimensione lineare di impiego maggiore di quella
finita.
Mi fermo e cito indirettamente il senso dello spunto da cui sono partito:
"leggo col codice a barre il codice dell'articolo e digito (o rilevo da
numerelli già codificati) la quantità". Può non bastare. A volte l'unità di
misura
è necessaria. Altre, anche la dimensione unitaria.
Morale:
"Scriviamo quel che vogliamo e possiamo, ma non diamo mai per certo
che basti sempre e ovunque. I "miracoli" li fa solo il governo che,
dall'oggi al domani, riesce a decretare potabile quell'acqua che sino a ieri
era avvelenata. Basta alzare il limite di tolleranza, checcefregaanoi?"

 racchiusa un'enormità di "stranezze" che mi picco di evidenziare.
Ricordi il thread sul magazzino, con le mie paranoie sulle tabelle dei
magazzini, delle ubicazioni e, forse ti è sfuggito, delle unità di misura.
Io uso una tabella UM, in cui ogni unità di misura ammessa è codificata, con
tanto di descrizione breve e estesa.
Ogni giacenza, movimentazione, ecc..., viene sempre identificata da codice
articolo, ubicazione di partenza, ubicazione di arrivo o giacenza, quantità,
unità di misura, unità di condizionamento (imballaggio), ecc...
Lo stesso articolo, quindi, può essere giacente in magazzino in
condizionamenti diversi (ho un sacco di cacao da 10kg, e un barattolo di
cacao da 200g: lo stesso cacao, potenzialmente mescolabile e vendibile in
una unica fornitura).
Con una semplice tabella di conversione fra um e condizionamenti, posso (e
qui dipende dalla logica del cliente), effettuare rettifiche di magazzino
cumulando o meno le diverse situazioni.
Nell'esempio precedente, se il cliente vuole la giacenza complessiva di quel
cacao, posso dirgli che è di 10200g, o 10,2Kg.
Posso anche dirgli dove e come è distribuito.
Ovviamente, si aumenta la complessità delle query che ricavano le
informazioni, visto che i "LEFT OUTER JOIN" diventano una costante, ma alla
fine si ha una flessibilità.
E' stato bellissimo, in diverse occasioni, avere il cliente che, di fronte
ad una demo in cui credeva di fregarmi dicendo "ma da noi i movimenti sono
gestiti in un altro modo...", io inserivo la password admin, cambiavo alcune
voci nelle tabelle um, condizionamenti, tipi movimento, conversioni, e
tornavo ad operare come utente esattamente come voleva lui :-))
Ciao
Alberto

Un cliente che chiede una struttura di consultazione Business Intelligence
con poca spesa , tipo: interfaccia user costruita
VB6 e dati in Access , con prezzi molto scontati, presumo che le difficoltà
di raggiungere l'obbiettivo siano quasi
impossibili.
Se invece è possibile proporre architetture OLAP , ed è disposto ad
investire in , hardware , formazione del personale o
assumere personale specializzato , e retribuirlo adeguatamente , presumo che
il numero degli ostacoli diminuisca
proporzionalmente.
giuseppeD

 proporzionalmente.
Sai a quanto vendo il mio magazzino? 700 euro + (circa) 100 per ogni
postazione aggiuntiva.


Il mio intervento era un discorso generale , non riferito nello specifico.
Mi sono trovato in situazioni di rifiutare lavori perchè il cliente chiedeva
soluzioni che comportavano tempi e soluzioni superiori alla spesa
preventivata. E non sempre per mancanza di risorse ma a volte per una
considerazione superficiale o facilistica.
Chiedere , prendiamo ad esempio case produttrici di abbigliamento dove le
variabili sono elevate e si vuole una risposta immediata incrociando il
tessuto,la dimensione,la tagla,il modello,il colore,le date,il paese,la zona
del paese,ecc. , con un sistema di reportistica tipo standard neccessita un
bel po' di lavoro , con un sistema tipo Business Object ottengo risposte
complesse in tempo reale con un semplice drag-and-drop e superiori al
classico report.
Ma per utilizzare programmi di BI devo investire .......
In questo senso era diretto il mio intervento.
giuseppeD

 ha scritto nel messaggio
news:b0v6m6$tuhug$1...@ID-174464.news.dfncis.de...
Ciao caro Lupo.
Sei sempre al can che si morde la coda.
Io ho capito perfettamente cosa cerchi e cosa vuoi fare.
Un'idea ben fatta ce l'ho e te la proporrò.
Il lavoro è simile alla MF con qualche variante di poco conto.
Non conta quanto o in cosa il cliente vuole spendere. Conta il concetto che
hai espresso.
Un'applicazione deve essere unica per una casa di soft.
Per legge deve rispettare alcuni standard e fin qui è facile.
Poi col cliente la musica cambia. Per utopia (mica tanta) gli stessi dati
esposti in maniera diversa fanno sembrare un programma più appetibile di
altri.
Allora diventa importante che l'applicazione diventi "portante".
Supponi che io mi inventi un'infinità di campi che gestisco per fatti miei.
L'unica cosa che alla fine mi serve è un totale da mettere in fondo a una
fattura o in un movimento.
Che ti frega di maneggiarne la gestione di questo totale. Fallo fare
all'utente. L'importante è che alla fine LUI decida quale totale dei suoi
debba abbinare a quello che tu gli chiedi. FINE.
EXCEL alla fine lavora così. Celle su celle, alcune doppie per comodità di
lettura, ma alla fine sei tu che decidi quali_dove_come_e_se computare nelle
celle di totalizzazione.
Il problema principale di applicazioni lineari realizzate dalla maggior
parte delle case di soft è e sarà sempre quello di tentare di risolvere il
problema "DEL" cliente.
Se i clienti sono tutti dello stesso settore o similare il problema è
piccolo, altrimenti........
Te ne stai accorgendo anche tu dall'incasinamento generale delle tue
maschere.
Dati su dati che potrebbero andar bene per tutti, ma che singolarmente
vengono usati per la metà di propria competenza dall'utente in questione
con, però, un sovraccarico immenso nei DB e non per ultima la paura del
cliente davanti alla maschera ammucchiata di dati di un carico di magazzino.
"Ma a me servono solo due cose delle mille che lei chiede e poi qui non le
vedo nemmeno."
L'idea ormai l'avrai capita.
Col potenziale che hai già creato la soluzione ce l'hai a portata di mano,
ti serve solo sganciarti dal quotidiano e pensare.
Ci sono cose che devono essere fatte così per legge.
Ci sono cose che servono al singolo cliente.
Come faccio a creare una cosa che vada bene per tutti e non mi crei problemi
con gli aggiornamenti?
Medita, medita.

 con gli aggiornamenti?
Ma io l'ho fatta. Non capisco. :-(

Sdrammatizzando un po ....
ma non e' che adesso mi verranno a chiedere quanti kgdi salme hanno ? Oppure
quanti mc di terra dovranno spostare ogni anno ? ^_^
-- 
<Gigio2K>
Sito Comune
Nokia -> I.T.H.N. -> 
http://www.ithn.it/
VB -> I.C.L.VB -> 
http://www.it-lang-vb.net/