PDA

Visualizza versione completa : Configuratore offerte



Asterix
09-06-10, 10: 25
Ciao ragazzi sono alla ricerca di un configuratore offerte free valuto possibili soluzioni locali e web.

il configuratore deve:

dato un database di prodotti identificato da codice - descrizione - prezzo e una videata dove si selezionano i vari codici e le varie quantità presentare una offerta commerciale in word o similare

codice - descrizione - quantità - prezzo totale


Inizialmente stavo valutando di utilizzare excel come db e word come report ed eseguire il tutto con delle macro, ma vorrei spingermi oltre :P

Attendo fiducioso.

:bai

ginalfa
17-06-10, 10: 50
Se non ho capito male devi creare un database dal quale estrarre con query o con form di selezione uno o più record e presentarli in form o in documento.
In pratica
tabella -> query di selezione -> report

Con MS access sarebbe sicuramente possibile con le query ed i report (i wizard sono abbastanza efficienti), che possono poi essere stampati o esportati in word, anche mediante codice VB.
Solo che access è access....e si paga.
Hai pensato alla suite openoffice?

Asterix
17-06-10, 11: 02
Ciao

access l'ho escluso in quanto dovrei generare un eseguibile da passare ad ogni account e questo con access comporta qualche problemino, la suite open non la conosco la cosa ottimale risulterebbe uno script free da installare su un server web ma le mie nozioni su mysql e php sono limitatissime :P

:bai

ginalfa
17-06-10, 11: 11
In questo caso la cosa è ben più complessa.
Purtroppo non so aiutarti.
Ho lavorato tempo addieto con access, ma mi sono limitato a creare database locali.
Comunque una guardatina ad openoffice daccela, magari è in grado di farti verede il codice mysql, così ti fai un'idea.

Asterix
20-07-10, 18: 09
Ho creato una macro vba per esportare i dati dal foglio di calcolo al word, questo è il codice di test da me utilizzato.
Aggiunge una riga tabella nel doc word ed importa i dati dalla riga selezionata in excel


Only registered members can view code.

deathwish
20-07-10, 19: 43
probabilmente al caso tuo potrebbe andare bene anche XPDF (ma richiederebbe una licenza acrobato) o, se ti è sufficiente un'output "da browser" anche una trasformazione XSL...



la cosa ottimale risulterebbe uno script free da installare su un server web ma le mie nozioni su mysql e php sono limitatissime :P


... beh, siamo qui per questo, no? ;)

pensandoci, potrebbe essere più che sufficiente uno script PHP lato web-server con una form per effettuare l'upload del tracciato dell'offerta e con poche righe di PHP puoi produrre una tabella HTML secondo le tue esigenze (che eventalmente abbelisci come ti pare con CSS e quant'altro).

se la cosa ti sembra opportuna, possiamo partire da quest'idea...

Asterix
20-07-10, 20: 21
Si la cosa sarebbe migliore dell'attuale xls to word in quanto avrei un unico database, ma il mio php e mysql non arrivano a tanto, un conto è variare del codice già scritto e un'altro è partire da zero.

:bai

deathwish
20-07-10, 20: 29
umm... se riporti un tracciato esemplificativo (un semplice file di testo ASCII) dell'input potrei buttarti giù una bozza di script PHP che importa e in uscita produce il reporto in HTML...

... poi, a partire da questo, si può dividere in sotto-script per importare in mySQL, effetuare le ricerche, produrre il report... tutto sommato un progetto molto carino da realizzare. :)

Asterix
21-07-10, 06: 41
Ad oggi il sottoscritto ha:

un foglio xls listino con le seguenti colonne. codice - descrizione breve - descrizione completa (+255 caratteri) - prezzo - quantità

cosa cercavo:

uno script che potesse gestire il listino in multi lingua su un db mysql in modo da ottenere una area comune a tutti, naturalmente in questo caso il tracciato record cambia un po rispetto al file xls che è composto da più fogli (lingue) e un file per categoria. (categoria prodotto - codice - descrizione breve - descrizione completa (+255 caratteri) - prezzo - quantità - lingua)
uno script che data una categoria riportasse una lista di articoli selezionabili e con possibilità di retifica prezzo e qtà.
uno script che a selezione avvenuta e scelta lingua riportasse un report in lingua degli articoli con la seguente struttura, per ogni articolo selezionato:

codice articolo --- descrizione breve (prima riga)
descrizione completa (seconda riga)
prezzo (terza riga sulla dx)




azioni permesse:


gestione listino: modifica - inserimento - cancellazione articolo
data una categoria devi far comparire una scheda di tutti gli articoli con la possibilità
selezione categoria e lingua.


ad oggi in rete non ho trovato nulla peccato

:bai

Skywalker87
21-07-10, 11: 12
Salve gente :bai

comincio con piccolo ma doveroso offtopic:

Sono stracontento di vedere che finalmente è stata aperta una seziona dedicata all' "arte della programmazione" :eye anche qui su collectiontricks, e ovviamente a capitanarla non poteva esserci che lui, l'unico ed inimitabile :bgg2, deathwish!! :forgive


Ok, veniamo al problema ...

Decisi gli strumenti da utilizzare (php e mysql) io inizierei a schematizzare il database. :sisi

Purtroppo non ho ancora affrontato in modo approfondito il corso di "basi di dati", quindi non so se quella che ti presento sia la forma migliore / ottimale / corretta per strutturare il database ... :boh

Ad ogni modo la mia soluzione presenta una sola tabella così fatta:


Only registered members can view code.

deathwish
21-07-10, 12: 07
uno script che potesse gestire il listino in multi lingua su un db mysql in modo da ottenere una area comune a tutti, naturalmente in questo caso il tracciato record cambia un po rispetto al file xls che è composto da più fogli (lingue) e un file per categoria.



idealmente, la base di dati dovrebbe essere formata da

una tabella anagrafica dei prodotti
una tabella anagrafica delle categoria
una tabella anagrafica delle lingue
una tabella delle descrizioni


il fatto che tu voglia gestire la base di dati in "multi-lingua" complica un po' lo schema relazionale e rende necessaria la terza tabella.

dal punto di vista pratico, questa normalizzazione complica un po' la gestione, ma immaginando che tu gestisca tutto in un unico tracciato record così fatto

Only registered members can view code.

( "lingua" e "categoria" sono stringhe descrittive della lingua e della categoria e bisognerebbe fare attenzione a scrivere sempre in modo coerente... ovvero, evitare typo )

ci penserebbe lo script di importazione a smistare i dati e popolare la tabelle in modo opportuno mantenendo l'integrità referenziale.



(categoria prodotto - codice - descrizione breve - descrizione completa (+255 caratteri) - prezzo - quantità - lingua)



non è chiaro il tipo dei dati. quali di questi campi sono stringhe (e di che lunghezza massima)? quali sono numerici? quali sono decimali?



uno script che data una categoria riportasse una lista di articoli selezionabili e con possibilità di retifica prezzo e qtà.


selezionabili con una casella di spunta oppure con dei filtri (su wildcard, ad esempio)? con paginazione oppure su un'unica paginona (più semplice, ma se sono tanti articoli ci si perde)?



azioni permesse [...]


se non hai propria fretta, posso realizzare una bozza entro un paio di giorni...



Salve gente :bai

ciao Skywalker87, ben ritrovato. :)


Ad ogni modo la mia soluzione presenta una sola tabella così fatta

l'idea non è affatto sbagliata... ma, a parte mancare la categoria, non è detto che debbano essere solo due le lingue da gestire. inoltre, mancando un identificatore di lingua, come sarebbe possibile effettuare una selezione (a meno di non infarcire il codice di diramazioni)?

Asterix
21-07-10, 16: 10
Ciao

vediamo di rispondere ad alcune domande:

Tipologia campi:

Codice – quantità: numerici senza decimali
prezzo: numerico con decimali
categoria prodotto: stringa (30)
descrizione breve: stringa(100)
lingua: stringa

Tipo selezione:

selezionabili con una casella di spunta, con paginazione oppure su un'unica paginona

Per la gestione delle tabelle si concordo con questa affermazione


ma immaginando che tu gestisca tutto in un unico tracciato record così fatto



se non hai propria fretta, posso realizzare una bozza entro un paio di giorni...

non ho fretta

Mi pare di essere uno scroccone, non saper nulla e voler fare :P o meglio far fare

:bai

deathwish
22-07-10, 13: 01
Tipologia campi [...]

ottimo, ora è chiaro. per la descrizione "lunga" per intanto possiamo immaginare un limite ragionevole di 512 caratteri?




Mi pare di essere uno scroccone, non saper nulla e voler fare :P o meglio far fare


intanto, iniziamo da una bozza semplice... poi la si renderà più complessa, mano a mano che ci prenderai pratica... ;)

Asterix
22-07-10, 15: 19
ottimo, ora è chiaro. per la descrizione "lunga" per intanto possiamo immaginare un limite ragionevole di 512 caratteri?


Non si potrebbe evitare limiti, in quanto non saprei a priori cosa mettono.

:bai

deathwish
22-07-10, 15: 42
Non si potrebbe evitare limiti, in quanto non saprei a priori cosa mettono.

va bene, nessun problema... bisogna pensare, allora, nella pagina di visualizzazione dei prodotti come gestire la cosa... se far vedere un'anteprima dei primi caratteri della descrizione lunga, ad esempio... oppure non metterla proprio. ma è solo una questione di visualizzazione in quella pagina.

Asterix
22-07-10, 17: 28
Non serve nella fase di scelta, quella descrizione viene richiamata solo in fase di creazione offerta, nella scelta basta quella breve.

:bai

deathwish
23-07-10, 16: 09
dunque, dunque... innanzi tutto descriviamo il (semplice) schema relazionale.

quattro le tabelle coinvolte (ma se ne sarebbero potute usare cinque, a ben vedere)

le tabelle "languages" e "categories" per mantenere le liste rispettive,
la tabella "messages" per mantenere la lista dei testi,
la tabella "products" come anagrafica dei prodotti.


ogni tabella possiede una chiave primaria auto-incrementante, gestita dal DBMS... lo si è fatto per comodità, anche se dal punto di vista prettamente accademico in ogni tabella sarebbe stato possibile determinare una chiave primaria effettiva (ad esempio, il codice del prodotto per la tabella dei prodotti).

sulle prime due tabelle, ben poco da dire. sono due classiche "tabella tipo" (o delle "LUT"), sequenze di valori ammissibili. a differenza dei altri messaggi descrittivi dei prodotti, queste non vengono tradotte in multi-lingua. il testo della lingua/categoria è, di fatto, una chiave primaria dato che non sono permessi duplicati.


Only registered members can view code.

la tabella dei messaggi contiene sia le descrizioni brevi che quelle lunghe, differenziate da un valore diverso dell'attributo "message_type" ("0" per quelle brevi, "1" per quelle lunghe). ogni messaggio possiede due chiavi esterne per poter tenere traccia della lingua e del prodotto cui si riferisce.


Only registered members can view code.

la tabella dei prodotti, infine, tiene traccia dei dati anagrafici degli articoli, con un'unica chiave esterna nei riguardi della tabella delle categorie.

Only registered members can view code.

detto questo, ho iniziato qui (http://www.kwyjibolabs.net/warehouse) un'implementazione MOOOLTO semplice e abbozzata. permette di effettuare ALCUNE delle funzioni richieste e l'interfaccia è "buttata li". però almeno rende l'idea.

per importare l'anagrafica, si deve dare in input allo script di importazione un tracciato con la seguente struttura

Only registered members can view code.

riportando su righe successive più volte lo stesso prodotto (identificato dal codice) è possibile aggiungere traduzioni diverse. per i campi "categoria", "prezzo" e "quantità" vengono mantenuti i valori dell'ultimo record importato.

per i campi numerici (il prezzo) il separatore decimale è il punto (e non la virgola).

--- EDIT ---

Nota: rileggendo ora la discussione dal principio, penso di aver male inteso le specifiche. la quantità non deve essere memorizzata nella base dei dati ma essere un campo in ingresso editabile al momento della creazione dell'offerta... corretto?

Nota #2: se così fosse, nel report di offerta deve comparire anche il totale articoli/prezzo?

Asterix
24-07-10, 07: 46
Nota: rileggendo ora la discussione dal principio, penso di aver male inteso le specifiche. la quantità non deve essere memorizzata nella base dei dati ma essere un campo in ingresso editabile al momento della creazione dell'offerta... corretto?

Nota #2: se così fosse, nel report di offerta deve comparire anche il totale articoli/prezzo?

Corrette entrabe le cose, in più dovrebbe esserci il totale di tutte le righe

deathwish
26-07-10, 12: 52
occhei, quindi procedo con le modifiche necessarie...

... ai fini di semplificare il proseguimento, comunque, sto valutando la possibilità di fare uso di un controllo di revisione (de)centralizzato in modo da poter condividere i sorgenti e fare uso di un sistema di "issue reporting". a breve vi farò sapere.