Pagina 1 di 4

idea x fattura, magazzino etc. con applicativo esterno

Inviato: 20/11/2005, 21:05
da deromas
un saluto circolare a tutto il forum

poichè è la prima volta che scrivo su questo valido forum
prima di tutto mi presento:
sono un ottimo tecnico hardware (anche a livello di progettazione di schede) e una smanettone a livello software (vuol dire che sò programmare, conosco vari linguaggi anche se non sono una cima, ma conosco a menadito i database e la loro gestione)

in seconda battuta voglio ringraziare tutti coloro che gratuitamente si impegnano per la comunità allo sviluppo di software open (in questo caso rivolto a oscommerce) e in particolare al lavoro fatto da Bass.

ma vengo immediatamente al punto:

conosco oscommerce da diversi anni, grazie a ricerche fatte per mettere su impiedi un mio progetto (ho trovato tantissimo materiale -non solo di os commerce - e selezionato i più validi - come si dice... impara larte e mettila da parte.. -) e per il momento buono della sua messa in opera.

il momento è ora arrivato. (dopo anni di lavoro per mettere da parte soldi per il nuovo negozio)

sto aprendo un nuovo negozio al publico con vendita al banco e contemporaneamente un negozio on line (sul mio sito che da anni, in attesa di questo momento, porta la scritta "in custruzione")

ho scelto come gestionale on line oscommerce (scelta già fatta da parecchi anni, prima che nascesse questo furum in italiano)

(sono rimasto meravigliato dal progresso fatto grazie alle contributions realizzate.)

per il negozio volevo integrare oscommerce con la gestione al banco, magazzino (così che si aggiorna una sola volta etc) fatturazione, gestione assistenza tecnica con visualizzazione on line etc.

ho visto inoltre nel forum che MOLTI hanno il problema della fatturazione
( chi in un modo e chi in un altro) e come dice Bass è meglio usare un programma gestionale esterno.

pensavo allora di realizzare un programma in grado di leggere i dati dal database e gestirli oer gli svariati usi. su un 3d una persona (non ricordo il nick) ha pero detto questa frase " e se mi cade la connesione internet che faccio... sto fermo con il negozio?"
affermazione giustissima che condivido a pieno

di programmi gestionali ho visto che ne conoscete alcuni, e in particolare mi riferisco a mosaico che da la possibilità di integrarsi con os commerce sicronizzando i database.

ma il costo? a parere mio elevato e inguistificato, soprattutto per chi sceglie software open.

ingiustificato perchè, conoscendo la gestione dei database, la sincronizzazione non ci vuole poi molto a realizzarla.
i costi sarebbero giustificati se il gestionale (molto più complesso) costasse quanto il modulo aggiuntivo e viceversa.

Ma veniamo all'idea (scusate se sono stato lungo, ma scrivendo relazioni tecniche di continuo, questa e la mia massima sintesi - deformazione professionale, devo spiegare tutto per filo e per segno)

in passato per il mio negozio ho realizzato un programma di fatturazione decente con access (lo usano parecchi miei clienti a cui lo distribuito gratis- ricaricando forse un poco sulle assistenze :lol: - il lavoro è lavoro e a fine mese i conti so tanti)

ricostuendo tutto il programma sulla base delle tabelle di oscommerce, apportando alcune semplici modifiche ai campi sul server on line e sul database in locale, fare la sincronizzazione dei due sarebbe MOLTO semplice.

facendo questo gestionale (inizialmente solo per la fatturazione - per vendita on line e al banco, con lagestione della cassa e degli scontrini, poi integrabile con la gestione magazzino - un unico magazzino per i due negozzi - che poi in realta è così- e altre funzioni quale la gestione dell'assistenza tecnica quando ci portano un prodotto in riparazione con -realizzando un modulo aggiuntivo per oscommerce- la visione dello stato di lavorazione on line)

io sono in grado di realizzare questo "gestionale" e renderlo tuttuno con oscommerce.

il problema è il seguente:

personalmente no ho molto tempo per la realizzazione di questo software.
ma purtoppo, vedendo i miei bisogni legati alla gestione del lavoro, un applicativo con le funzionalità su descritte ( e in più open quindi modificabile e integrabile in base alle più svariate esigenze di chi lo usa) e di fondamentale importanza e renderebbe oscommerce completo sotto molti punti di vista.
quindi in un modo o nell'altro sono COSTRETTO a realizzarlo.

come su detto sono a livello software smanettone (non mi posso definire programmatore perchè sarebbe un'offesa a chi programmatore lo è veramente e in modo serio e professinale) il programma lo potrei realizzare solo in access ( e quindi non sarebbe più totalmente gratuito perche per farlo girare è richiesto il relativo software a pagamento - e non poco-) non perchè non conosca ad esempio vusual basic, ma perche con esso impiegherei troppo tempo.

(ho letto da qualche parte che esistono programmi che convertono i programmi fatti con access in visual basic e quindi realizzare l'eseguibile non più legato al primo, ma
1 non sono mai riuscito a trovali
2 non so quanto possano funzionare)

Vorrei trovare tra di voi qualche smanettone o programmatore per la realizzazione in visual basic di questo applicativo in modo che si rendano disponibili (open) sia i sorgenti che l'eseguibile.
da parte mia posso fornire tutti i dettagli tecnici su come fare, cosa devono fare e come lo devono fare, loro devono solo (pare poco detto cosi, ma è la magior parte del tempo e del lavoro) scrivere il codice.
ci possiamo anche dividere il lavoro (come una vera comunità open)
uno fa la parte grafica e lo fa bello, io curo l'aspetto tecnico relativo alla gestione del database, altre due 3 persone scrivono il codice relativo ad altrettanti sezioni.

Se non trovo nessuno che mi da una mano, lo ripeto ne sono costretto vista l'importanza e la fondamentalità dell'aplicativo in questione, lo realizzero in access e lo pubblicherò su questo forum (come ha già fatto il grande Bass con il suo applicativo).

sinceramente una cosa che mi darebbe molto fastidio: è che il mio lavoro sia usato da persone che sfruttano l'open e che non forniscono ad esso un minimo contributo, ma stanno li come avvoltoi pronti esclusivamente a beneficiare del lavoro degl'altri.

e vi posso assicurare che ce ne sono tanti.

se si è una decina di persone a lavorare su un progetto, ok, degli avvoltoi non me ne frega niente, anzi paradossalmente arrivo a dire che danno anche loro un grosso contribbuto alla diffusione del progetto (già realizzato da altri), ma se sono da solo ci rosico un poco (per non dire tantissimo) poichè da solo ci impigherei 10 volte di più come tempo, la qualità sarebbe 1/100, e soddisferebbe solo le mie esigenze, e cosa fondamentale, TUTTI i problemi che si verrebbero a creare con l'applicativo ( i cosiddetti Bugs) sarebbero i miei, senza nessuno che mi dia una mano e risolveri o quantomeno a darmi un'idea o supporto morale: il che significa che mi dovrei fare un gran buxxxio di cuxxxo.

non mi dilungo oltre (l'ho già fatto abbastanza esponedo il mio pensiero, che spero sia stato chiaro per tutti)

sono aperti i reclutamenti, fatemi sapere.
E scusate ancora della lungaggine del presente 3d.

Inviato: 20/11/2005, 22:16
da M3gaHeRtZ
:D Io sono un grafico quindi...per la grafica non c'è problema e per puro caso di mastico anche un po' di visual basic e guarda caso quel poco che mastico l'ho principalmente usato per applicativi di gestione magazzino e fatturazione per alcuni clienti.
Per la grafica quindi io ci sono e se serve posso anche aiutare a codare.

Ciacciaooo! :wink:

Inviato: 20/11/2005, 22:39
da Bass
M3gaHeRtZ ha scritto: Per la grafica quindi io ci sono e se serve posso anche aiutare a codare.
Io purtroppo sono anni che non programmo in VB e ho anche pochissimio tempo, credo di non ricordarmi nemmeno come si fa.
Comunque mi propongo come tester, il VB originale ce l'ho ancora anche se deve essere un edizione un poco vecchiotta :)

'iao

Sergio

Inviato: 20/11/2005, 23:13
da DarkAmex
Il progetto è piuttosto ambizioso ma può essere fatto, direi però di cercare una base:

1) Secondo me utilizzare VB non è il massimo quando si tratta di ricavare dati da MySQL (soprattutto quando si lavora on-line) servirebbe un linguaggio un pò più versatile... C++, Java, PHP, Phyton...
2) Sarebbe molto dispendioso in termini di tempo... anche per una piccola comunità (a meno che non si parta da una base...)
3) Serve qualcuno che conosca bene MySQL...

Inviato: 20/11/2005, 23:36
da CountZero
Ciao,
io programmo anche in VB, ma al momento sono FULL su altri progetti e comunque non conosco benissimo problematiche di Magazzino ed affini.

Di applicazioni che convertono il codice di Access in codice VB, non ne ho mai visti funzionare bene... comunque penso che il problema sia relativo.

Puoi tranquillamente realizzare il tutto in Access e poi realizzare un pacchetto di installazione con il file MDB (il db access e il programma fatto da te) ed il SOLO runtime di access.
Così facendo PUOI distribuire il tuo pacchetto senza avere l'obbligo di avere su ogni macchina una licenza di Access.
Naturamente con il solo runtime non puoi fare delle modifiche al file mdb e lavorarci come se tu avessi il pacchetto completo di Access.

Spero di essere stato utile.
Personalmente posso essere di supporto per la realizzazione del pacchetto di installazione.
Ciao

Inviato: 21/11/2005, 2:06
da deromas
perfetto. gia trovati alcuni collaboratori, e a parere mio, una importante info fondamentale di cui non ero a conoscenza:
CountZero ha scritto: Puoi tranquillamente realizzare il tutto in Access e poi realizzare un pacchetto di installazione con il file MDB (il db access e il programma fatto da te) ed il SOLO runtime di access.
Così facendo PUOI distribuire il tuo pacchetto senza avere l'obbligo di avere su ogni macchina una licenza di Access.
Naturamente con il solo runtime non puoi fare delle modifiche al file mdb e lavorarci come se tu avessi il pacchetto completo di Access.
se cosi è (però dicci come si fa perchè sono ingorante, ovvero questa me manca...) io direi di scrivere il tutto in access compreso il codice (visual basic) per operazioni più "a basso livello" che lo stesso access non permette o permette malamente.

questo perchè è il sistema più semplice per "programmare" con i database - fermo restando quello che ha detto CountZero- e il sistema sarebbe perfettamente open, non legato all'acquisto della licenza per chi lo deve usare, modificabile con semplicità anche da non esperti ed adattabile a tutti.

M3gaHeRtZ si occupera dell'aspetto grafico e le altre persone del gruppo di stendere il codice per i moduli.

perfetto, poche ore e già a buon punto (qualcuno diceva:"chi ben comincia è gia a metà dell'opera....... -se, magari!!!-)

andiamo per passi.
per prima cosa io direi di iniziare con la gestione dell'anagrafica e di porci come limite di tempo (poi se sforiamo chi se ne frega, mica ci pagano o chi ci corre dietro?) domenica prossima.
domani a pranzo e poi la sera inizio a fare un'analisi sulla sezione "anagrafica" e vi posto i risultati e vi dico sul da farsi.

x M3gaHeRtZ: a te ora il compito più difficile (per il momento).
cerca di immaginare le maschere del programma, casomai butta giù qualcosa e le posti come immagini. ricorda per ora sono necessari:

1 schermata iniziale: da dove gestire e richiamare tutte le parti del programma
2 le varie schermate per la gestione anagrafica "inserimento, modifica, ricerca etc."

prendi in considerazione una risoluzione 1024x768 (credo che oggi sia la più usata).
per ora non serve un lavoro rifinito, ma grossolano (del tipo: un riquadro grosso con scritto "qui ci vanno i campi con i dati del clente2, e non tutti i campi nome comgnome etc - in questo momento non sappiamo con esattezza quanti campi sono-) tanto per dare l'idea della posizione degli oggetti sulla schermata.
poi domani, finita l'analisi, ti do' i nomi dei campi e dove andare a pescare i dati

credo di riuscire domani a dare le prime direttive per la stesura dei primi moduli in vb

per ora grazie a tutti per le risposte e per la disponibilita, ora vado a nanna che si è fatta una certa.

Inviato: 21/11/2005, 2:06
da deromas
perfetto. gia trovati alcuni collaboratori, e a parere mio, una importante info fondamentale di cui non ero a conoscenza:
CountZero ha scritto: Puoi tranquillamente realizzare il tutto in Access e poi realizzare un pacchetto di installazione con il file MDB (il db access e il programma fatto da te) ed il SOLO runtime di access.
Così facendo PUOI distribuire il tuo pacchetto senza avere l'obbligo di avere su ogni macchina una licenza di Access.
Naturamente con il solo runtime non puoi fare delle modifiche al file mdb e lavorarci come se tu avessi il pacchetto completo di Access.
se cosi è (però dicci come si fa perchè sono ingorante, ovvero questa me manca...) io direi di scrivere il tutto in access compreso il codice (visual basic) per operazioni più "a basso livello" che lo stesso access non permette o permette malamente.

questo perchè è il sistema più semplice per "programmare" con i database - fermo restando quello che ha detto CountZero- e il sistema sarebbe perfettamente open, non legato all'acquisto della licenza per chi lo deve usare, modificabile con semplicità anche da non esperti ed adattabile a tutti.

M3gaHeRtZ si occupera dell'aspetto grafico e le altre persone del gruppo di stendere il codice per i moduli.

perfetto, poche ore e già a buon punto (qualcuno diceva:"chi ben comincia è gia a metà dell'opera....... -se, magari!!!-)

andiamo per passi.
per prima cosa io direi di iniziare con la gestione dell'anagrafica e di porci come limite di tempo (poi se sforiamo chi se ne frega, mica ci pagano o chi ci corre dietro?) domenica prossima.
domani a pranzo e poi la sera inizio a fare un'analisi sulla sezione "anagrafica" e vi posto i risultati e vi dico sul da farsi.

x M3gaHeRtZ: a te ora il compito più difficile (per il momento).
cerca di immaginare le maschere del programma, casomai butta giù qualcosa e le posti come immagini. ricorda per ora sono necessari:

1 schermata iniziale: da dove gestire e richiamare tutte le parti del programma
2 le varie schermate per la gestione anagrafica "inserimento, modifica, ricerca etc."

prendi in considerazione una risoluzione 1024x768 (credo che oggi sia la più usata).
per ora non serve un lavoro rifinito, ma grossolano (del tipo: un riquadro grosso con scritto "qui ci vanno i campi con i dati del clente2, e non tutti i campi nome comgnome etc - in questo momento non sappiamo con esattezza quanti campi sono-) tanto per dare l'idea della posizione degli oggetti sulla schermata.
poi domani, finita l'analisi, ti do' i nomi dei campi e dove andare a pescare i dati

credo di riuscire domani a dare le prime direttive per la stesura dei primi moduli in vb

per ora grazie a tutti per le risposte e per la disponibilita, ora vado a nanna che si è fatta una certa.

Inviato: 22/11/2005, 14:21
da deromas
scusate gente se ancora non hi fatto l'analisi, ma ha causa di un lutto ne ieri ne oggi mi sarà possibile farla. la eseguirò al più presto.
intanto se postate le cose che vi ho chiesto sui 3d precedenti vi sarei grato.

Inviato: 22/11/2005, 17:45
da Ricsca
Io non ho capito niente ma l'idea mi sembra buona! :)

Inviato: 22/11/2005, 22:06
da blackviper
Ricsca ha scritto:Io non ho capito niente ma l'idea mi sembra buona! :)
IO concordo e rispondo per tenere alto il post,non sarebbe male l'idea,ma cmq non e' affatto facile,sopratutto perche' e' una delle parti piu' delicate di tutto il sistema o sbaglio?

Inviato: 22/11/2005, 22:09
da feddar
blackviper ha scritto:
Ricsca ha scritto:Io non ho capito niente ma l'idea mi sembra buona! :)
IO concordo e rispondo per tenere alto il post,non sarebbe male l'idea,ma cmq non e' affatto facile,sopratutto perche' e' una delle parti piu' delicate di tutto il sistema o sbaglio?
+1 mi associo... :)

Inviato: 22/11/2005, 22:14
da duketrt
Leggo solo ora questo post ma sono disponibile a contribuire con il mio a questo ambizioso ma oltremodo utile progetto.
Un mio socio nel negozio stava cercando di valutare quale programma gestionale affiancare a osc per tutto quello che e' "separato" dall'ecommerce e invece ecco qui che leggo questo post e mi scimmio con sta idea.
Per quello che mi riguarda nonostante la scarisita' di tempo metto a disposizione una "decente" conoscenza di qualsiasi linguaggio di programmazione e sopratutto conoscenze di architetture sw basi di dati e progettazione sw.
Nello specifico, conoscendo osc da poco piu' di 1 settimana, potrei dire che il linguaggio di programmazione piu' adatto per sviluppare un applicativo come da te descritto e' C#.
Sia per la modalita' di connessione a ODBC che per la comodita' di poter utilizzare un linguaggio un po' piu' versatile di VB.
Per ora non dico altro ma do la mia disponibilita' in questo progetto che mi pare molto interessante nonstante come premesso non e' che abbia moltissimo tempo da dedicarvi ma quello che ho glielo dedicherei volentieri :)

Inviato: 24/11/2005, 1:06
da deromas
:) :o :lol: :lol: CI SONO RIUSCITO :shock: :D :) :o :lol: :!: :!: :shock: :D :) :o :lol: :lol:

ho collegato i due database.... è semplicissimo...... domani, lavoro permettendo, posto la prima versione in access dell'anagrafica e spiego come fare....


la grafica a che punto stà?

e le istruzioni per rendere access indipendente???

ragazzi dai che ci riusciamo, non è affatto complicato anzi, A ME ME PARE UNA STRUNZ:

è più semplice del previsto!!!
ora però mi chiedo: perchè non ci ha mai provato nessuno?

Inviato: 24/11/2005, 4:05
da deromas
quasi finita la prima relase... mo vado a dormire che s'è fatta una certa.

ma non posta più nessuno?

Inviato: 24/11/2005, 13:31
da duketrt
A ma avete gia' organizzato tutto? io ho letto solo 2 giorni fa' il post quando ho risposto e qui gia' parlate di grafica a che punto sta etc... ok mi sa che pago il fatto che sono nuovo del forum e mi saro' perso degli altri post :)