Newsgroup: it.lavoro.professioni.webmaster
Titolo: gestione ordini clietne via web

Salve a tutti, in azienda avremmo la necessità di integrare il nostro
attuale gestionale con qualcosa che ci permetta di poter gestire gli
ordini clienti da web. Naturalmente la società che ci vende il
gestionale non prevede un tale modulo per cui avremmo pensato di
valutare qualcosa di open source e farci in casa la parte di
integrazione.
Avete qualche nome da consigliare? E' essenziale che le anagrafiche
(articoli e clienti) e i listini possano essere aggiornate tramite
importazione di dati da file csv.
Grazie
debharlock

 importazione di dati da file csv.
Prova a vedere Prestashop, pero' non so se faccia quello che chiedi, il 
nostro ragionamento e' stato l'opposto (non con prestashop, ma con un 
carrello/backend fatto internamente), gestisco online ed esporto tramite 
script nel gestionale gli ordini processati correttamente.
Anche perche' rischi di avere tanta fuffa se fai passare tutto 
direttamente al gestionale senza un filtro all'ingresso. Probabilmente 
la contabilita' non vi ringraziera' per questo :D
Ciao
-- 
MMM


Io intendo quello che dici tu. il caricamento\aggiornamento delle
anagrafiche dovrebbe avvenire tramite script solo in una direzione.
Dal gestionale verso il web, e nel gestionale arriveranno solo gli
ordini correttamente chiusi.
Ciao
debharlock

 ordini correttamente chiusi.
Ma quindi non ho capito, se fai una vendita via web, deve arrivare al 
gestionale in qualche modo, quindi l'unica via e' web->gestionale, se 
metti solo gestionale->web, come li prendi gli ordini direttamente da 
internet?
Ciao
-- 
MMM

 debharlock
Perl la struttura semplice del DB suggerirei cs-cart che indubbiamente � 
anhce avanti anni luce rispetto alle soluzioni free.
Cmq la cosa � identica per ogni applicazione dato ceh si andr� ad 
interagire con MySQL al 99,999% dei casi.
Il mio dubbio �, siete certi di essere in grado di inserire i dati nel 
gestionale? Nel senso che se utilizza un DB esterno MySQL/Oracle o altro 
la cosa � certamente fattibile ma se utilizza un formato proprietario di 
archiviazione tipo vecchi gestionali in cobol la vedo ardua.


Ricevendo i dati dal web e trasferendoli al gestionale; il gestionale 
processa i dati ricevuti ed elabora l'ordine e quindi inoltra al web i dati 
elaborati e ad altre componenti le informazioni necessarie per il disbrigo 
della pratica; il tutto assumendo che il gestionale sia "un qualcosa" di 
esterno rispetto al software server-side del sito web. 

Il 19/07/11 18.11, TripleM ha scritto:

Ovviamente, la cosa migliore è ogni tot effettuare una query e 
verificare dal DB del sito se ci sono ordini, ovviamente una copia 
dell'ordine arriva anche via mail ma è decisamente più 
comodo/pratico/sicuro interrogare il DB remoto (avendo anche cura di 
configurare debitamente il firewall del server o di predisporre un web 
service)

 ordini correttamente chiusi.
Ti servono un paio di databases sul "frontend" (web); uno sar�
aggiornato dal DB aziendale e conterr� cataloghi, prezzi, etc...
il secondo invece verr� usato dall'applicazione per inserire gli
ordini
I due databases verranno poi sincronizzati (usando qualsivoglia
meccanismo di replica) ad intervalli regolari in modo da aggiornare
i dati del primo e da trasmettere i dati immessi nel secondo alla
sede; il vantaggio di un tale approccio � che, anche nel caso in
cui, per un qualsiasi motivo, la connessione tra il sito web e la sede
non funzionasse, i dati imessi verrebbero comunque "accodati"
ed in qualsiasi caso la sincronizzazione avverrebbe non appena
possibile senza problemi di "offline"
Vorrei comunque fare un'ulteriore considerazione che, sebbene
in parte off-topic, � comunque relativa a quanto sopra
Si tente spesso a mettere in piedi qualcosa come quanto sopra
utilizzando una singola macchina che "fa tutto"; un tale tipo di
configurazione, realizzata vuoi per ignoranza (nel senso letterale
di mancanza di conoscenza, senza offesa) vuoi per altri motivi,
� tutto meno che ottimale
Per mia esperienza diretta, l'ideale sarebbe separare i vari
"strati" ossia, ad esempio, usare una macchina (o "virtual
machine" che sia, ovviamente) per ospitare unicamente il
webserver e le pagine che compongono l'applicativo, questo
non dialogher� MAI direttamente con il database (anzi, non
avr� alcuna conoscenza dello stesso) ma utilizzer� per la
lettura e la scrittura dei dati, dei webservices (SOAP su SSL)
e questi ultimi saranno esposti (solo nei confronti del web
server) da un secondo host (o VM); tali webservices a loro
volta, provvederanno ad effettuare i necessari accessi al DB
(possibilmente usando esclusivamente delle chiamate a
stored procedures) allo scopo di reperire o memorizzare i
dati; il DB potr� essere situato sullo stesso host che offre
tali webservices o (meglio) su di un terzo host separato ed
ovviamente, ciascun host sar� opportunamente isolato
dagli altri (firewall etc...)
Il vantaggio di tale approccio � che, nel caso in cui il web
server (ossia il frontend esposto "al mondo") venga per un
qualsiasi motivo compromesso, non sar� possibile avere
accesso ai dati n� tantomeno manipolare gli stessi, dato
che tali operazioni (in special modo la scrittura) richiederanno
un accesso "autenticato" ai webservices preposti

 un accesso "autenticato" ai webservices preposti
Sicuramente in questo modo incrementi di tanto la sicurezza, ma se ti 
bucano il web server, cosa gli impedisce di fare le stesse identiche 
chiamate SOAP? Se non ti creano danni immediati e' difficile che tu ti 
renda conto che e' stato bucato.
Certamente comunque il tuo approccio e' uno dei migliori possibili, io 
cerco solo il pelo nell'uovo visto che nessun sistema connesso ad 
Internet potra' mai essere considerato sicuro al 100% ;)
Ciao
-- 
MMM


Parlavo di anagrafiche clienti ed articoli. Per questi oggetti
l'aggiornamento e' solo gestionale verso web. Non esiste un ritorno.
Per questo motivo mi serve che la struttura dei dati sul db della
parte web sia o molto semplice o molto commentata.
Gli ordini inseriti vengono estratti con una query e messi su csv ed
importati sul gestionale.
Al momento un tracciamento della vita (creazione, stato dell'evasione
e chiusura) dell'ordine sul web non mi interessa
Ciao
debharlock

 possibile senza problemi di "offline"
La sincronizzazione sarebbe sempre off-line. Non posso aggiornare
direttamente il gestionale, perderei il supporto. E in piu' il
programma e' abbastanza potente per quanto riguarda l'estrazione dei
dati (dbsu MSSQL in chiaro + schema della base dati) e l'importazione
tramite file csv  (tracciai ampiamente personalizzabili)
Taglio la parte della sicurezza. Se riusciro' a mettere su il tutto
con quello che ho a disposizione e farlo funzionare probabilmente
avro' a disposizione i soldi per fare quello che dici tu solo dopo il
primo "buco" :-(
Ciao
debharlock

 archiviazione tipo vecchi gestionali in cobol la vedo ardua.
L'importazione la fa il programma tramite file csv. Non posso scrivere
direttamente dentro il db, molto probabilmente in caso di problemi
l'assistenza mi sbatte la porta in faccia
Ciao
debharlock

 renda conto che e' stato bucato.
Ho (volutamente) omesso alcuni dettagli :)