Closed TheMule71 closed 2 weeks ago
eLBati
commented
2 years ago Non conviene prendere, per l'autofattura, il regime fiscale presente nell'XML della fattura originale, quando presente?
In ogni caso, io azienda che devo inviare autofattura non dovrei essere costretta a preoccuparmi del regime fiscale del mio fornitore
TheMule71
commented
2 years ago Non conviene prendere, per l'autofattura, il regime fiscale presente nell'XML della fattura originale, quando presente?
Se c'è l'XML, sì. Ma in caso di fornitori esteri di solito la fattura non arriva tramite SdI. Si risolverebbe solo il caso di reverse charge interno (dal 2022 credo che tutti i regimi fiscali abbiano l'obbligo di fatturazione elettronica). In ogni caso fatturapa_in potrebbe leggere il dato e metterlo nel partner.
Per i fornitori esteri, bisognerebbe informarsi se si usa convenzionalmente RF01, perché in tal caso potremmo già essere a buon punto: fornitore italiano, fattura dallo SdI, il dato viene caricato nel partner da fatturapa_in. Nel caso di fattura caricata a mano, il sistema dice all'utente di popolare il campo nel partner prima di confermare la fattura. Oppure decidiamo che se il campo non è popolato, mettiamo RF01 nell'XML (un po' come fa la PR della 14).
In ogni caso, io azienda che devo inviare autofattura non dovrei essere costretta a preoccuparmi del regime fiscale del mio fornitore
Posso essere anche d'accordo in linea teorica. Rimane il fatto che:
finché queste tre condizioni sono vere, io azienda sono obbligata a preoccuparmi nel senso che devo inviare dati veritieri allo SdI e qualcosa dentro a RegimeFiscale lo devo mettere.
Il punto della issue è che - prima della necessità di generare XML per le autofatture - i dati per popolare il Cedente/Prestatore dell'XML delle fatture out sono stati "attaccati" a res_company, dando per scontato che Cedente/Prestatore sarebbe stata sempre la company (esattamente come fa Odoo, per altro). Adesso, abbiamo la necessità di popolare quei dati (che però per la stragrande maggioranza non sono obbligatori - IscrizioneREARea, Contatti ecc.) partendo dal partner invece che dalla company (in condizioni normali, li prendi da company.partner_id). Alcuni campi sono già duplicati, per es. vat.
Possiamo anche decidere di lasciare le cose così, gestendo solo RegimeFiscale in modo specifico. Possiamo fare una funzione get_regime_fiscale_cp(invoice) che va a vedere la fattura originaria, i dati dell'XML, prende il regimefiscale, se c'è, altrimenti ritorna RF01.
In generale però mi piace di più l'idea di campi editabili dall'utente (magari popolati automaticamente) piuttosto che dati compiati senza che l'utente abbia modo di intervenire, ma in questo caso cambia poco.
stevech091
commented
2 years ago Suggerimento spostare il campo RegimeFiscale sul partner "Fornitore" che viene preso da XML.
Quando viene generata un xml da una autofattura e se il campo "regimeFiscale" è vuoto, appare un messaggio di errore
odooNextev
commented
7 months ago Ci siamo accorti dello stesso errore, nell'Autofattura il Regime Fiscale del fornitore non deve essere RF01 "Regime Ordinario" ma deve essere RF18 "Altro".
github-actions[bot]
commented
1 month ago There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days. If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.
In caso di trasmissione di autofattura allo SdI, vengono cambiati i dati del Cedente/Prestatore (settandoli a quelli della fattura originaria), ma il tag
RegimeFiscaleviene ancora valorizzato con il dato della company. Nel partner manca proprio il campo.Module
l10n_it_fatturapa_out_rc
Describe the bug
L'autofattura generata in caso di reverse charge è di tipo 'out' (fattura cliente). Per come funziona Odoo, il campo partner_id contiene i dati del cliente (Cessionario/Committente) per le fatture out, e - implicitamente - il Cedente/Prestatore è la nostra company. In questo caso, partner_id punta al partner della nostra company (in pratica i dati di C/P e C/C sono uguali).
Quando si trasmette la fattura allo SdI, come Cedente/Prestatore va indicato il fornitore orginario. Ciò non è rappresentabile al livello di modello Odoo, per cui dati vengono sovrascritti in fase di generazione dell'XML.
Tuttavia, tra i dati da inserire abbiamo
<RegimeFiscale>(RF01, RF02, ecc.). Tale dato è presente nella company ma non nel partner, per cui non è possibile recuperarlo dal fornitore della fattura originaria.Sulla 12.0, credo più per caso che per volontà, non viene sovrascritto, lasciando quello della company.
Sulla 14.0, @tafaRU ha notato il problema di fondo. Discutendone al momento sembra che tanto valga cablare 'RF01'. Non è chiaro quale sia l'impatto, se la cosa è passata finora inosservata sulla 12.
Probabilmente non ci sono molti casi di utenti con company diverse da RF01 e/o che ricevono fatture in reverse charge da fornitori diversi da RF01. Tra l'altro credo a senso che i fornitori non IT vadano indicati come RF01, e che i regimi fiscali "non ordinari" siano automaticamente piva italiane.
La casistica in cui la 12 potrebbe fallire è:
Per la 14, se manteniamo l'approccio attuale:
Difficile confrontarne l'impatto, e vista la rarità forse non conviene preoccuparsene. Per tutte le company con r.f. RF01, la stragrande maggioranza, il comportamento tra 12 e 14 è identico (entrambe impongono RF01 per tutti i fornitori nelle autofatture).
Un'azienda con r.f. diverso da RF01 avrebbe probabilmente più fortuna con la 14 (nella 12 imporebbe il proprio r.f. a tutti i fornitori).
L'unico caso in cui la 12 fa meglio è se una company con r.f. RF02 ricevesse una fattura in reverse charge da un'altra azienda in RF02 (in tal caso la 14 sbaglierebbe r.f. per il fornitore).
Stiamo comunque confrontando corner case di comportamenti fondamentalmente bacati.
L'approccio ideale per noi è:
Affected versions:
Vd.
https://github.com/OCA/l10n-italy/blob/55c2095320b743f0d36e58d2ac22acf2e4746679/l10n_it_fatturapa_out/data/invoice_it_template.xml#L326
https://github.com/OCA/l10n-italy/blob/81e2162499d6d66ddc0f53a462359082e3c5996d/l10n_it_fatturapa_out/wizard/wizard_export_fatturapa.py#L247