ARGOMENTO: elenco funzionalità presenti e future

marcomarkiori ha scritto:"La localizzazione italiana di openerp comprende tutte quelle funzionalità che servono solo alle aziende italiane."
Perchè ambiguo?
La community si può occupare di tutto quello che crede.
Forse se ci fai degli esempi degli altri problemi funzionali capiamo meglio

enlightx ha scritto:Fortunatamente qualcuno in più c'è.
Inoltre, grazie a chi ha scritto documenti di specifiche, siamo riusciti a produrre diversi moduli interessanti.

Fortunatamente si

Cmq siamo l'unico paese dove stiamo cercando di costruire la localizzazione collettivamente.

Negli altri paesi c'è qualche azienda dittatrice che ha sviluppato il pacchetto e gli altri dipendono da lei.

Se vogliamo accelerare possiamo comportarci così anche in Italia...decidiamo...

Rispondo solo a questo perché è secondo me la fonte dei vari malintesi.
Aziende italiane sono quelle che operano in Italia? Che operano solo con l'Italia? Che hanno sede in Italia? Che applicano IVA italiana? Che usano banche italiane?
Ora se è un fumoso concetto commerciale è ragionevole secondo voi agganciare un lavoro comune a un concetto così?

Secondariamente secondo me
- il problema della chiusura dei conti NON è localizzazione
- i formati per interfacciarsi con le banche FORSE sono localizzazione ma le scritture NON sono localizzazione
- il problema della progressività NON è localizzazione
- il calcolo "verticale" delle imposte NON è localizzazione
- neanche la liquidazione dell'IVA

Invece
sono localizzazione tutta una serie di reports utili e richiesti da autorità pubbliche o istituti bancari italiani (anche questo diminuirà molto). Neanche la traduzione è strettamente localizzazione...

Non sto affatto dicendo che non stiamo lavorando seriamente o che sono pessimista, dico solo che un lavoro comune porta maggior beneficio se utilizziamo concetti forti e non ambigui.
La localizzazione è un concetto perdente, superato.

marcomarkiori ha scritto:Giusto, allora diciamo le aziende soggette alla legge italiana.
Certo. Non mi sono mai occupato direttamente delle specifiche, ma dovremmo sicuramente produrre qualcosa di internazionale, possibilmente senza duplicare il lavoro che magari qualcuno sta facendo in altri paesi.
Certo. Infatti in questo ambito i lavori dovrebbero focalizzarsi sull'analisi dei vari progetti già esistenti, tipo account-banking
Certo. Infatti intendevamo produrre il modulo 'account_invoice_free_number', ma nessuno l'ha mai portato avanti
In generale no, infatti abbiamo prodotto 'account_invoice_tax_by_column'. Solo che questo modulo è fatto per gestire il calcolo verticale anche nel caso di IVA parzialmente detraibile, che solo la legge italiana prevede.
Eventualmente se ne potrebbe fare uno generico (account_invoice_tax_by_column), ed uno l10n_it_* che lo estende aggiungendo solo la gestione dell'IVA parzialmente detrabile.
Dipende, perchè ad esempio i debiti/crediti del periodo precedente in molti paesi non ci sono. Comunque in questo caso personalmente devo ancora capire quale sia la strada migliore, ne parleremo.
Perfettamente d'accordo

Questo non sarebbe molto giusto, nel senso appunto che è ambiguo... ma essendo tu un informatico ti perdono.

SE invece tutto il resto è un florilegio di "sono d'accordo" ne conseguirebbe che la nostra attività (a mio modestissimo parere) si dovrebbe organizzare per cicli/processi e gli aspetti locali o localistici dovrebbero entrare in gioco come specificazione o variante di un sistema solido o non-localizzato.

Ad esempio:
Un purchase journal deve raccogliere un set di informazioni e generare una contabilità;
un purchase journal per essere utilizzato a certi effetti in Italia deve raccogliere/includere alcune informazioni;
un registro IVA acquisti deve attingere al purchase journal e, secondo alcune specifiche può comprendere alcune funzionalità...

La community dovrebbe essere utile a coordinare ciò che si fa sul purchase journal (controllo del processo di acquisto) di cui una parte solo è stretta applicazione di norme o consuetudini locali.