[14.0] fatturapa_in Autofatture per autoconsumo TD27

[francescapenso]

Mi sono accorta che quando si fanno autofatture per autoconsumo poi queste appaiono in fatture in ingresso come da registrare.
Essendo TD27:
"TD27 tale codice identifica le fatture (autofatture) emesse in relazione alle operazioni di autoconsumo o di cessione gratuita senza rivalsa IVA"
A mio avviso dovremmo "nasconderle" come si fa per TD17, TD18

• 12.0: [IMP] fatturapa_in Autofatture per autoconsumo TD27 #3340 (risolta per supporto terminato)
• 14.0: [14.0] [IMP] l10n_it_fatturapa_in: add TD27 TD28 #3162
• 16.0: [16.0] [MIG] l10n_it_fatturapa_in #3000

[TheMule71]

Per quanto riguarda la 12.0, nascondere le autofatture non dovrebbe essere più necessario a seguito di #2790 che è un approccio molto migliore.

Per la 16.0, #3000 già include la modifica.

[SirTakobi]

Giusto per capire la situazione:

• risolvere questa issue equivale a risolvere l10n_it_reverse_charge supporting "with_supplier_self_invoice" for e-invoices + link supplier self invoice to e-invoice #2869,
• per 12.0 questo problema è stato già risolto da [12.0] l10n_it_reverse_charge supporting "with_supplier_self_invoice" for e-invoices + link supplier self invoice to e-invoice #2790,
• per 14.0 c'era già [14.0] l10n_it_reverse_charge supporting "with_supplier_self_invoice" for e-invoices + link supplier self invoice to e-invoice  #3084 (porting dell'approccio migliore di [12.0] l10n_it_reverse_charge supporting "with_supplier_self_invoice" for e-invoices + link supplier self invoice to e-invoice #2790 a 14.0),
  però in 14.0 seguiamo un altro approccio che è stato implementato in [14.0] [IMP] l10n_it_fatturapa_in: add TD27 TD28 #3162
• 16.0 sarà allineata a 14.0

Quindi le due versioni saranno disallineate per quanto riguarda la gestione di questa problematica e vanno chiuse sia #3084 che #2869?
Oppure nella #3084 va aggiunto il revert di quanto è stato implementato in #3162?

[TheMule71]

No, per me sia nella 14.0 che nella 16.0 andrà mergiata/portata #3084. Nessuno ha parlato di chiudere #3084.

Quella di nascondere le autofattura era solo una pezza. #3162 non fa altro che aggiungere due codici a quello che c'è già, in attesa che l'approccio migliore venga mergiato.

[SirTakobi]

Quindi

nella #3084 va aggiunto il revert di quanto è stato implementato in #3162?

[TheMule71]

Quindi

nella #3084 va aggiunto il revert di quanto è stato implementato in #3162?

No, a che servirebbe? La #3162 riguarda solo TD27 e TD28. Si limita ad estendere la logica della #2553 comprendo altri due casi. Al limite sarebbe da fare il revert della #2553 (includendo la #3162 ovviamente). Tutta la logica di nascondere se is_self_invoice è True non dovrebbe più servire se gli attachment vengono auto linkati ad una fattura esistente... non apparirebbero comunque.

Tuttavia sulla 12 la #2790 non ha fatto il revert della #2666 (che è il backporting della #2553). Per cui la #3080 non deve necessariamente fare il revert della #2553+#3162. Sulla 16 il porting è partito con la #2553 mergiata per cui ha senso allienarla con la #3162.

Dopo il merge di #3000 per la 16 e #3080 (dopo aver ripulito i commit che non c'entrano) per la 14, avremo il codice allineato (salvo il fatto che per la 12 non esiste il back port di #3162, ma stiamo parlando di una riga di codice e in un path non usato).

Poi se decidiamo che ne vale la pena, possiamo pensare di fare il revert di #2666 sulla 12, di #2553+#3162 sulla 14 e la rimozione del codice corrispondente sulla 16 con una issue separata.

Riepilogo:

1. logica di nascondere le autofatture dalla lista di quelle da importare:
   12.0 : [12.0][FIX] l10n_it_fatturapa_in: show if a file contains self invoices #2666 (backporting da 14)
   14.0: [14.0][FIX] l10n_it_fatturapa_in: show if a file contains self invoices #2553 + [14.0] [IMP] l10n_it_fatturapa_in: add TD27 TD28 #3162
   16.0: [16.0] [MIG] l10n_it_fatturapa_in #3000 (da mergiare, include forward porting da 14 di 2553 e 3162)

2. logica di autolinkare gli XML a fatture esistenti:
   12.0: [12.0] l10n_it_reverse_charge supporting "with_supplier_self_invoice" for e-invoices + link supplier self invoice to e-invoice #2790
   14.0: [14.0] l10n_it_reverse_charge supporting "with_supplier_self_invoice" for e-invoices + link supplier self invoice to e-invoice  #3084
   16.0: da fare forward port

La 12.0 è l'unica ad avere entrambe le logiche attive (manca solo la parte TD27 TD28).
La 14.0 ha la logica 1) completa
La 16.0 nella PR attuale per l10n_it_fatturapa_in ha la logica 1) completa

Per me la #3084 dovrebbe allineare la 14.0 alla 12.0 implementando la logica 2). E va fatta analoga PR per la 16, una volta che #3000 viene mergiata.

Successivamente - se ne vale la pena - con una issue e 3 pr separate va rimosso il codice inutile da tutte e tre le versioni.

[SirTakobi]

Grazie mille per il riepilogone 😄
la logica 1) ha come riferimenti la issue #2552 e questa issue;
la logica 2) invece è la issue #2869.

Quindi le due problematiche sono equivalenti nel senso che vogliono risolvere lo stesso problema: non vogliono vedere le FE delle autofatture tra quelle da importare.
Sono però state implementate diverse soluzioni: la logica 1) e la logica 2).

In 12.0 la logica 1) è implementata ma zoppa (manca l'esclusione di TD27 e TD28), la lasciamo così perché essendoci la logica 2) già non servirebbe quello che c'è (implementato in #2666).

No, a che servirebbe?

Servirebbe a togliere del codice che non viene utilizzato, come secondo me sarebbe servito già in #2790; ma vista la situazione concordo che va bene farlo

Successivamente - se ne vale la pena - con una issue e 3 pr separate va rimosso il codice inutile da tutte e tre le versioni.

[TheMule71]

Corretto. Nella 12, è inutile aggiornare la logica 1) perché la logica 2) interviene prima.
Per 14.0 e 16.0 terrei per ora la logica 1) "aggiornata" (con TD27 e TD28), in attesa che la logica 2) venga portata. Quando le tre release sono allineate con entrambe le logiche, facciamo la issue di rimozione di logica 1).

[SirTakobi]

Nella 12, è inutile aggiornare la logica 1) perché la logica 2) interviene prima.

Il collegamento automatico della logica 2) si applica in https://github.com/OCA/l10n-italy/blob/ab9152607bd381a78ecc47276a3890146d9d171d/l10n_it_fatturapa_in_rc/models/attachment.py#LL23C25-L23C25, quindi la fattura elettronica deve essere riconosciuta come autofattura (is_self_invoice = True) perché la logica 2) intervenga.

Affinché le fatture elettroniche dei tipi TD27 e TD28 vengano riconosciute come autofatture, è necessario aggiungere i tipi a quelli elencati per le autofatture: l'ho implementato in #3340.

@TheMule71 quando puoi aggiungi la PR in descrizione e se ti va mi dici che ne pensi (qui o nella PR)?