ARGOMENTO: localizzazione italiana (traduzione/funzionalità)

Il IRC si è iniziato a discutere riguardo la creazione di alcuni profili "italianizzati" per OpenERP 5.x

Per rendere l'idea, intendiamo qualcosa tipo:

1. "Azienda di servizi italiana"
2. "Azienda manifatturiera italiana"
3. "Solo contabilità italiana"
4. ...

Per arrivare a fare ciò, dobbiamo raccogliere tutto quello che stiamo facendo e creare un pacchetto per la localizzazione.
I fronti su cui si sta lavorando collettivamente coordinandoci su IRC, sono:

1. piano dei conti
Abbiamo 2 PDC, più o meno minimali, adatti ad esigenze generiche.
Ne creeremo uno completo al massimo, più per pubblicità che per altri motivi, visto che è impossibile avere un PDC che vada bene a due aziende diverse.

2. Dati societari
Supporto a PIVA e CF c'è.
Magari mettiamo un minimo di validazione e aggiungiamo anche i campi REA, capitale sociale e simili in base alle ultime esigenze normative.

3. Reportistica
Abbiamo quasi finito di preparare dei report completi per fatture, pro-forma, ordini, ddt, etichette prodotto con supporto barcode e simili, utilizzando un nuovo sistema di crezione di report che si basa su quello utilizzato da tryton, ancora in fase ultra alpha, ma per lo meno non bisogna impazzire con Reportlab e RML per avere dei report decenti.

4. Campi mancanti
I campi mancanti per DDT, fatture e simili vengono aggiunti tramite un modulo apposito, che verrà aggiornato man mano che il legislatore si inventa qualcosa di nuovo.

5. Registri IVA / Bilancio
In OpenERP c'è tutto, solo che si chiama diversamente e non si trova dove uno se lo aspetta, quindi possiamo rinominare i menù e dare una forma più "Italiana" al tutto.

6. Bilancio CEE
Il deposito del bilancio non centra quasi nulla con un ERP, siccome è un qualcosa che le aziende non fanno mai internamente, ma senza di quello sembra quasi che un ERP non possa funzionare.
Alla fine si tratta di creare un PDC parallelo e fare una mappatura campo-campo tra il PDC e quello CEE, a cui associare un report dedicato.

7. Paghe
Anche qui, caratteristica quasi inutile in un ERP visto che il 99% delle aziende si appoggia ad uno studio di consulenza per i cedolini. Tuttavia ho iniziato a prendere contatti con un'azienda che sviluppa un software di gestione paghe, per il quale da supporto di aggiornamento fiscale, e che sta pensando di rilasciare sotto licenza GPL. Il software è in Java lato cliente, ma per lo meno si ha qualcosa di libero da integrare.

8. Aliquote IVA, Ritenute, Rivalsa, etc etc
Inseriamo nel PDC tutte le aliquote e le tasse che ci vengono in mente, così che gli utenti non debbano inserirsele a mano dopo l'installazione.

9. Modalità di pagamento
Idem come sopra.
Per la RI.BA. stiamo lavorando al supporto del formato CBI, ormai utilizzato da "quasi" tutti i sistemi di home-banking. Per i sistemi che ancora non lo usano, solitamente si lavora in CSV, quindi il supporto di export di OpenERP è sufficiente. Ovviamente bisogna mettersi d'accordo con il proprio istituto di credito se il loro sistema non supporta CBI.

10. Traduzione software e manuali
La traduzione collettiva "per capitolo" non è andata molto a buon fine, siccome siamo indietro e soprattutto per il fatto che ognuno interpreta i termini tecnici a proprio modo.
Forse converrebbe prima fare un glossario?
Facciamo una colletta e "compriamo" la traduzione?

11. Servizio di aggiornamento fiscale/normativo
Le aziende hanno paura ad usare un software che non abbia un servizio di aggiornamento.
In realtà non sarebbe necessario, in quanto sono gli utenti che devono adeguare il loro modo di lavorare in base alle normative. Nel senso che se campia l'aliquota IVA del pane, è l'utente che deve selezionare l'aliquota corretta. Se c'è da aggiungere un campo al report del DDT perchè non lo può fare l'utente?
I sistemi commerciali che danno questo tipo di supporto, ovviamente costano, e anche cari.
Perchè un'azienda che vende servizi dovrebbe pagare gli aggiornamenti quando in un anno magari arriva un aggiornamento per i fruttivendoli e uno per i panettieri?
Comunque, è giusto che le aziende si sentano sicure. Ed è giusto che OpenERP si adegui dove può alla normativa italiana.
Che ne dite di organizzare un servizio di aggiornamenti collettivo?
Ovviamente deve essere qualcosa di organizzato a dovere, gestito da professionisti del settore e convalidato da altri professionisti del settore.

Nella community ci sono commercialisti? contabili? o figure che operano nel settore fiscale?

12. Altro
Ci sono altre "urgenze" che vedreste bene per un pacchetto di localizzazione?

13 ) ritenute e fatture , devono potere essere calcolati correttamente tutti i tipi di ritenuta e di conseguenza anche il pagamento deve essere corretto.

14) export cbi dei bonifici.

15) Pe rla riba il giro contabile e' diverso rispetto a un debito / credito con bonifico.

16) Valorizzazione di magazzino al costo medio , credo che oerp ce l'abbia gia' ma non ho approfondito.

17) cespiti ? forse non fondamentali .

non mi viene in mente altro per ora

umibozu ha scritto:
Qui dietro c'è il concetto di fondo di OpenERP.
Ciò che dobbiamo fare non è "calcolare correttamente", ma dare la possibilità agli utenti con configurare correttamente il calcolo.
OpenERP è un progetto libero, quindi deve essere il più possibile orizzontale.

Per OpenERP le ritenute, l'iva, la rivalsa previdenzione e così via sono degli oggetti di tipo "tassa".
Se andate nella configurazione delle tasse e avete selezionato l'interfaccia estesa durante l'installazione, vi troverete un immenso ed incomprensibile form con il quale potrete creare il vostro tipo di tassa.

Ciò che comunque conviene fare e "pre-impostare" tutti i tipi di tassa che ci vengono in mente, assicurandoci che il calcolo di ritenute e fatture risulti corretto, ma sta di fatto che dobbiamo comunque concentrarci sul tool più che sui tipi pre-impostati.
Altrimenti ci troviamo un classico gestionale italiano che risulta vecchio dopo 6 mesi dal suo concepimento.

Si, giusto.
Anche se...quali home-banking lo supportano?
Cmq, più supporti abbiamo, meglio è

Certo, il pacchetto dovrà creare i movimenti corretti.
Inizialmente si può utilizzare account_voucher, che permette di impostare la serie di movimenti manualmente.

Si c'è.
Ciò che farei è creare delle viste e dei report semplici da comprendere riguardo a questo argomento.

La gestione cespiti e ammortamento c'è.
Onestamente non ho mai approfondito quanto siano diverse le normative tra i vari paesi europei, e quindi quanto sia adatto al nostro paese.

Ci verrà in mente!

PS: chi c'è per dare una mano?

Ciao, per cose non contabili ci sono.
Come già detto ad Davide, sul DDT mancano alcuni campi essenziali come:
-l'aspetto dei beni
- numero dei colli
- Volume dei colli
- peso dei colli
- causale di vendita

Questi campi sopracitati sono già stati inseriti in un modulo che ho fatto per me per poter fare i DDT. In modo semplice e veloce si possono trasportarequesti campi su un modulo standard da definire.

Inoltre, credo sia MOLTO UTILE aggiungere nella tabella sale.order.line 2 campi relativi a il costo di listino del prodotto e il costo standard, questo è per aver traccia nel tempo dei dati fondamentali per poter risalire ai ricarichi e sconti vari.

luca

a breve creo un branch di gruppo su openobject-italia dove iniziamo a fare il merge dei nostri lavori.

Quei campi del DDT in realtà ci sono o sono calcolabili/riciclabili.
forse manca "aspetto dei beni"