Newsgroup: it.comp.programmare
Titolo: Problema unità di misura in applicazione gestionale

Salve a tutto il newsgroup.
Vi pongo una questione che mi ha dato molto da combattere e a tuttora 
non riesco a dare una giusta soluzione.
Vi spiego il mio problema:
Gestionale che permette di caricare prodotti in magazzino:
Supponiamo che carico 10 confezioni di coca cola (ogni confezione 
contiene 6 lattine) (il codice della coca cola è aaa)
Siamo in fase di vendita :
Cliente c1 acquista 1 lattina di coca
Cliente c2 acquista 1 confezione di coca
Richiamando il prodotto con il codice aaa per il cliente c2 nessun problema
Richiamando il prodotto con il codice aaa per il cliente c1 è come se 
gli vendessi una confezione.
In questo scenario qual'è la soluzione informatica che mi permetta una 
veloce operazione di vendita ??
Per non considerare poi il caso di scarico di magazzino all'atto di vendita.
Aggiungo che il tutto va gestito con dei codici a barre.
C'è qualcuno che si è mai occupato di questi problemi ???
Sono a vostra disposizione per un  confronto su questi argomenti.
Ad es. quendo vado al supermercato, carica la lattina o la confezione.
Sono 2 codici diversi ?? è come se sdoppiassero il prodotto con 2 codici 
diversi ??

 diversi ??
Per quanto riguarda le confezioni di Coca Cola non ricordo esattamente, 
ma ho ben presente il caso delle confezioni delle bottiglie d'acqua 
minerale.
In gergo tecnico, la confezione da 6 bottiglie di acqua minerale, si 
chiama "fardello" e ha un suo codice a barre che e' diverso da quello 
della singola bottiglia.
I programmi di gestione del punto cassa, e quelli di gestione magazzino 
dovrebbero prevedere questi prodotti "fardello", e creare un legame tra 
il fardello e l'articolo singolo, nonche' indicare la quantita' di 
articoli presenti nel fardello.
Quindi si tratta di prevedere nel record dell'articolo dei campi in piu' 
per la gestione del fardello.
un flag booleano che indica se l'articolo e' un fardello
un campo quantita' che indica il numero di elementi
un campo codice_articolo che indica l'articolo singolo del fardello
Questo e' il caso piu' semplice.
I casi piu' complessi sono i "cesti natalizi" che sono dei contenitori 
con un loro codice a barre e al loro interno contengono diversi articoli 
in vendita (panettone, torrone, bottiglia, etc...)
Se devi prevedere anche cose del genere allora e' il caso di gestireuna 
tabella separata che contiene gli elementi del fardello.
Una volta definita la struttura dati, il software di vendita e quello di 
gestione magazzino devono adeguarsi.
Purtroppo non ho piu' sottomano niente perche' sono piu' di 5 anni che 
non mi occupo di software di grande distribuzione: vado un po' a memoria.
Ma questa situazione la ricordo abbastanza bene perche' e' stata ostica 
non poco.

veloce operazione di vendita ??
Io farei nel modo seguente, dimmi se ti piace.
Premesso che:
- una confezione di articoli (cassa, confezione generica, aggregazione
di articoli per un'offerta con sconto, cesto natalizio, ecc..) è un
articolo essa stessa ed ha codice a barre X;
- l'articolo eventualmente contenuto nell confezione ha codice a barre
Y (diverso da X);
avrai uno scenario del genere (la faccio semplice):
ARTICOLO:
- id_articolo (PK);
- descrizione
- id_tipo_articolo (FK su TIPO_ARTICOLO)
- prezzo_vendita
- ...
TIPO_ARTICOLO:
- id_tipo_articolo (chiave primaria)
- descrizione ("singolo"/"multiplo")
CONFEZIONE:
- id_articolo_1 (in PK) (id dell'articolo "multiplo")
- id_articolo_2 (in PK) (id dell'articolo "singolo")
- quantita
Esempio di dati:
TIPO_ARTICOLO:
------------------------------
id_tipo_articolo | descrizione
------------------------------
       1         | singolo
------------------------------
       2         | multiplo
------------------------------
ARTICOLO:
-----------------------------------------------------------
id_articolo | descrizione          | id_tipo_articolo | ...
-----------------------------------------------------------
     1      | coca cola            |       1          |
-----------------------------------------------------------
     2      | conf. 2x coca cola   |       2          |
-----------------------------------------------------------
     3      | acqua minerale       |       1          |
-----------------------------------------------------------
     4      | cassa 6x acqua min.  |       2          |  
-----------------------------------------------------------
...
CONFEZIONE
------------------------------------
id_articolo | id_articolo | quantita
------------------------------------
     2      |      1      |    2    
------------------------------------
     4      |      3      |    6    
------------------------------------
Ogni articolo può essere singolo o multiplo (confezioni).
La tabella CONFEZIONE rappresenta una relazione "molti a molti" tra
articoli e mette in relazione sé stessa con gli articoli contenuti.  
In realtà la tabella TIPO_ARTICOLO è ridondante: se un articolo non è
una confezione, nella tabella CONFEZIONE non apparirà nessun record in
relazione suo suo id, però verificare questo stato con una join può
risultare pesante.
Questa struttura supporta bene casi anche complessi, come il cesto
natalizio, aggregazione eterogenea di articoli e che a sua volta
potrebbe contenere confezioni.
All'atto del caricamento del magazzino, gli articoli singoli
incrementano di uno la propria giacenza, mentre le confezioni
(articoli multipli) vanno ad incrementare della quantità specificata
nella tabella CONFEZIONE, la giacenza degli articoli in esse
contenuti.
Ovviamente, se l'articolo contenuto è ancora una confezione, si avrà
un effetto a cascata, sino a che non si raggiunge gli articoli
singoli.
Quando si scarica un articolo singolo, di decrementa di uno la sua
giacenza, mentre scaricando una confezione, analogamente al carico, si
va a decrementare della quantità relativa ogni singolo articolo in
essa contenuto.
Tutto ciò ha il vantaggio di gestire quei casi come lo "smembramento"
di una cassa d'acqua, per accedere alle singole bottiglie (lo si fa
spesso nei supermercati). Quando si caricano 10 casse da 6, in realtà
si stanno scaricando 60 bottiglie; se si vendono 5 casse, vuol dire
che si vendono (e si scaricano) 30 bottiglie.
Le confezioni possono avere anch'esse una giacenza, ma è poco
significativa, proprio perché vengono caricate come confezioni, ma
scaricate come prodotti singoli.
Ovviamente, se calcolando la giacenza, risulterà che la quantità di
confezioni è >= al numero di prodotti singoli, vuol dire che
*presumibilmente* quelle confezioni realmente esistono, altrimenti
sono dati "zombie" e la loro giacenza può essere sicuramente azzerata.
In ogni caso, la giacenza delle confezioni non è significativa.
Metti per esempio il caso in cui vi siano 2 casse d'acqua e 5
bottiglie singole (= 17 bottiglie totali). Se io compro 1 cassa e 3
bottiglie singole, scarico 6 + 3 = 9 bottiglie, ma io scarico anche la
cassa, quindi la giacenza è coerente: ci sono 1 cassa e 3 bottiglie in
meno (17-6-3 = 8 bottiglie). Se il cliente successivo smembra una
confezione per prendere 2 bottiglie solo, io scarico 2 bottiglie
(8-2=6 bottiglie), pur risultando ancora una cassa giacente.
Il terzo cliente prende le ultime 6 bottiglie d'acqua ed io scarico 6
bottiglie, ma rimane sempre una cassa giacente. La giacenza delle
bottiglie è 0 (zero), mentre quella delle casse è 1. Si tratta quindi
di un dato "zombie" che può essere sicuramente azzerato.
Dico che la giacenza delle confezioni non è un'informazione affidabile
perché se ammetti di avere 3 confezioni d'acqua e ogni cliente lascia
in ogni confezione 2 bottiglie, alla fine avrai 3 confezioni giacenti
e 6 bottiglie d'acqua giacenti. Da qui potrai dedurre che 2 confezioni
sicuramente non ci sono più, ma una potrebbe esserci oppure no
(difatti non c'è come confezione sana).
Spero di averti aiutato e non averti confuso ulteriormente le idee.
E' tardi e potrei aver fatto qualche errore di valutazione ;-)

 scaricate come prodotti singoli.
Infatti le confezioni non avevano giacenza.
Il magazzino contiene solo l'inventario dei prodotti singoli.
E' solo in vendita, che quando passa il codice di una confezione, vengono
sottratti i quantitativi dei componenti.
Nel carico dell'acqua minerale ogni codice di fardello incrementa di 6 il
quantitativo delle bottiglie.
Mentre i cesti natalizi vengono confezionati in negozio e di questi non
c'e' carico di magazzino.
Piuttosto, ora che mi ricordo, uno dei problemi legati ai cesti natalizi
era la suddivisione del prezzo perche' praticamente mai il prezzo del
cesto natalizio corrisponde alla somma dei prezzi degli articoli che
contiene.
Ma qui entriamo nel campo delle promozioni e degli sconti ed entrano in
gioco altre tabelle e la cosa si complica.
Un altro aspetto infine, che non e' proprio il punto di questo thread ma
che ci somiglia, ed e' una bella rogna, sono i pacchetti delle bilance del
banco gastronomia/salumeria e simili.
Quando vai al banco salumeria e chiedi 2 etti di prosciutto e 1 di salame,
il salumiere affetta, pesa e alla fine consegna un pacchetto con sopra un
codice a barre che indica il prezzo del contenuto complessivo.
In questo caso lo scarico di magazzino viene fatto la notte, durante le
elaborazioni notturne, incrociando quel codice a barre, con il log
prodotto dalle bilance.
La bilancia quando stampa uno scontrino scrive in una sua tabella il
dettaglio del contenuto (2 etti di prosciutto x e un etto di salame y)
e le procedure notturne vanno ad incrociare questi dati per calcolare i
quantitativi di venduto del prosciutto e del salame...
In gergo tecnico questa operazione viene chiamata "spacchettamento delle
bilance"
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 contiene.
Ma infatti č anche per questo che ho considerato la "confezione" come un
articolo proprio, perché ogni articolo ha un suo prezzo e il prezzo della
confezione potrebbe essere inferiore alla somma (vedi il classico 3x2).


Andrea Laforgia ha scritto:

Ciao Andrea e grazie della risposta.
Ho letto la tua soluzione: Semplice in effetti ma su certi punti diventa
contorta.
Ad esempio:
Nella gestione del listino.
Premetto che non ho molta esperienza su questo campo.
Mi sto cimentando in questa applicazione per la gestione di un
negozio di alimentari ad uso familiare ma che però gestisce tutte quelle 
situazioni che avete illustrato come cesti natalizi e aggregati di prodotti.
Ora il punto è:
Carico il magazzino con 100 confezioni di acqua.
Devo modificare il listino:
Quindi devo gestirmi sia il listino della confezione d'acqua e sia 
quello della bottiglia singola.
Nel caso della coca poi:
Listino confezione da 6
Listino confezione da 2
listino singola lattina.
Un pò dispersivo, no ??

 Un pò dispersivo, no ??
No! :-)
Considera che sono _articoli diversi_, ognuno con il proprio _codice_.
Quindi non ti cambia nulla, è solo un articolo in più a cui modificare
il prezzo.
Come tu stesso (o qualcun altro, forse) hai detto, il prezzo della
"confezione" è spesso diverso da "numero elementi * prezzo singolo
elemento"... quindi quando modifichi il listino, necessariamente dovrai
modificare anche i prezzi delle varie confezioni (da 6, da 3, da 2)...
Sperando di esser stato d'aiuto,
David
-- 
         Linux Registered User #334216
Get FireFox! >> 
http://snipurl.com/gofoxygo/
 <<
Blog         >>  
http://www.hanskalabs.net/
  <<
Staff        >> 
http://www.debianizzati.org/
 <<

 quello della bottiglia singola.
Certo, è ovvio, sono articoli di fatto diversi, ognuno con un suo prezzo.


 scaricate come prodotti singoli.
Infatti le confezioni non avevano giacenza.
Il magazzino contiene solo l'inventario dei prodotti singoli.
E' solo in vendita, che quando passa il codice di una confezione, vengono
sottratti i quantitativi dei componenti.
Nel carico dell'acqua minerale ogni codice di fardello incrementa di 6 il
quantitativo delle bottiglie.
Mentre i cesti natalizi vengono confezionati in negozio e di questi non
c'e' carico di magazzino.
Piuttosto, ora che mi ricordo, uno dei problemi legati ai cesti natalizi
era la suddivisione del prezzo perche' praticamente mai il prezzo del
cesto natalizio corrisponde alla somma dei prezzi degli articoli che
contiene.
Ma qui entriamo nel campo delle promozioni e degli sconti ed entrano in
gioco altre tabelle e la cosa si complica.
Un altro aspetto infine, che non e' proprio il punto di questo thread ma
che ci somiglia, ed e' una bella rogna, sono i pacchetti delle bilance del
banco gastronomia/salumeria e simili.
Quando vai al banco salumeria e chiedi 2 etti di prosciutto e 1 di salame,
il salumiere affetta, pesa e alla fine consegna un pacchetto con sopra un
codice a barre che indica il prezzo del contenuto complessivo.
In questo caso lo scarico di magazzino viene fatto la notte, durante le
elaborazioni notturne, incrociando quel codice a barre, con il log
prodotto dalle bilance.
La bilancia quando stampa uno scontrino scrive in una sua tabella il
dettaglio del contenuto (2 etti di prosciutto x e un etto di salame y)
e le procedure notturne vanno ad incrociare questi dati per calcolare i
quantitativi di venduto del prosciutto e del salame...
In gergo tecnico questa operazione viene chiamata "spacchettamento delle
bilance"
-- 


 Eh sě, ma "prevedere", in termini informatici, significa "progettare bene"
Questo e' innegabile.
Dovendo cominciare ex novo a progettare l'informatizzazione di un punto
vendita, si puo' tener conto di queste situazioni e predisporre la base
dati per poterle gestire elegantemente.
Purtroppo la dura realta' e' fatta di programmi, procedure e basi dati,
scritti *prima* (e per prima intendo una dozzina abbondante di anni fa),
quando le esigenze erano diverse, la scontistica non era cosi' elaborata,
e la potenza delle macchine non lasciava spazio ai fronzoli.
Quando poi successivamente gli uffici commerciali si sono inventati gli
sconti 3x2, o gli sconti del tipo se compri questo, quello ti costa meno,
i cesti natalizi ricorsivi e altre cose che non mi vengono in mente,
bisognava far funzionare le cose con la struttura che c'era.
Se l'amico che ha aperto il thread deve scrivere tutto ex novo, e' bene
che imposti una bella struttura elastica, come quella che hai suggerito
tu, a cui aggiungo il consiglio di non usare il codice a barre come chiave
primaria, ma sempre un codice articolo definito dal negozio.
Perche' le lattine di coca, tanto per fare un esempio, possono avere
codici a barre diverso.
La cassa legge il codice a barre, da questo risale al codice articolo del
negozio, e quindi e' possibile aggiornare il magazzino della coca cola in
lattina.


 
Ti ringrazio dell'ultimo suggerimento.
Nei test avevo già previsto questa situazione e modificato la base dati 
in funzione di ciò.
Il problema è che non tutto si può prevedere e per questo sto cercando 
suggerimenti da gente che ne si è scontrata con questi problemi.

popiero70 ha scritto:

Vedo che l'argomento ha convolto molti utenti.
Sono contento.
Vi chiedo:  conoscete qualche sito dove sono presenti contenuti utili ?
Tipo esempi di base dati sull'argomento ??
Thanks

 suggerimenti da gente che ne si è scontrata con questi problemi.
Poi c'e' anche il caso degli articoli a peso.
Le bilance self service della frutta per esempio, oppure le confezioni 
di carne o pesce, per i quali il codice a barre, indica il codice 
bilancia e il prezzo di vendita.
Poi in fase di riconteggio, dal prezzo si risale al peso, e si puo' 
aggiornare il magazzino.
Pero' questi codici li generano le bilance, e le bilance hanno il loro 
database con codice articolo e prezzo al chilo.
Questi database delle bilance hanno un formato proprietario, ma vengono 
fornite con dei programmi per interfacciarsi col database del negozio.
Poi ci sarebbe tutta la parte di promozioni e sconti.
Sconti sull'articolo, sconti sul reparto, sconti per supero di una certa 
quantita', sconti MxN, punti fedelta', sul totale della spesa o sul 
singolo articolo.
Poi la cassa deve poter gestire i resi e gli storni.
Poi ci deve essere pure dell'altro che ora non mi ricordo, ma se ne 
parliamo ancora un po' magari mi ritorna in mente.
Ci ho lavorato parecchio tempo con le casse della grande distribuzione, 
annessi e connessi.
Prima per implementare una gestione di tessere fidelity, poi per l'anno 
2000, poi per il passaggio lira-euro...

 bilancia e il prezzo di vendita.
Una curiosità...
Quanti bit vengono memorizzati in questi codici a barre?
E.

?manu* ha scritto:

I codici a barre sono rappresentati con delle stringhe alfanumerche, non 
con dei bit.
I piu' diffusi nel commercio sono gli EAN-13, ma poi ce ne sono di altri 
tipi.
Il lettore di codice a barre ritorna sempre una stringa, della lunghezza 
corrispondente al tipo di codice, ma al massimo si arriva ad una ventina 
di byte.
Nel caso degli EAN-13, che sono lunghi 13 byte, mi pare di ricordare che 
i primi 3 byte indichino la nazione del produttore, poi ci sono 5 o 6 
byte che sono il codice del produttore, e i rimanenti meno uno sono il 
codice dell'articolo del produttore.
L'ultimo byte e' un check digit che si ricava in funzione dei precedenti 
con una semplice formula di somme e moduli.
Credo che si trovi ampia documentazione in rete sui codici a barre, 
cercando su google BARCODE e magari EAN

popiero70 ha scritto:

Supponiamo avere un db di questo tipo:
Tab1:Articoli            Tab2:CodiciArticoli         Tab3:ArtAggregati 
cmp:IdArticoli----->     cmp:IdArticolo              cmp:IdArtPrincipale
cmp:Descrizione          cmp:CodiceArticolo          cmp:IdArtMultiplo
                          cmp:Descrizione             cmp:Quantita
Devo creare una procedura ricorsiva che mi permetta di gestire il caso 
scarico Articoli Multipli.
Avete suggerimenti di come si possa fare  ?

primaria, ma sempre un codice articolo definito dal negozio.
Se č per questo, io consiglio di non usare proprio codici applicativi
per le chiavi primarie, ma di lavorare sempre con campi interi
autoincrementanti. La chiave primaria č un'informazione "interna" al
sistema ed č sempre bene lavorare nel modo piů efficiente possibile,
anche al fine di recuperare correttamente i dati.

"Andrea Laforgia" <a.laf...@andrealaforgia.it.invalid> ha scritto nel 
messaggio news:jrmf23huv2gkc1323...@4ax.com...

[CUT]
Mi intrometto nel thread perche' questa soluzione mi sembra molto 
interessante... Mi piacerebbe poterla espandere per avere una sorta di 
distinta base (come gia' lo e') a piu' livelli (come potrebbe essere ad 
esempio il caso di un cesto natalizio con all'interno una confezione di 2 
bottiglie di spumante ad esempio). Per fare cio' penso che ci sia tutto 
l'occorrente, si tratterebbe "solo" da codice di leggere se il codice "aaa" 
e' singolo o multiplo (tabella TIPO_ARTICOLO... questa info si potrebbe 
spostare anche sulla tabella ARTICOLO giusto?), fare una select di tutti 
glii id_articolo_1 = "aaa" della tabella CONFEZIONE e verificare se i 
singoli id_articolo_2 sono singoli o multipli. Se multipli, rifaccio la 
select con id_articolo_1= "<codice figlio>" etc etc...
secondo voi e' funzionante? Esistono modi per ottimizzarlo?
grazie
Dade