Nel file l10n_it_spesometro/spesometro.py a riga 28 è stato definito il
campo
codice_stato_agenzia_entrate
che è un duplicato del campo ufficioiva della tabella res.country nel nuovo
modulo l10n_it_base in fase di approvazione
Inoltre nel modulo l10n_it_base in fase di approvazione sono
L'appartenza o meno alla UE è un dato universale che serve ovunque.
Il campo nazione invece serve alle dichiarazioni verso l'ufficio IVA. Se
questo modulo sarà usato per tutte le comunicazioni polivalenti, allora
il campo dovrebbe stare in questo modulo. Allo stato attuale, però il
codice
Esiste il modulo l10n_it_account, nel quale dovrebbero stare tutte le
configurazioni e la logica relativa ai dati contabili.
Se parliamo di IVA, forse quello è il posto giusto (anche se il modulo, come
tutti gli altri, avrebbe bisogno di refactoring estremo).
Appartenenza a EU o meno, sono
Per l'appartenenza a EU - l10n_it_base ok
I campi IVA - l10n_it_account ok
Per i dati come Cognome, Nome, Data nascita ecc legati alla persona fisica?
Per me sono da mettere su l10n_it_account.
Anzi farei anche un page specifico nella scheda cliente tipo Dati fiscali.
Non penso che farli sulla
Per me, che non ho esperienze precedenti con OpenERP, ogni soluzione è buona
Sulla base di quanto dice Davide proporrei quanto segue:
- I campi blacklist e blacklist_date inserirli in l10n_it_account (non
dovrebbero dare problemi alle versioni precedenti)
- Il campo con nome da conccordare
On 03/13/2014 09:24 AM, Antonio M. - Zeroincombenze wrote:
Colgo l'occasione per segnalare che nella tabella abbiamo aggiunto anche
2 campi per il SEPA (paese aderente a SEPA e data di accesso),
I moduli SEPA e bancari in generale sono qua
https://launchpad.net/banking-addons
--
ho messo anche 1 come default sul pagina iniziale della liquidazione.
Ciao
--
https://code.launchpad.net/~a-camilli/openobject-italia/7.0_liq_IVA_opzioni_stampa/+merge/210669
Your team OpenERP Italia core devs is subscribed to branch
lp:openobject-italia/7.0.
Public bug reported:
Found bad country transaltion.
=
Repubblica Dominicana is double but they refer to 2 different counties:
iso3166 = DO - Repubblica Dominicata (right)
iso3166 = DM - Dominica (currently wrong)
===
Nigeria is double but but they
Nell'ultimo push oltre ai suggerimenti di Lorenzo, ho aggiunto la gestione del
Documento riepilogativo usato principalmente per la scheda carburante.
--
https://code.launchpad.net/~a-camilli/openobject-italia/6.1-spesometro/+merge/210439
Your team OpenERP Italia core devs is subscribed to
Ciao Alessandro, grazie ancora per il modulo :-)
Negli header potresti aggiungere il copyright dell'associazione?
#Copyright (C) 2014
#Associazione OpenERP Italia (http://www.openerp-italia.org)
Ovviamente se vuoi puoi anche aggiungere il tuo
riga 64: come website,
Public bug reported:
In base module thera are 2 countries no yet existent:
iso3166-yu - Yugoslavia does not yet exist, now it is Serbia iso3166 = SR
iso3166-zr - Zaire is old name of Democratic republic Congo iso3166 = CD
** Affects: openobject-italia
Importance: Undecided
Status:
Blueprint changed by Antonio M. - Zeroincombenze:
Approver: (none) = OpenERP Italia core devs
--
Refactoring l10n_it_base
https://blueprints.launchpad.net/openobject-italia/+spec/l10n-it-base-v8
___
Mailing list:
Thanks for the report.
That looks like a problem in the translation of the core openerp,
(project openobject-server).
You should be able to fix the translation directly from Launchpad.
** Project changed: openobject-italia = openobject-server
** Changed in: openobject-server
Status: New
Sinceramente non ho capito. Vorrei che ogni volta che viene salvata la
comunicazione vengano ricalcolati i totali di tutti i quadri
Se le righe della comunicazione vengono modificate sempre e solo tramite
il form della comunicazione, allora dovrebbe funzionare anche solo con
store=True
Concordo con quanto detto da Lorenzo, stiamo provando anche noi il
base_location e non vedo problemi.
Anzi stiamo convertendo il file csv dei comuni / regioni in un formato XML
cercando di standardizzare quanto fatto da altre localizzazioni
Il giovedì 13 marzo 2014, Lorenzo Battistini - Agile BG
On 13 Mar 2014, at 16:14, Franco Tampieri fra...@tampieri.info wrote:
Anzi stiamo convertendo il file csv dei comuni / regioni in un formato XML
cercando di standardizzare quanto fatto da altre localizzazioni
Per quale motivo?
In questi casi trovo il CSV più comodo del XML
--
Davide Corio
On 13 Mar 2014, at 16:39, Info SHS-AV i...@shs-av.com wrote:
Il problema non è il CSV o il file XML ma la funzionalità.
Due argomenti differenti :)
Dire che il modulo in oggetto è migliore perchè lo usano svizzeri e spagnoli
mi sembra una motivazione fragile e non comprendo perchè sia
Sono d'accordo con Davide, io purtroppo in passato ho fatto il tuo stesso
errore e poi a posteriori mi sono reso conto che quello che pensavo fosse
una localizzazione invece era un verticalizzazione per un certo tipo di
clienti o addirittura per un cliente.
Pensa che addirittura sto rivalutando
Il 13/03/2014 17:05, Franco Tampieri ha scritto:
Sono d'accordo con Davide, io purtroppo in passato ho fatto il tuo
stesso errore e poi a posteriori mi sono reso conto che quello che
pensavo fosse una localizzazione invece era un verticalizzazione per
un certo tipo di clienti o addirittura per
Andrea Cometa has proposed merging
lp:~coopenerp/openobject-italia/7.0-adding-intra-cee into
lp:openobject-italia/7.0.
Requested reviews:
Andrea Cometa (scigghia)
Davide Corio @ LS (enlightx)
For more details, see:
Review: Approve
ora il branch dovrebbe essere quello giusto :)
--
https://code.launchpad.net/~coopenerp/openobject-italia/7.0-adding-intra-cee/+merge/210855
Your team OpenERP Italia core devs is subscribed to branch
lp:openobject-italia/7.0.
___
New question #245449 on OpenERP Italia:
https://answers.launchpad.net/openobject-italia/+question/245449
ciao a tutti,
A) ho visto oggi nel codice che nel modulo fiscalcode non sono state gestite:
omocodie, cioè nel caso che un codice fiscale sia uguale ad un altro L'Ag.
Entrate ha gestito
Review: Disapprove
Personalmente non sono a favore dello scrivere manualmente paid.
Una fattura dovrebbe risultare in tale stato perchè è openerp a deciderlo, dopo
aver verificato la riconciliazione completa.
Il deepcopy è pericoloso.
L'autofattura non dovrebbe essere intestata all'azienda
Question #245449 on OpenERP Italia changed:
https://answers.launchpad.net/openobject-italia/+question/245449
Davide Corio @ LS posted a new comment:
Per quanto riguarda il CF, a mio avviso il modulo andrebbe rifatto in vista
della 8.0.
Quindi c'è spazio per miglioramenti.
Per quanto riguarda i
Comprendo tutto ma ..
qual'è e dove si trova il tavolo dove di parla di queste cose?
Sino ad oggi non mi è chiaro, ho condiviso nel forum e ci sono queste
maillist gigantesche.
Immagino che questi siano i tavoli (separati perchè forum e mailist non
si prendo in considerazione a vicenda).
Il 13/03/2014 18:08, Davide Corio @ LS ha scritto:
Review: Disapprove
Personalmente non sono a favore dello scrivere manualmente paid.
Una fattura dovrebbe risultare in tale stato perchè è openerp a deciderlo,
dopo aver verificato la riconciliazione completa.
Ovviamente ogni tipo di
On 13 Mar 2014, at 18:50, Info SHS-AV i...@shs-av.com wrote:
Comprendo tutto ma ..
qual'è e dove si trova il tavolo dove di parla di queste cose?
qui, chat, forum, in pizzeria, in birreria, durante gli open days, ...
Tradotto: faccio le cose che mi interessano e non mi preoccupo della
Noi stiamo lavorando a questo aspetto anche in virtù dello spesometro.
Abbiamo già la tabella nazioni con i campi per lo spesometro e ho già i
dati catastali per le nazioni.
La politica di cambiamento dell'Agenzia delle Entrate non è così strana:
abbiamo riscontrano situazione analoga per i
Question #245449 on OpenERP Italia changed:
https://answers.launchpad.net/openobject-italia/+question/245449
Status: Open = Answered
Antonio M. - Zeroincombenze proposed the following answer:
Noi stiamo lavorando a questo aspetto anche in virtù dello spesometro.
Abbiamo già la tabella
On 13 Mar 2014, at 18:51, Francesco Apruzzese cesc...@gmail.com wrote:
Ovviamente ogni tipo di soluzione è ben accetta se possiamo migliorare
il codice. La decisione riguardo lo stato di pagamento è dovuta al fatto
che per far risultare una fattura pagata dovremmo registrare un
pagamento
Question #245449 on OpenERP Italia changed:
https://answers.launchpad.net/openobject-italia/+question/245449
Franco Tampieri posted a new comment:
Ciao Alessio,
per quello che mi riguarda il fiscalcode è specifico dell'Italia per cui
ogni miglioramento da apportare è bbuono, fra l'altro l'ultima
On 13 Mar 2014, at 19:12, Davide Corio @ LS davide.co...@lsweb.it wrote:
La fattura fornitore viene riconciliata dal pagamento al fornitore +
scrittura integrativa, siccome l'iva deve essere esplicitata sulla fattura
intra comunque.
o meglio... questo è quello che avevo in mente :)
--
Review: Abstain
--
https://code.launchpad.net/~coopenerp/openobject-italia/7.0-adding-intra-cee/+merge/210855
Your team OpenERP Italia core devs is subscribed to branch
lp:openobject-italia/7.0.
___
Mailing list:
Il 13/03/2014 19:12, Davide Corio @ LS ha scritto:
Temo il contrario.
La fattura fornitore viene riconciliata dal pagamento al fornitore +
scrittura integrativa, siccome l'iva deve essere esplicitata sulla fattura
intra comunque.
L'autofattura quindi rimarrebbe scoperta.
ma forse ho
On 13 Mar 2014, at 19:30, Francesco Apruzzese cesc...@gmail.com wrote:
Se hai una fattura fornitore ed una fattura intra e le paghi entrambe
umh... la fattura fornitore è la fattura intra :)
C'è pericolo. Ma vorrei sapere perchè. Anche per
conoscenza personale. Sai com'è
35 matches
Mail list logo
