ARGOMENTO: [8.0] comunicazione clienti e fornitori (Spesometro 2017)

Segnalazioni per gli utenti:

Verrà rilasciata a breve una nuova versione con le segnalazioni degli utenti. In attesa Vi prego di leggere qui

##### Nome file non corretto #####
Provvisoriamente dovete modificare il nome dell'allegato inserendo l'estensione .xml e gli underscore prima e dopo il testo DF
Correzione in arrivo tra breve



##### In alcuni casi il flag individual non corrisponde alla presenza di un codice fiscale italiano. #####
Verificare che:
** Se presente con codice fiscale di una persona fisica (16 caratteri, lettere e numeri) il flag individual DEVE essere attivo
** Se codice fiscale non presente o insertita partita IVA il flag individual NON DEVE essere attivo
Il flag è impostato automaticamente ma non so per quale motivo sono stati rilevati casi di anomalia.

Errore nel log:
- Campo nome > 60 caratteri



#### Le fatture fornitori intraUE generano errore ####
Il problema è dovuto all'algoritmo che copia il codice fiscale dalla parita IVA. La copia deve avvenire solo per i fornitori italiani.
Correzione in arrivo tra breve

-- Scarto con errore 200


##### Problemi di visualizzazione in alcuni casi #####
Correzione in arrivo tra breve

gigidn ha scritto:
Gigidn,
probabilmente l'errore nome>60 caratteri è dovuto alla separazione cognome e nome delle persone fisiche.
Ti consiglio di effettuare il porting del modulo github.com/Odoo-Italia-Associazione/l10n...0/l10n_it_fiscalcode che ti sarebber di grande aiuto.

Il CAP è in effetti un errore dello schema. Tra l'altro lo schema scaricato dalla pagina dell'Agenzia delle Entrate non accetta partite IVA (senza il prefisso nazione) più corte di 9 caratteri. Vanno in errore le partite IVA di Spagna e Irlanda.
Io ho corretto lo schema e per fortuna l'Agenzia delle Entrate ha accettato questi valori.

Tutto questo per invitarti a sviluppare insieme all'Associazione. Con lo Spesometro abbiamo sperimentato con successo una bella collaborazione. Tu potresti gestire tutto il porting verso la 10.0. Gli utenti sarebbero felici.

Antoniov ha scritto:
Sfortunatamente no, anche perchè nel mio caso non gestisco clienti che fanno vendite a privati. La denominazione era qualcosa del tipo "picopallo s.r.l. eredi di mario rossi della bla bla bla" ... ora di preciso non ricordo ma cosi' era riportato in fattura e la denominazione andava oltre i 60 caratteri consentiti. Purtroppo in questo, come in mille altri casi simili, poco puo' fare il software e bisogna procedere ad una bonifica manuale del dato. Chi ha creato la specifica dello spesometro nella migliore delle ipotesi fa altro di mestiere e non ha mai visto una fattura in vita sua da qui tutte le problematiche riscontrate in questi giorni.

E' assurdo prevedere un campo obbligatorio e poi consentire di valorizzarlo con "DATO ASSENTE", era meglio non metterlo obbligatorio, cosi' come dover specificare natura N1 per le fatture omaggio solo perchè il controllo in presenza di IVA a zero si aspetta una "natura", quella operazione non sta in natura N1 ma per far passare il file (non i controlli sullo schema perchè quelli vanno) è l'unico modo o si otterrebbe uno scarto (strada suggerita dal call center dell'agenzia nei rari casi che siam riusciti a parlarci).

Per quando riguarda il CAP, essendo esso un dato non obbligatorio in talune circostanze, controllo che sia composto da sole cifre e se non lo è evito di esportarlo ... questo risolve buona parte dei problemi sul cap appunto.

Ma devo ripetermi, il problema non è nello specifico caso ma nel suo insieme, La realizzazione dello scema è stata fatta a "cazzo di cane" (perdonate il francesismo) e la sua implementazione ancora peggio. hanno messo una serie di controlli restrittivi che non hanno tenuto conto degli innumerevoli casi particolari e pertanto lo schema è risultato fallace. La parte tragicomica è che l'adeguamento è ricaduto sui contribuenti (chiamati a modificare la loro base dati per adeguarla alle stravaganze richieste) e sui produttori di software che hanno dovuto implementare patch specifiche per evitare lo stallo. Un grosso danno economico solo perchè in sogei non sanno lavorare.

Nel mio piccolo posso dirti che abbiamo 1 ed in alcuni casi 2 risorse impiegate a tempo pieno negli ultimi 15gg per risolvere insieme ai clienti tutti i problemi causati da dati incompatibili con il tracciato, uno sforzo umano ed economico che nessuno ripagherà a parte la stima e la fiducia del cliente che non è stato abbandonato alla deriva in questa bolgia.

Analoghe problematiche, se non peggio visto il numero di clienti, le stanno sperimentando i commercialisti. La proroga è un palliativo, servono interventi strutturali che non ricadano sulle spalle di contribuenti/operatori del settore ... se fossi io il ministro avrei preso l'unica decisione possibile, annullare lo spesometro far piazza pulita in sogei e solo successivamente ripristinare il tutto perchè era ed è l'unica soluzione possibile in presenza di tanta incompetenza. Ma siamo in Italia e le poltrone sulle aziende di stato non saltano mai pertanto di dovremmo adeguare

Per quando riguarda la possibilità di collaborare io sono sempre disponibile e a chi in questi giorni mi ha chiesto un consiglio e/o un aiuto l'ho sempre dato (senza nulla a pretendere a scanso di equivoci) ma la mia posizione sulla fiscalità resta quella espressa in altro post e la recente esperienza con lo spesometro piu' che farmi cambiare idea ha maggiormente confermato tale linea. Lo sforzo necessario a sviluppare e rilasciare componenti fiscali nei modi e nei tempi imposti dai balzelli italiani va finanziariamente sostenuto.

Cio' non di meno ad oggi abbiamo, che io sappia, almeno 3 versioni distinte dello spesometro realizzate tutte da zero il che vuol dire aver impiegato 3 volte le risorse necessarie a realizzarlo ... uno spreco inutile di risorse. Ad esempio solo troppo tardi mi so reso conto che abbiam fatto un lavoro simile, riunire in singolo modulo tutti i bind pyxb per superare gli accavallamenti degli schemi.

Son ormai diversi anni che lo ripeto, ma le mie parole si disperdono al vento, se vogliamo avere una fiscalità decente su odoo a costi contenuti serve una NO PROFIT che si occupi esclusivamente di questo aspetto ma questa no profit va in qualche modo finanziata e le persone che vi lavorano retribuite un po' come avviene per apache group per citare un nome famoso o per la "eclipse".

Questo forum ha migliaia di iscritti, è un riferimento per odoo in italia eppure a fronte della ridicola cifra richiesta per associarsi (10 euro annui lo ricordo) gli iscritti all'associazione son poche decine. In altre parole si prende dal lavoro altrui ma non si è disposti a scucire neanche un centesimo ... forse è arrivato il momento di riflettere seriamente su questo punto.

gigidn ha scritto: [...]
Per quando riguarda la possibilità di collaborare io sono sempre disponibile e a chi in questi giorni mi ha chiesto un consiglio e/o un aiuto l'ho sempre dato (senza nulla a pretendere a scanso di equivoci) ma la mia posizione sulla fiscalità resta quella espressa in altro post e la recente esperienza con lo spesometro piu' che farmi cambiare idea ha maggiormente confermato tale linea. Lo sforzo necessario a sviluppare e rilasciare componenti fiscali nei modi e nei tempi imposti dai balzelli italiani va finanziariamente sostenuto.

Cio' non di meno ad oggi abbiamo, che io sappia, almeno 3 versioni distinte dello spesometro realizzate tutte da zero il che vuol dire aver impiegato 3 volte le risorse necessarie a realizzarlo ... uno spreco inutile di risorse. Ad esempio solo troppo tardi mi so reso conto che abbiam fatto un lavoro simile, riunire in singolo modulo tutti i bind pyxb per superare gli accavallamenti degli schemi.
[/quote]

Questo è il punto più importante sul quale invito te e gli sviluppatori del Network ad un tavolo comune.
Perché oltre ad avere lavorato in 3 gruppi sullo stesso problema abbiamo 3 diverse versioni molto probabilmente incompatibili.

E questo vale per Spesometro e Liquidazione IVA, cioè obblighi fiscali che diventeranno mensili. Su questa strada anche la nuova fattura elettronica darà origine a 3 diverse versioni.

Il problema reale non è SOGEI o l'Agenzia delle Entrate ma lo sviluppo con Odoo Proprietary License e conseguente la necessità di non pubblicare codice e le relative notizie. Avevo parlato con ElBati di questo potenziale problema ma i tempi non erano (ancora) maturi per una collaborazione con il Network.

Temo che la proposta di merge del codice sviluppato per la 6.1, 7.0 e 8.0 inerenti liquidazione IVA, Spesometro e fatturazionePA (che è semplicemente un aggiornamento allo standard 1.2 sulla 7.0) non potrà che essere bocciata, perché i membri italiani di OCA non potranno accettare un software incompatibile con quello a pagamento prodotto dalle loro stesse aziende del Network.

L'unico risultato che si otterrà con questa politica è la valorizzazione della repository dell'Associazione e anche se questo, da una parte mi fa piacere, non mi sembra una bella soluzione.

Vedremo cosa succederà nel futuro prossimo quasi immediato.

Salve,
la nuova versione con gli ultimi bug è stata pubblicata sulla repository dell'Associazione github.com/Odoo-Italia-Associazione/l10n-italy/ che trovate anche in alto sotto il menù “Wiki e Repository”

La documentazione sull'utilizzo la torvate qui wiki.zeroincombenze.org/it/Odoo/7.0/man/FI/spesometro2017

Oggi non sono giunte altre segnalazioni e ritengo questa versione stabile e utilizzabile dagli utenti finali e ho aggiunto la certificazione “fatturapa” nel README.

Naturalmente resto a disposizioni per eventuali segnalazioni ricordandovi che sinora la consegna del software da parte di Odoo Italia Associazione è sempre avvenuta prima dell'ultima scadenza fiscale e con un elevato livello di qualità del prodotto.

Salve,
abbiamo emesso fatture con codica IVA 00v (Fuori campo IVA) e queste fatture non vengono inserite dal programma nella communicazione fatture emesse.
Quale tabella devo aggiornare per includere anche queste fatture?
Grazie,
Zsolt