Newsgroup: it.comp.lang.visual-basic
Titolo: Una query su Db Access

Buongiorno a tutti, spero che qualcuno voglia/possa aiutarmi a risolvere 
l'enigma. Spiegando che nel vb6 mi ci hanno buttata
dentro per forza(!), cerco di darmi coraggio e farmi venire le idee, ma 
questa proprio no, 'gna fò!
Ho un file access 2003 gestito da vb6 nel quale ho un codice articolo 
(numerico) ed un costo (valuta). Ogni volta che viene effettuata una 
vendita, questi due parametri vengono scritti nel file delle vendite, 
riportando ovviamente i pezzi venduti:
MAGAZZINO TABELLA ARRIVI
==========================
COD     125
ART     Blablabla
COSTO   12,25
ARRIVO  100
DATABASE VENDITA
=========================
COD             125
ART             Blablabla
COSTO           12,25
PZ VENDUTI      2
PREZZO VENDITA  19,00
Se però vado ad effettuare una modifica del prezzo di costo nel file di 
magazzino (Arrivo), per poter avere un allineamento anche nel file delle 
vendite (ci occorre per valutare eventuali margini), sarei costretta a 
modificare manualmente tutte le transazioni già effettuate a quel prezzo 
precedente,per allinearle al reale prezzo di acquisto.
Così, ho pensato di eseguire una verifica sul file delle vendite, 
mettendo un select case con queste casistiche:
se quell'articolo non è mai stato venduto, posso tranquillamente variare 
il prezzo --
Se è stato venduto ma in quantità minore di quella che voglio variare, 
effettuo ugualmente la modifica perchè non credo che cambi nulla  sui 
margini di guadagno --
ma l'ultimo caso? Quello cioè in cui io dovrei variare un arrivo di 10
pezzi e nel file delle venfite ce ne stanno 431 venduti!? Con quale 
query posso dire di modificare il prezzo soltanto a 10 dei 431 venduti a 
quel prezzo? Proprio non saprei come fare.
Vi chiedo scusa per questo post da perfetta idiota e lungo quanto una 
quaresima, ma non sapevo come spiegare meglio!
Grazie

 quaresima, ma non sapevo come spiegare meglio!
Ciao,
non so come funzioni il vostro programma, ma immagino che database 
vendita contenga le "righe di fatturazione" partendo da questa ipotesi 
si possono fare alcune considerazioni, quindi queste dovrebbero essere 
immutabili, cosa succederebbese un cliente chiedesse una copia della 
fattura dopo che avete aggiornato i prezzi?
Quello che farei (così su due piedi  poi si potrebbe pensar meglio) è 
mantenere uno storico degli aggiornamenti della tabella arrivi con costo 
e data su tabella separata,
costo 		12,25
validità dal 	01/01/2010
se poi dovesse cambiare il prezzo avresti una nuova tupla con
costo		15,00
validità dal	01/01/2001
naturalmente il database vendita dovrà avere un corrispondente campo 
contenente la data di vendita, in questo modo lasci corretamente i 
prezzi al valore del momento della vendita e ti puoi calcolare i 
relativi margini nei periodi che ti serve.
ciao
stefano


Grazie Stefano per la tua risposta, mi spiace se sono stata poco chiara, 
ma non volevo andare oltre il panegirico che ho fatto!
Dunque il problema, visto dal tuo punto di vista è corretto, tuttavia è 
da affrontare in maniera diversa. E' vero che la riga di fatturazione 
contiene i campi quantità prezzounitario e anche il costo ma 
quest'ultimo comunque non è visibile e riguarda solo noi a livello 
interno. Quindi il cliente, dopo aver ricevuto lo scontrino o la 
fattura, è già lontano dai nostri affari(!) e non gli cambia nulla se il 
prodotto a noi costa 10, 20 o 30 euro.
Ben diverso è il lato interno, e qui credo di aver spiegato chiaramente 
sopra, quindi il punto più importante resta sempre la terza fase del 
select case.
Grazie

 Grazie
Ciao,
premesso che non conoscendo esattamente la struttura del DB e/o ciò che 
è l'operatività del programma è difficile fare una qualsivoglia analisi,
premesso che date le informazioni, continua a suonarmi strano quello che 
vuoi fare,
se conosci a priori quante righe vuoi aggiornare, potresti fare così:
do per scontato che la tabella vendita abbia un id univoco,
UPDATE vendita SET prezzo_vendita = nuovo_prezzo_vendita WHERE idunivoco 
IN (SELECT TOP x idunivoco FROM vendita WHERE COD = tuocodicearticolo)
dove x va sostituito con il numero di righe che vuoi aggiornare.
Altra strada è aggiungere la colonna COSTO alla tabella vendita, in 
questo modo hai sempre il differenziale corretto anche quando aggiorni 
la tabella arrivi.
ciao
stefano


In questi casi...ci si sente piccini piccini! Ok, provo a spiegarmi 
ancora meglio. Se guardi la struttura approssimativa del db, per come te 
l'ho scritta nel messaggio iniziale, forse risulta più chiaro, ma provo 
a farlo meglio, perchè qualcosa l'avevo omessa:
DB ARRIVI ---> TABELLA DETTAGLIARRIVI
=====================================
ID(UNIVOCO)-IDARTICOLO-DESCRIZIONE-QTAARRIVATA-PREZZOCOSTO-PREZZOVENDITA
etc etc....
DB ARRIVI ---> TABELLA MAGAZZINO
ID(UNIVOCO)-IDARTICOLO-DESCRIZIONE-QTAARRIVATA-PREZZOCOSTO-PREZZOVENDITA
etc etc....
contiene i campi di cui sopra e altri necessari ad altre operazioni. 
Quel che devi sapere è che il campo quantità, si modifica ad ogni 
arrivo,relativamente al codice articolo,incrementandone il valore se 
esso è già in magazzino, mentre i campi prezzo acquisto e vendita, 
possono essere attribuiti all'articolo in due casi, il primo, se 
l'articolo non è ancora presente in magazzino, il secondo, se l'articolo 
è presente, ma a quantità 0. Ti faccio l'esempio di un altro caso:
Magazzino:
Penne Blu  GIAC 10 przacq 1.25 przvend 2,00
Arrivi
Penne Blu  quant 20 przacq 1.50
in questo caso, o metti dentro un nuovo articolo con nuovo codice o non 
ti è possibile variare il prezzo di costo, altrimenti, quelle 10 penne 
che hai già dentro, subirebbero il cambiamento di prezzo in maniera non 
corretta. Questa è la prima fase, e chi realizzò il programmino, mise 
questo paletto che seppure complicato, può essere accettabile.
In fase di vendita dunque, l'articolo caricato in griglia, con tutte le 
sue informazioni, verrà scritto, a vendita avvenuta sul DBVENDITE, il 
quale è strutturato così:
ID(UNIV)-IDART-DESCARTICOLO-QUANTVEND-PREZZVND-PREZZOACQ etc etc
mi troverò una griglia di questo tipo:
1 - 104 - Penna Blu - 2 - 1.55 - 0.80
2 - 75 - Matita - 2 - 0.68 - 0.25
3 - 104 - Penna Blu - 2 - 1.55 - 0.80
4 - 88 - portachiavi - 7 - 4.21 - 2.50
..........................
.............................
..........
N - 104 - Penna Blu - 9 - 1.55 - 0.80
Se adesso, andassi a variare soltanto il costo di 1 degli arrivi delle 
penne,che magari interessa solo 3 penne arrivate, come la metterei?
Se per ipotesi, il costo mi fosse stato scontato dopo il caricamento 
della bolla, quindi quei 3 pezzi che ho già caricato a 0.80 di costo e 
che ho venduto e scritto nel database vendite, adesso mi costano 0.55 
poichè mi è stato fatto uno sconto in fattura, per determinare 
correttamente i margini lordi, dovrei cambiare il prezzo di costo su 3 
penne, giusto?
Ok, qui il select case di cui al post precedente:
Se nel DBVendite, l'articolo 104 non è presente, posso tranquillamente 
variare il prezzo, in quanto nulla cambierebbe.
Stessa cosa dicasi se SUM(quantitàvenduta) è < della quantità da 
variare, esempio, ho avuto tre arrivi da 20 penne ma ne ho vendute 
finora soltanto 5.
Terzo  caso: 3 arrivi da 20 penne, costo imputato 0.80
Mi viene comunicato che soltanto in un arrivo, mi è stato applicato uno 
sconto e che in fattura il prezzo sarà di 0.55, e io nel dbvendite ne ho 
già vendute 51, provenienti dai tre arrivi.
Ecco che mi tocca cambiare il prezzo soltanto in 20 dei 51.
Mi sono fermata qui.
Non posso altro che chiedere scusa del romanzo. Manzoni a scrivere i 
promessi sposi ci mise meno tempo e inchiostro!!!

 wrote:
zac
esiste un sistema che taglia la testa al toro...e che risolve casi
come codesto...
codifichi anche la partita in arrivo.
Ogni partita avrà il suo costo e puoi fare tutti i mix che vuoi
Penne bic
codice100
Listino 10Euro a imballo
Cod100 Partita A1 Qta 40 prezzo 10
Cod100 Partita A2 Qta 50 prezzo 9.50
Cod100 Partita A3 Qta 30 prezzo 12
...a questo punto se la qta è la giacenza puoi decidere con una query
da quale fonte attingere e farti tutti i mix più strani possibili...
ad esempio
20  dalla partita A1 = Euro200
10 dalla  partita A2 = Euro 95
5 dalla partita A3= Euro 60
Ovvio che se la partita ha il medesimo prezzo PER SOLO CODESTO caso
non se ne crea un altra!
In realtà la partita si crea lo stesso perchè serve ad avere una sorta
di tracciabilità del prodotto venduto: ad esempio per risalire
all'assemblatore o per monitorare la distribuzione degli ordini ai
fornitori e per milel altri motivi!
Quando il tessile tirava di brutto si faceva con il filato...le
pezze...i capi finiti...etc etc

 Ecco che mi tocca cambiare il prezzo soltanto in 20 dei 51.
Ciao,
Wodka ti ha fornito sicuramente la quadratura del cerchio, ma temo che 
nel tuo caso non sia applicabile dato che, mi sembra di capire, a 
livello applicativo tu non possa intervenire, ma abbia la sola 
alternativa di mettere qualche "pezza" ai dati in tuo possesso.
Detto questo, secondo me rimane valido quanto ti ho esposto nel 
precedente post, e cioè:
UPDATE vendita SET prezzo_vendita = nuovo_prezzo_vendita WHERE idunivoco 
IN (SELECT TOP x idunivoco FROM vendita WHERE COD = tuocodicearticolo)
eventualmente se il prezzo da aggiornare è uno specifico (e non uno a caso)
UPDATE vendita SET prezzo_vendita = nuovo_prezzo_vendita WHERE idunivoco 
IN (SELECT TOP x idunivoco FROM vendita WHERE COD = tuocodicearticolo 
AND prezzo_vendita = y)
ciao
stefano

 quaresima, ma non sapevo come spiegare meglio!
Premesso che i dati di vendita sono dati storici che NON DOVREBBERO MAI 
ESSER MODIFICATI se non a fronte di correzione di un errore materiale quello 
che descrivi è il tipico esempio di (di)gestionale con analisi a piripacchio 
ed implementazione a meglio che non lo dico...
Facendo analisi delle entità qualsiasi essere senziente che non sia chi ha 
scritto il vs. gestionale capirebbe che se compro qualcosa da altri debbo 
pagare un prezzo e che questo prezzo può variare di giorno in giorno per 
infiniti motivi. Quello che occorre quindi è una tabella che registri 
l'andamento dei prezzi di un articolo al loro variare registrando data-ora 
di entrata in vigore del prezzo, codice articolo e prezzo unitario.
Edgard Codd e Chris Date ci hanno regalato il modello relazionale dei dati 
proprio per risolvere queste problematiche. Nei database relazionali esite 
il concetto di vista (view) e di join 
http://en.wikipedia.org/wiki/View_(database)
 che Access implementa molto 
bene.
Saluti.
 


Ordunque...ringraziando il buon Dio che mi ha fatto trovare questo ng 
(!) e fermo restando che le mie ambizioni si fermano laddove esto 
prodotto abbia una parvenza di prodotto quasi funzionale, vi ringrazio 
per le risposte. Tu l'hai detta tanto giusta che non lo immagini , in 
quanto la  tabella in oggetto, si chiama proprio tracciabilità!! E' 
evidente che forse nasceva con queste intenzioni (avranno subito un 
aborto in itinere), ma qualcosa di funzionale c'è. Seconda cosa, credo 
che il mio ex collega che lo ha fatto, abbia fatto più del dovuto viste 
le sue mansioni, quindi ovviamente lo perdono, perchè anche io da 
perfetta semi idiota ignorante essendo solo anni luce più avanti delle 
mie colleghe, vorrei fare l'impossibile, ma so che farò solo caxxate! ;-)
Non so ancora come ne uscirò, ma tanto per rendere un pò più ilari le 
vostre giornate, se riesco a far qualcosa ve lo renderò noto!
A patto che non esageriate con le male parole...non vale eh?
Thx

 Il 06/12/2010 19:31, Wodka40[Google] ha scritto:
Cara amica
....io mi sento di darti un altro importantissimo consiglio...che non
c'entra nulla con l'informatica: anche se i titolari non saranno
d'accordo...trova un prof di merceologia o un commercialista
competente (lo sò...trovarne!)...e (come dice Fantozzi) FACCI LEI UNA
CHIACCHERATA!
Perchè secondo em codesta applicazione se la continuate come mi dici
ha un difetto di analisi logica enorme!
Come detto NON POTETE cambiare i prezzi di listino!
In tutte le aziende che hanno problemi simili (pensa un supermercato)
il prezzo di listino NON E' una costante...ma una variabile!
In tempi diversi io ho prezzi di acquisto diversi!
POI...in base a calcoli miei...che TENGONO CONTO della variabilità dei
fornitori...calcolo un PREZZO DI VENDITA che mantengo volatile o
rigido per un periodo di tempo
Ne hai esempio in 2 casi:
Prezzo vendita rigido
Un mobiliere...le materie prime cambiano prezzo...il mobiliere
mantiene l'offerta per il mese di dicembre a prezzi fissi
Prezzo vendita volatile
Vai al supermercato lunedì e tornaci sabato...quanto costano le
zucchine???
Puoi fare finta che non ci sia questo problema solo in un caso:
IO impongo il prezzo di acquisto...però poi corri il rischio come
succede in Sardegna che i pastori occupino di tutto perchè
sottopagati!
Quindi mi sento di dirti: prima di arrivare all'informatica...tu o chi
per te...chiaritevi le idee a livello di gestione
amministrativa...altrimenti fate degli "arrosti" incredibili!
Il rischio quale è
il rischio è che piccole variazioni di prezzo nel piccolo periodo
passino inosservate ma nel lungo si sommino erodendo una parte
significativa del margine lordo aziendale.
Tradotto: ad esempio a fine anno invece del 20% lordo di guadagno
avete un 18% lordo senza sapere perchè...e non lo potrete sapere mai
perchè non avete registrato le variazioni dei prezzi dei fornitori!
Io capisco da quello che dici che ti hanno caricato di un ruolo che
non è il tuo  e probabilmente di tecnica gestionale non ne capisci
nulla...
Ma un ragioniere che non abbia fatto le serali o il Cepu lo avete in
azienda???
Lui che dice? Gli va bene questa impostazione logica?
E il vostro commercialista?
Ed il proprietario?
Saluti!


Buongiorno a grazie!
Dunque procedo con ordine, poichè quello che hai scritto (e che non ho 
letto io soltanto ma ho fatto leggere ad un paio di colleghe/i) mi è 
piaciuto molto.Forse il problema è un pò meno grave di ciò che sembra, 
anche se quanto da te espresso è pertinente e molto professionale.
Nella nostra piccola attività commerciale (3 dipendenti), ha lavorato 
per qualche anno un ragazzo che avendo una discreta dimestichezza con 
l'informatica, ha creato questo prodotto che a giudizio del titolare e 
di tutti noi che lo usiamo, è carino, non crea problemi e fa esattamente 
quello che a noi serve da bravo bravo.... A questo punto, il nostro 
collega se ne va, ma lascia senza alcun problema, il codice a 
disposizione del titolare, e tra me ed un altro collega, non 
professionisti ma molto amanti della materia, abbiamo apportato alcune 
correzioni (molto sceme, tipo qualche report mirato e qualche campo in 
più) che ci hanno aiutato a renderlo ancora più personale.Pensa che ho 
messo due anni e più di studio da autodidatta per passare da utente 
evoluta a persona in grado di intendere una parte di codice... Il 
problema è sorto solo quando una mia collega, si è accorta di aver 
inserito una bolla la settimana prima, imputando un prezzo che invece 
apparteneva alla riga sotto, da qui la domanda obbligata: ma correggere 
soltanto il prezzo riferito a questo articolo in questa circostanza?
Se cercassimo di apportare almeno questa variazione? Sarebbe perfetto. 
Ecco tutto. In fondo, non si volevano toccare i listini, non si voleva 
cambiare l'archivio del già venduto, nè creare problemi legati a 
documenti emessi e manipolati! Marcello (il mio collega) ed io, insieme 
con il nostro titolare, abbiamo riflettuto sul fatto che la correzione 
del prezzo di acquisto inficiava il report dei margini e a forza di 
ricerche abbiamo fatto la domanda a voi guru (anzi, plurale GURI[!]).
Detto questo, non posso che ringraziarvi perchè siete persone speciali.
In questo periodo, leggendo i vostri post, mi viene una voglia immensa 
di imparare un mucchio di cose, poi quando leggo con attenzione ciò che 
scrivete, mi sento un microbo!
Saluti per tutti voi, spero di non rompere più le scatole, ma non ne 
sarei tanto sicura... ;-)

 Il 08/12/2010 10:40, Wodka40[Google] ha scritto:
zac
Beh ma il prezzo di una riga di una fattura DEVE essere locale!!!
Altrimenti non tornerà mai un cazzo! (scusa la finezza eh ma rende
l'idea!)
Mi spiego :
tu hai
Cliente Pippo
Cliente Pluto
ad ambedue vendi 100 pezzi di un articolo...da dove prendi il prezzo?
...
se mi rispondi da un listino unico non va bene...o meglio...va bene se
sei un artigiano che ha molto ricarico ...gli fa un baffo la crisi...e
a tutti i clienti pratica il solito prezzo!
Ad esempio entro in un negozio di terrecotte e compro un mascherone di
1 mt x 2....costa 1000 Euro...è un prezzo unico....è un pezzo
unico....mi è costato farlo 50Euro di materiali ed energie varie...più
il mio estro ...chissenefrega di queste menate ho talmente tanto
ricarico!
OLTRE non va bene
Perchè pippo e pluto potrebbero avere i propri prezzi (è la normalità
ad esempio per chi vende abiti all''ingrosso)
Quindi Pippo e Pluto avranno ognuno il proprio listino
Ma anche così non è perfetto
Perchè?
Perchè ci sono i saldi di mezzo..o le vendite a stock degli articoli
vecchi ...o le promozioni...etc etc
Quindi da diciamo sempre la fattura è composta da
UNA TESTATA con i dati del cliente
e tante RIGHE di fatturazione...ognuna con prezzo qta e tutto il
resto!
Tu dovrai PROPORRE il prezzo di listino di un articolo in base al
listino in vigore del cliente...ma (la faccio facile senza automatismi
per avvertire di promozioni o altro) alla fin fine l'operatore può
cancellare quel prezzo ed inserirne un altro...ed è quello che vuoi!
quindi 2 tabelle: (almeno) TestataFattura e VociFattura collegate uno
a molti possibilmente in integrità referenziale
e poi una tabella LIstini che riporta i listini in vigore cliente per
cliente
Così il sistema è versatile e si piega a tutte le finezze che vuoi
fare (quasi tutte)
Riformulo la domanda fatta sopra:
Ma un ragioniere c'è in azienda? (se c'è) possibile che non si sia mai
posto questi problemi?
C'è un commercialista?...come fà a tornargli il valore del magazzino
se spippolate i prezzi?
Lo sapete che se viene un controllo dei "berrettini grigi" ed
incrociano le fatture di acquisto con questo dato e trovano una
discrepanza sono "volatili alquanto acidi anche per diabetici" ?
Cmq alla fin fine...sono problemi vostri....ma io un bel discorsino
con un tecnico gestionale (ragioniere, commercialista,prof di
merceologia) ce lo farei...giusto per chiarirvi la procedura corretta
per spippolare i dati.....
Come dice il proverbio
Uomo avvisato...mezzo magnato (o era salvato...boh!)
eh eh eh!!!
Ciao....