[12.0][l10n_it_fatturapa_out] trasmissione degli importi in EUR per fatture in valuta estera

[TheMule71]

Ciao,

un cliente ci ha sottoposto la questione di trasmettere allo SdI fatture in valuta estera. Da quello che ho visto, gli importi nell'XML (in particolare imponibile e iva) vanno in euro, possibilmente indicando gli importi originali usando i campi aggiuntivi.

Faccio questa draft PR principalmente per poterne discutere avendo del codice davanti.

#2590

--
Confermo di aver firmato il CLA https://odoo-community.org/page/cla e di aver letto le linee guida su https://odoo-community.org/page/contributing

[eLBati]

Quindi il campo Divisa non può essere diverso da EUR?

[marco-marchiori]

Ricordo all'inizio del 2019 ci fu una lunga discussione e non so se mi sono perso qualcosa.
Per la normativa comunitaria sull'IVA la fattura può essere espressa in qualsiasi valuta, mentre l'iva va espressa nella moneta nazionale dello Stato.
Poi non so quali e quanti problemi tecnici o pratici ci siano o si siano frapposti.
Fatto sta che se io ho una contabilità in EUR e voglio/devo fare una fattura in USD devo poterlo fare per un elementare principio di libertà economica.
Mi pare che SDI accettasse, non ho fatto prove recenti, ma se non succedesse bisognerebbe prendersela con SDI invece di adeguarsi, se qualcuno ha esperienze recenti cortesemente aggiorni.

[TheMule71]

Allora, da quello che ho capito, il formato XML dello SdI prevede il campo valuta. Tuttavia, una norma del '72 (successivamente adeguata, immagino), prevede che imponibile e iva siano arrotondati al centesimo di euro, e la cosa viene interpretata dallo SdI come: vanno necessariamente espressi in euro. Nella risposta alla FAQ n.64 del 2019 la AdE ci dice che quei campi verranno comunque interpretati dallo SdI in euro.

https://www.agenziaentrate.gov.it/portale/documents/20143/287582/FAQ+pubblicate+il+19+luglio+2019+%28aggiornate+il+20+novembre%29.pdf

Suggeriscono due modi di indicare i valori originali in valuta estera, sovrascrivere il CodiceArticolo o usare AltriDatiGestionali. Io ho scelto la seconda, ma volevo raccogliere opinioni al riguardo.

[marco-marchiori]

Si, certo, è un'interpretazione dell'Agenzia della norma base IVA secondo il proprio comodo che contraddice nella sostanza la normativa comunitaria e le proprie specifiche.
Ma conferma la natura della fattura elettronica.
Ovviamente può avere senso "non avere problemi" e seguirla, ma il problema va a mio parere valutato approfonditamente, definendo i casi d'uso (qual è l'accordo contrattuale?) e descrivendo le conseguenze.

[dcorio]

@TheMule71
Sto testando la PR.
Per quanto riguarda la conversione in EUR, vedo che c'è "forse" qualche problema di arrotondamento.
Nel mio caso il totale in EUR su Odoo è 2 centesimi in meno di quello riportato nel XML.

Per il resto, il problema più strano che ho è questo errore riportato dal validatore dell'ade:

The value '145.0' of element 'RiferimentoNumero' is not valid. riga: 1 - colonna: 3070 - File non conforme al formato

A me sembra ok nel XML, dove vedo:
<RiferimentoNumero>145.0</RiferimentoNumero>

[TheMule71]

Strano, dovrebbe produrre 145.00

Edit: sono stato un po' conciso... intendo dire, il tipo (xsd) è lo stesso degli importi, per cui le cifre decimali sono da 2 a 8 e 145.0 è effettivamente non conforme. Tuttavia, PyXB dovrebbe produrre l'output corretto e non ho idea perché non lo faccia.

Ho letto anche la mail, il tag Divisa non va popolato con altro se non EUR. Ho letto le più varie interpretazioni, ma per me fa fede questa FAQ: https://www.agenziaentrate.gov.it/portale/documents/20143/287582/11+Tutte+le+faq+%28aggiornate+al+15+ottobre+2020%29.pdf/c90915b7-4ba6-d609-c395-176112fbf753
che dice:

Conseguentemente, se la fattura è emessa da soggetti residenti o stabiliti il codice da inserire nel campo
deve essere obbligatoriamente “EUR”.
Va da se che i valori da riportare nelle singole righe dei e, in particolare, nei campi 2.2.2.5
e 2.2.2.6 devono essere coerenti con la divisa indicata (nel caso di fattura
nazionali, abbiamo detto euro).

In pratica il formato consente divise diverse ma se sei residente in italia (o avente sede stabile) devi indicare l'IVA in euro e siccome la valuta degli importi IVA dipende da , questa deve essere EUR.

Di qui l'opportunità di indicare l'importo originale in dollari in campi opzionali.

Da notare che la stessa FAQ si contraddice:

Infine, è anche possibile valorizzare il campo “Divisa” con una valuta diversa da Euro ma, per rispettare il dettato
normativo dell’art. 21 del d.P.R. n. 633/72:
 l’operatore dovrà specificare in fattura (anche nei campi descrittivi) che gli importi dell’imponibile e dell’IVA
delle singole righe e dei dati di riepilogo sono in Euro e solo l’importo totale della fattura (che il SdI non
controlla) si intenderà in valuta estera.
 gli importi delle singole righe dei e, in particolare, dei campi 2.2.2.5
e 2.2.2.6 saranno considerati dall’Agenzia delle Entrate in Euro;

Quindi in pratica puoi mettere USD ma gli importi imponibile e iva delle righe e dei riepiloghi vanno tutti in EUR comunque (e devi scriverlo nella descrizione). Rimane solo il totale in USD, non so quanto senso abbia a questo punto non mettere pure il totale in EUR e indicare EUR.

[parsifino]

ciao, ho guardato il tuo codice. A mio avviso, ci sono due problemi:

• devi convertire col tasso di cambio alla data della fattura, non con la data di oggi
• gli importi in EUR nella fattura elettronica devono corrispondere a quelli del libro giornale, convertiti in EUR al momento della registrazione, altrimenti la tua IVA non corrisponderà a quella calcolata dall'AdE
• non puoi arrotondare a 2 decimali altrimenti la somma non torna. Nellla versioone 1.6 della fattura elettronica hanno aumentato il numero di decimali per questa ragione.

è possibile modificare la funzione to_eur per prendere il tasso di cambio alla data corretta e mantenere più decimali?

[TheMule71]

ciao, ho guardato il tuo codice. A mio avviso, ci sono due problemi:

• devi convertire col tasso di cambio alla data della fattura, non con la data di oggi
• gli importi in EUR nella fattura elettronica devono corrispondere a quelli del libro giornale, convertiti in EUR al momento della registrazione, altrimenti la tua IVA non corrisponderà a quella calcolata dall'AdE

Corretto, o quanto meno ha senso... ciò che conta dovrebbe essere la data di registrazione della fattura.

• non puoi arrotondare a 2 decimali altrimenti la somma non torna. Nellla versioone 1.6 della fattura elettronica hanno aumentato il numero di decimali per questa ragione.

Io non arrotondo a due decimali... il codice precedente già arrotondava a 2 decimali in alcuni punti, ad es. TheMule71@95973e7#diff-914565354eea6151b103fe044fbc59e9406e4df75dd4143da361a2873a4c246eL723
io non ho modificato il comportamento. Se quel comportamento va modificato, non è questa la PR per discuterne, ne va fatta una a parte (e poi a limite faccio il rebase su quella). Converrebbe aprire una issue con un caso d'uso che manifesti il problema degli arrotondamenti.

è possibile modificare la funzione to_eur per prendere il tasso di cambio alla data corretta e mantenere più decimali?

La _to_EUR() non arrotonda, a meno che non lo faccia da solo il metodo _convert() della currency. Sicuramente la si può chiamare col paramentro today=invoice.date per cambiare la data della conversione.

[francescapenso]

Adesso che diverrà obbligatorio trasmettere elettronicamente anche le fatture emesse verso l'estero potrebbe essere importante riprendere in mano la discussione?

[francescapenso]

Pare che cmq l'agenzia voglia i valori obbligatoriamente in euro e permetta eventualmente di mettere un controvalore in dollari.
L'opportunità potrebbe essere quella di emettere e registrare fattura in euro e creare solo la copia cortesia (pdf) per il cliente estero in valuta diversa. Forse potrebbe essere la cosa più aderente alla normativa

[OpenCode]

Pare che cmq l'agenzia voglia i valori obbligatoriamente in euro e permetta eventualmente di mettere un controvalore in dollari. L'opportunità potrebbe essere quella di emettere e registrare fattura in euro e creare solo la copia cortesia (pdf) per il cliente estero in valuta diversa. Forse potrebbe essere la cosa più aderente alla normativa

Non cambierei il comportamento del flusso di un'azienda per adattarsi a una richiesta della nostra agenzia delle entrare ma lavorerei sul formato del file. L'azienda deve essere libera di registrare le fatture in una valuta che segue una logica consona ai propri standard. Le registrazioni dovrebbero comunque avere il campo in cui viene congelato il valore in valuta convertita.

[francescapenso]

Pare che cmq l'agenzia voglia i valori obbligatoriamente in euro e permetta eventualmente di mettere un controvalore in dollari. L'opportunità potrebbe essere quella di emettere e registrare fattura in euro e creare solo la copia cortesia (pdf) per il cliente estero in valuta diversa. Forse potrebbe essere la cosa più aderente alla normativa

Non cambierei il comportamento del flusso di un'azienda per adattarsi a una richiesta della nostra agenzia delle entrare ma lavorerei sul formato del file. L'azienda deve essere libera di registrare le fatture in una valuta che segue una logica consona ai propri standard. Le registrazioni dovrebbero comunque avere il campo in cui viene congelato il valore in valuta convertita.

Si mi sono spiegata male io. L'azienda deve continuare a lavorare come è abituata a fare e poter poi fornire la fattura nella valuta in cui viene pagata alla controparte anche sulla base della negoziazione commerciale. Bisogna però che nell'xml venga messo il valore in euro e il controvalore in valuta. Io userei i cambi standard per i valori in euro e i campi "Altri dati gestionali" per i valori in divisa estera.Necessario però che il tasso di conversione sia quello del giorno di emissione della fattura

Al di là dell'obbligatorietà che pare scattare al 1/7/2022 è già possibile inviare fatture verso l'estero allo sdi attualmente quindi credo che sia da adeguare ASAP

[francescapenso]

qui il doc giusto agenzia entrate con dettagli
https://www.agenziaentrate.gov.it/portale/documents/20143/0/10FAQ+pubblicate+il+19+luglio+2019+%28aggiornate+il+1+luglio+2021%29.pdf/6e8acb34-b7c5-730e-6a39-79c0a296e02b
aggiornato al 1 luglio 2021 e tuttora valido
FAQ 63 e 64

[TheMule71]

Nota: ho portato avanti #2563, che ha anche un test. Idealmente questa andrebbe allineata.

[TheMule71]

Altra nota: riporto anche qui che probabilmente
https://github.com/OCA/l10n-italy/blob/12.0/l10n_it_fatturapa_out/tests/data/IT06363391001_00009.xml
non è corretto in base alle indicazioni attuali. Nella #2563 ho proprio eliminato il test.

[matteoopenf]

ho aperto sulla scia di questa pr, una pr migliorativa
Ed è questa: #2684
La differenza è che si tiene conto della data della fattura per calcolare la conversione e non today, perchè altrimenti si generano degli ammanchi essendo che i tassi di cambio cambiano giornalmente

[eLBati]

@TheMule71 questa è pronta o ci sarebbero altre cose da fare?

[TheMule71]

@TheMule71 questa è pronta o ci sarebbero altre cose da fare?

Per me è pronta.

[eLBati]

Grazie

[OCA-git-bot]

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

[matteoopenf]

ho testato funzionalmente e funziona

[eLBati]

/ocabot merge patch

[OCA-git-bot]

On my way to merge this fine PR!
Prepared branch 12.0-ocabot-merge-pr-2042-by-eLBati-bump-patch, awaiting test results.

[OCA-git-bot]

Congratulations, your PR was merged at ad8f575. Thanks a lot for contributing to OCA. ❤️