l10n_it_fatturapa_out: errore in caso di cliente EU privo di PIVA e CF

[TheMule71]

Vd. https://discord.com/channels/753902328494424064/753902328494424070/933097276111470682

Il template XML di generazione della f.e. non copre correttamente la casistica di cliente estero privo di PIVA e CF, producendo un XML non corretto per lo SdI (a livello formale di XML Schema entrambi i campi sono opzionali, ma a livello di controlli SdI almeno uno deve essere valorizzato).

Module

l10n_it_fatturapa_out

Affected versions:

• [ ] 12.0 ? da verificare
• [ ] 14.0 #2602

Per la 14.0 il codice è: https://github.com/OCA/l10n-italy/blob/66613b837e374686a32aa231e50221ef98919e8e/l10n_it_fatturapa_out/data/invoice_it_template.xml#L422-L438

[TheMule71]

Vd. https://discord.com/channels/753902328494424064/753902328494424070/933674413604352021

TL;DR:

[in IdCodice] metterei sempre partner_id.commercial_partner_id.vat se valorizzato e 99999999999 se vuoto, a livello di template (fatto salvo che sia siamo in_eu(), va fatto lo split del codice nazione e del numero). Prima, al momento dei controlli preventivi, verifichiamo se imponiamo le obbligatorietà del caso (oppure no se i controlli in res_partner sono completi). Per es. se in_eu(), il valore del campo vat deve essere splittabile con get_vat_country() e get_vat_number(), per quelli non EU il valore è libero (ma max 28 caratteri).

[MarcoCalcagni]

Ciao , spero di non dire cazzate, da un esperienza recente di fattura a marocco abbiamo dovuto scrivere IdPaese>MA< e IdCodice>OO99999999999< e la fattura è passata liscia. per risolvere di fretta in piva della form abbiamo messo "MA OO99999999999"

quindi si potrebbe provare per i clienti esteri privati cee ad aggiungere codice paese e poi OO99999999999 . Marco

[eLBati]

Non ho capito, pensi ci sia qualcosa di sbagliato qui https://github.com/OCA/l10n-italy/blob/66613b837e374686a32aa231e50221ef98919e8e/l10n_it_fatturapa_out/tests/data/IT06363391001_00009.xml#L42-L45 ?

[primes2h]

Anche noi recentemente abbiamo avuto un caso di cliente estero privato francese, v.12.0.

Lasciando vuoti i campi CF e P.IVA, alla creazione dell'xml è stata generata in automatico la partita iva FR99999999999. L'XML ha passato senza problemi i controlli dell'SDI.

[TheMule71]

Credo di aver visto OO99999999999 in vecchie versioni delle FAQ. In ogni caso, attualmente viene scritto:

nel campo 1.4.1.1.2 “IdCodice” un valore alfanumerico identificativo della controparte (fino ad un massimo di 28 caratteri alfanumerici su cui il SdI non effettua controlli di validità)

quindi sembra che accetti qualsiasi cosa, basta che si sia qualcosa.

[marco-marchiori]

Come ripeto gli interventi andrebbero sempre premessi da una chiara descrizione dei casi d'uso. 1.Sappiamo che il sistema accetta in generale codice fiscale e/o partita IVA (alternativa non esclusiva) (IdFiscaleIVA) 2. Questa regola non vale nel caso di committenti esteri per i quali (aziende o non aziende) va valorizzato l'elemento IdFiscaleIVA, ma il sistema si limita a fare un controllo sull'ID paese accettando poi un idcodice di fantasia (nelle specifiche tecniche non si parla di 99999999999 ma di un codice generico, quindi dovrebbe essere (correggetemi)

--cessionariocommittente IT-- azienda: partita IVA o codice fiscale non azienda: codice fiscale

--cessionariocommittente EX-- aziendaeuropa: partita iva europea in IdFiscaleIVA nonazienda europa: IdFiscaleIVA con IdPaese valorizzato e IdCodice fittizio azienda e nonazienda extraeuropa: IdFiscaleIVA con IdPaese valorizzato e IdCodice fittizio (la fattura dovrebbe passare anche nel primo caso con PI fittizia ma evidentemente crea ulteriori problemi di identificazione ed anagrafica)

Corollario: mai valorizzare un codice fiscale di un cessionario estero

Quindi:

1. potete confermarmi questo dalla vostra esperienza?
2. cosa dovrebbe fare quindi il codice?

[eLBati]

Non ho capito, pensi ci sia qualcosa di sbagliato qui

No, il caso è cliente "in EU" ma senza P.IVA

[TheMule71]

Siccome mi piacciono le cose semplici (se possibile), al momento la #2602 in sostanza fa:

            if partner.vat:
                id_paese = partner.vat[:2].upper()
                id_codice = partner.vat[2:]
            else:
                id_paese = partner.country_id.code
                id_codice = "99999999999"

Molto banalmente, se il partner ha l'IVA impostata, la splitta (come faceva prima) in paese e numero. Altrimenti va a prendere il codice della country e mette 99999999999 in IdCodice che lo SdI ignora. Notare che l'XML è fatto per es. così:

            <DatiAnagrafici>
                <IdFiscaleIVA>
                    <IdPaese>IT</IdPaese>
                    <IdCodice>07973780013</IdCodice>
                </IdFiscaleIVA>
                <CodiceFiscale>07973780013</CodiceFiscale>
                <Anagrafica>
                    <Denominazione>B2B Customer</Denominazione>
                </Anagrafica>
            </DatiAnagrafici>

Ossia la gestione del campo fiscalcode e l'elemento <CodiceFiscale> sono separate rispetto a quello che stiamo discutendo qui (e al momento è questa):

                   <CodiceFiscale
                        t-if="partner_id.commercial_partner_id.fiscalcode"
                        t-esc="partner_id.commercial_partner_id.fiscalcode"
                    />

ossia viene messo se nel partner è popolato.

Nella casistica riportata, cliente EU (ad es. francese) no VAT, ma con CF impostato, verrebbe:

                <IdFiscaleIVA>
                    <IdPaese>FR</IdPaese>
                    <IdCodice>99999999999</IdCodice>
                </IdFiscaleIVA>
                <CodiceFiscale>07973780013</CodiceFiscale>

no VAT e no CF, sarebbe:

                 <IdFiscaleIVA>
                    <IdPaese>FR</IdPaese>
                    <IdCodice>99999999999</IdCodice>
                </IdFiscaleIVA>

E a parte CN al posto di FR, sarebbe la stessa indentica cosa per un cliente non EU, ad es cinese.

Al momento, non mi sembra il caso di ragionare troppo su come popolare un elemento (IdCodice) in una condizione in cui lo SdI dice di non fare alcun controllo sul valore.

[primes2h]

Siccome mi piacciono le cose semplici (se possibile), al momento la #2602 in sostanza fa:

Nella casistica riportata, cliente EU (ad es. francese) no VAT, ma con CF impostato, verrebbe:

                <IdFiscaleIVA>
                    <IdPaese>FR</IdPaese>
                    <IdCodice>99999999999</IdCodice>
                </IdFiscaleIVA>
                <CodiceFiscale>07973780013</CodiceFiscale>

Questa soluzione coprirebbe un caso d'uso che nella v.12.0 non viene attualmente gestito, cioè di cliente privato estero con codice fiscale italiano.

Nella situazione che avevo riportato qui il primo tentativo di invio non era andato a buon fine (errore SDI) perché, con il campo codice fiscale valorizzato, nell'xml non compariva FR99999999999.

[marco-marchiori]

Al momento, non mi sembra il caso di ragionare troppo su come popolare un elemento (IdCodice) in una condizione in cui lo SdI dice di non fare alcun controllo sul valore.

Bene ma (non vedendo com'è attualmente il codice) non vedo quale sia il problema adesso, a parte la perplessità sulle specifiche (su cui non possiamo influire).

Se sono un'azienda che vende b2c e b2b all'estero e

• non metto il codice fiscale
• valorizzo la partita iva correttamente quando esistente -- e con IdPaese corretto + 12345678910 quando non esistente

dovrebbe passarmela sempre, no?

Che automatismi dobbiamo creare?

Certo è fastidioso non mettere un identificativo nel codice fiscale dove esistente, vabbè.

[TheMule71]

non vedo quale sia il problema adesso

Cliente no VAT in europa, senza codice fiscale. In questo caso, nella 14, non viene generata la stanza <IdFiscaleIVA>. Se non erro, in caso manchi anche il <CodiceFiscale>, lo SdI si adombra.

[luigimassa]

Salve a tutti. Ho letto il tread e propongo questo caso reale in cui il modulo di esportazione si blocca

Fornitore Digital Ocean. Dati fiscali:

DigitalOcean LLC
101 Avenue of the Americas, 10th Floor
New York, NY 10013
VAT ID: EU528002224

E' un fornitore extra ue per cui per evitare l'esterometro si può emettere autofattura in rc via sdi (sarà obbligatorio da luglio) Ma il fornitore ha la partita iva EU528002224 dove EU è un assegnazione che è data alle società extra-ue da una nazione UE per permettere di vendere in UE.

Questo il controllo che è eseguito

                if partner.vat[0:2] not in self.env['res.country'].search([]).\
                        mapped('code'):
                    raise ValueError(_(
                        "Country code does not exist or it is not mapped in countries: "
                        "%s" % partner.vat[0:2]
                    ))

In pratica cerca fra le nazioni anche il paese UE. Per ovviare si potrebbe creare un nuovo country, generico, UE oppure si può modificare il codice. Spero di non aver sbagliato thread. Grazie

[marco-marchiori]

salvo novità o aggiornamenti mi sembra il solito caso per cui le specifiche ministeriali per un fornitore estero richiedono la codifica ISO del Paese (US dovrebbe essere) ed un codice numerico farlocco,e quindi non accetteranno una codifica diversa

[TheMule71]

Allora, ho indagato un po' e mi sembra che nel codice diamo troppo per scontato che i primi due caratteri rappresentino il paese.

A latere, ho aperto questa: https://github.com/odoo/odoo/issues/84545

Tuttavia, oggi ho notato anche:

Allora, il problema greco nasce dal fatto che l'EU non usa ISO 3166-1, ma ISO 639-1. (A.Tanenbaum: "The nice thing about standards is that you have so many to choose from; furthermore, if you do not like any of them, you can just wait for next year's model."). Sono quasi identici, ma da una parte la Grecia è GR, dall'altra EL.

Nella sua infinita saggezza, lo SdI ha deciso che non siamo in EU, e quindi usiamo ISO 3166-1, del resto Odoo fa lo stesso nella tabella delle country. Di contro l'Europa ha deciso che le PIVA greche iniziano per EL.

Ora, in presenza di un partner greco, con piva EL123456789 ritengo che la cosa migliore sia quella di generare:

                <IdFiscaleIVA>
                    <IdPaese>GR</IdPaese>
                    <IdCodice>EL123456789</IdCodice>
                </IdFiscaleIVA>

Ossia, strippare IT davanti alle piva italiane e basta. Il resto si ignora come è fatta la piva (che diventa un codice "opaco"), si mette il country code dall'anagrafica del partner come da tabelle Odoo (che dovrebbe essere lo stesso che si aspetta lo SdI, ISO 3166-1, almeno ciò è quanto dichiara, ossia 'GR' per la Grecia), e si copia la piva as is in <IdCodice>

[TheMule71]

Salve a tutti. Ho letto il tread e propongo questo caso reale in cui il modulo di esportazione si blocca

Fornitore Digital Ocean. Dati fiscali:

DigitalOcean LLC
101 Avenue of the Americas, 10th Floor
New York, NY 10013
VAT ID: EU528002224

E' un fornitore extra ue per cui per evitare l'esterometro si può emettere autofattura in rc via sdi (sarà obbligatorio da luglio) Ma il fornitore ha la partita iva EU528002224 dove EU è un assegnazione che è data alle società extra-ue da una nazione UE per permettere di vendere in UE.

Questo il controllo che è eseguito

                if partner.vat[0:2] not in self.env['res.country'].search([]).\
                        mapped('code'):
                    raise ValueError(_(
                        "Country code does not exist or it is not mapped in countries: "
                        "%s" % partner.vat[0:2]
                    ))

In pratica cerca fra le nazioni anche il paese UE. Per ovviare si potrebbe creare un nuovo country, generico, UE oppure si può modificare il codice. Spero di non aver sbagliato thread. Grazie

Ciao, ci sono stati aggiornamenti sulla PR per la 14. Nel caso il tuo problema fosse sulla 14.0, potresti vedere se la #2602 effettivamente risolve la tua casistica.