Newsgroup: it.comp.appl.access
Titolo: Gestionale Access

Re-inoltro, che' forse è finito sotto altra discussione.
-------------------------------
Attualmente in azienda abbiamo (sigh!) due sw: uno (passapartout) che
gestisce le bolle - e quindi anche gli articoli di magazzino - fatture,
contabilità generale e fiscale.
L'altro, da me realizzato in Access negli anni, che, pur essendo
realizzato con nulla competenza, gestisce molto analiticamente il
magazzino, con descrizioni, posizioni, e un sacco di altre informazioni
che sul gestionale di contabilità non ci starebbero. I dati raccolti
negli anni sono una marea.
Chiaramente, quando si ha un articolo nuovo, ci tocca aggiornare due
sw, con i rischi di errori che si possono facilmente immaginare.
L'idea balzana del 2007 e' quella di unire di due sw.
Il percorso che mi sentirei di seguire è quello di trovare un gestionale
basato su Access nel quale far confluire il mio DB di magazzino.
A questo punto la domanda: mi chiedevo non solo se esiste la possibilità
di fare cio', ma anche quale potrebbe essere un gestionale access-based
abbastanza flessibile, ma che sia affidabilissimo dal punto di vista
contabile ed eventualmente provabile in demo per vedere se il merge è
possibile.
Marco

 wrote in message 
news:45b78052$0$22139$4faf...@reader3.news.tin.it...

Io ho un gestionale che potrei mostrarti.
Abito a Forlì, tu di dove sei?
Bruno 

Bruno Campanini ha scritto:

---
Di Bologna, se puoi prox settimana faccio un salto.
Ti lascio qui una mail che guardo: pinchos at tin punto it.
M.

 Abito a Forlě, tu di dove sei?
Certo che ... trasferire piano dei conti e movimenti contabili tra
gestionali eterogenei č un lavoro bestiale (e sa Dio come va a finire)  ;-)
Ciao.

 Ciao.
Se si accetta il disagio di tenere i piedi su due staffe
per quanto concerte l'analisi dei singoli movimenti
contabili, si possono semplificare notevolmente le
cose trasferendo i saldi a una certa certa data e da
quella operare sul nuovo programma.
L'ho fatto diverse volte, che ci vuole?
Tale trasferimento è senz'altro
l'operazione più semplice: se i programmi
possono comunicare fra di loro (non è detto che
possano...) si fa in un baleno, diversamente si dovrà
fare manualmente. Quanti conti sono? un migliaio?
Ci vorranno un paio di giorni.
L'operazione più noiosa - sempre ammessa
l'incomunicabilità - è senz'altro il trasferimento
dell'anagrafica Clienti-Fornitori.
Ciò fatto si marcia su due binari per qualche mese
ovvero fino a quando non si sia verificato che:
- le due contabilità parallele sono perfettamente coincidenti
- la nuova contabilità funziona come richiesto
L'osso più duro dovrebbe essere il magazzino però, da
quanto capisco, esso funziona separatamente dalla
contabilità e separato deve rimanere.
Bruno 

 dell'anagrafica Clienti-Fornitori.
Naturalmente la mia è solo un'opinione basata su esperienze precedenti: non
vuole esser regola  ;-)
Diciamo che già il trasferimento delle anagrafiche può esser problematico
(lunghezze campi diverse, Flags previsti da una parte e non dall'altra,
struttura del Piano dei conti etc.).
Ma il grande problema riguarda, a mio avviso, i movimenti contabili e di
magazzino: in genere gestionali eterogenei hanno strutture dati estremamente
diverse: degli archivi che contengono i movimenti ma anche e soprattutto
delle Causali Contabili e di Magazzino.
PassPartout poi (ma forse è cambiato ultimamente) era una brutta bestia:
archivi proprietari da cui poter attingere solo con opportuni "Sprix"
d'esportazione.
Oltre ad avere una struttura degli archivi contabili _pensata per
commercialisti_ molto complessa.
Comunque, ripeto, non voglio fare l'uccello del malaugurio!
Ciao.

 delle Causali Contabili e di Magazzino.
Per come la vedo io i movimenti contabili non vanno trasferiti.
Costruito il piano dei conti (costruito, non trasferito!) si fa una
situazione contabile diciamo a fine gennaio, si riportano i saldi
sul nuovo programma e dal primo di febbraio si tengono due
contabilità parallele.
Poiché normalmente (diciamo al 70/80%?) al sistema contabile
vengono richieste situazioni piuttosto che vicende storiche, nella
stessa percentuale le istanze possono essere rivolte al nuovo
programma.
Quando sono richieste vicende storiche occorrerà integrare
le due istanze (quella sul vecchio e quella sul nuovo).
Non dovrebbe essere un gran problema.
Esattamente come avviene tutte le volte che nel gennaio 2007
tu voglia non solo il saldo di un fornitore ma anche la disamina
dei suoi movimenti dal quarto trimestre dell'esercizio precedente.
Come procedi? Riposizioni il programma sull'esercizio
precedente etc. etc...
Non vedo particolari difficoltà.
Il magazzino sarebbe l'osso più duro nella circostanza se,
come già detto, non dovesse rimanere separato.
I collegamenti che di volta in volta si intenda porre in atto
saranno poi croce e delizia di chi vi si appresti.
Bruno 

 Non vedo particolari difficoltà.
Sì, questa è la procedura che si utilizza di solito quando si passa una
ditta da una procedura aziendale all'altra.
Mi pareva d'aver capito che, in questo caso, l'amico chiedesse di trasferire
integralmente i dati da un software all'altro.
Richieste di questo genere mi sono capitate varie volte: tanti credono che
sia non molto più difficile che fare una fotocopia.
Ciao.

 sia non molto piů difficile che fare una fotocopia.
Sě, č proprio cosě!
E ti dicono: "tanto i dati son tutti lě, no?"
Bruno 

 E ti dicono: "tanto i dati son tutti lì, no?"
Eh, eh, eh: tutto il mondo è paese...    ;-))
Ciao.

 
---
Perche', non è cosi?
;-)
No, so che ci sara' uno sporco lavoro manuale da fare.
Male che vada posso anche ricaricare i dati di 2 mesi di contabilità.
E' ricaricare 3000 record con 25 campi ognuno (magazzino) che mi è assai 
piu' problematico.
M.

 M.
Avevo capito che il magazzino dovesse restare separato e
che dovessi "far confluire" soltanto i dati che servono alla
contabilità generale (fatturazione, etc.), facendo altresì
"defluire" le codifiche dell'anagrafica necessarie al magazzino.
Se i programmi possono agevolmente comunicare fra di
lororo non è la soluzione migliore quella di tenerli separati?
E non mi sembra una soluzione di ripiego.
Bruno