Gestione dipendenze l10n_it_fatturapa_in

[SimoRubi]

Versioni coinvolte

• [x] 12.0 (risolta per supporto terminato)
• [ ] 14.0 https://github.com/OCA/l10n-italy/pull/2410

Il modulo l10n_it_fatturapa_in deve poter importare qualsiasi fattura perché non si ha il controllo sulle fatture ricevute, ma non deve dipendere dai moduli dedicati alle specifiche funzionalità.

Ad esempio: attualmente l10n_it_fatturapa_in dipende da l10n_it_withholding_tax_causali per poter importare fatture con ritenute, ma sarebbe corretto poter fare a meno del modulo (perché ad esempio non c'è gestione delle ritenute nell'azienda).

Una soluzione è rimuovere la dipendenza e sollevare dei warning/inconsistenze non bloccanti nella fattura importata; tornando all'esempio il messaggio sarebbe qualcosa tipo:

La fattura XXX contiene ritenute, per poterle gestire installare l10n_it_withholding_tax_causali

Il modulo l10n_it_fatturapa_in farà comunque il possibile: per alcune funzionalità è sufficiente creare registrazioni contabili.

Nota: il discorso è diverso per l10n_it_fatturapa_out che giustamente utilizza dei moduli ponte per aggiungere alla fattura elettronica generata le parti derivanti dalle singole funzionalità.

[TheMule71]

In quale modo suggerisci che l10n_it_fatturapa_in si accorga della presenza o meno degli altri moduli, per es. l10n_it_withholding_tax_reason? Il modulo in questione non può fare l'override di un metodo in un modello di l10n_it_fatturapa_in senza creare la dipendenza inversa. Ci sono modi ovviamente per testare per la presenza di un modulo o di un campo, sia via introspection che query su db, ma non so se si tratta di best practice.

Inoltre nella 14.0 tra "creare registrazioni contabili" e "avere il supporto per le ritenute in fattura" è sostanziamente la stessa cosa.

In realtà su discord abbiamo affrontato più volta l'argomento ritenute e registrazioni contabili. Attualmente il modulo ritenute adotta ancora uno stile molto "12", con tabelle di supporto associate alle fatture via relazioni (ftpa_withholding_ids) mentre lo stile "14" è quello di rendere poliedriche le account_move_line, senza tabelle extra, almeno dove possibile.

In ogni caso per sulle ritenute non ne so abbastanza per immaginare tutte le implicazioni di creare le giuste registrazioni contabili senza passare per 2.1.1.5.4 DatiRitenuta.CausalePagamento visto che quella è la chiave per cercare la ritenuta stessa, al momento.

[SimoRubi]

In quale modo suggerisci che l10n_it_fatturapa_in si accorga della presenza o meno degli altri moduli, per es. l10n_it_withholding_tax_reason?

Controllerei se il modulo è installato, faccio prima a scrivere un PoC che a spiegarmi :) vedi https://github.com/OCA/l10n-italy/pull/2410.

C'è anche da pensare a come gestire i test che attualmente falliscono perché provano a fare una ritenuta, probabilmente una parte di logica (e i test) sarebbe da delegare a un modulo che si autoinstalla quando ci sono fatturapa_in e withholding_taxes.

Non ho ancora pensato a fondo al tutto, per ora ho solo creato la issue per segnalare che sarebbe da fare.

[eLBati]

Però con https://github.com/OCA/l10n-italy/pull/2410 cosa risolvi? Che finchè non ricevi una fattura con ritenuta vai avanti senza errori, ma poi se la ricevi devi comunque installare l10n_it_withholding_tax_reason? Non vedo vantaggi, se non per quelle poche, ammesso che esistano, azienda che non ricevono mai fattura con ritenuta.

Secondo me, se si vuole togliere la dipendenza da l10n_it_withholding_tax_reason e l10n_it_withholding_tax significa che si vuole poter usare l10n_it_fatturapa_in per qualunque fattura senza però dover installare le funzionalità di gestione delle ritenute, perchè ci pensa il commercialista.

Per far questo, bisogna fare in modo che l10n_it_fatturapa_in importi i dati della ritenuta in campi informativi non legati ad alcun flusso, in modo però che all'utente sia almeno chiaro cosa deve pagare.

Per far questo si potrebbe spezzare l10n_it_withholding in 2:

• una parte per il solo calcolo del netto a pagare in fattura
• una parte per rilevare la ritenuta da versare e gestire i successivi pagamenti

Il primo resta dipendenza di l10n_it_fatturapa_in. Il secondo si installa solo quando serve gestire il versamento delle ritenute.

Altrimenti

Si modifica l10n_it_fatturapa_in togliendo la dipendenza da l10n_it_withholding e si affida a lui il compito di mostrare i dati della ritenuta solo a livello informativo (quanto devo pagare?).

Poi, quando si installa l10n_it_withholding ci sarà un modulo ponte autoinstallante che si occuperà di scrivere i dati nella ritenuta nei posti gusti in modo che poi la ritenuta sia rilevata e pagata (quello che succede adesso).

[TheMule71]

La domanda è: ne vale la pena? Alla fine dipende da un altro modulo, mica di 20.

[eLBati]

Ah io sulla 12 non ho problemi

[SimoRubi]

Però con #2410 cosa risolvi? Che finchè non ricevi una fattura con ritenuta vai avanti senza errori, ma poi se la ricevi devi comunque installare l10n_it_withholding_tax_reason?

Sì, il vantaggio è che hai installato solo il codice che utilizzi invece di avere del codice che magari non userai mai. Questo è uno dei vantaggi della modularità di Odoo che in questo caso non stiamo sfruttando.

Questa issue è per un discorso generale:

Il modulo l10n_it_fatturapa_in deve poter importare qualsiasi fattura perché non si ha il controllo sulle fatture ricevute, ma non deve dipendere dai moduli dedicati alle specifiche funzionalità.

che sollevammo all'epoca della migrazione del modulo l10n_it_fatturapa_in: per fare la migrazione dovevamo aspettare che fosse migrato l10n_it_withholding_tax_reason. All'epoca nessuno trovò una spiegazione funzionale al fatto che per importare le fatture elettroniche serviva poter fare le ritenute quindi aprii questa issue.

La soluzione che ho proposto in https://github.com/OCA/l10n-italy/pull/2410 risolve il problema in modo generico: il modulo della singola funzionalità non si installa finché non serve.

Delle due soluzioni che hai proposto preferisco la seconda:

Si modifica l10n_it_fatturapa_in togliendo la dipendenza da l10n_it_withholding e si affida a lui il compito di mostrare i dati della ritenuta solo a livello informativo (quanto devo pagare?).

Poi, quando si installa l10n_it_withholding ci sarà un modulo ponte autoinstallante che si occuperà di scrivere i dati nella ritenuta nei posti gusti in modo che poi la ritenuta sia rilevata e pagata (quello che succede adesso).

[eLBati]

Sì, il vantaggio è che hai installato solo il codice che utilizzi invece di avere del codice che magari non userai mai

Ci interessano scenari di aziende che non ricevono mai fatture con ritenuta? Esistono?

[TheMule71]

Sì, il vantaggio è che hai installato solo il codice che utilizzi invece di avere del codice che magari non userai mai

Ci interessano scenari di aziende che non ricevono mai fatture con ritenuta? Esistono?

Sorry, chiusa per errore....

[TheMule71]

Dicevo, prima di pigiare il pulsante sbagliato, il modulo ponte non mi dispiace, ma va fatto il refactoring parziale di fatturapa_in per permettere l'override dei metodi. Per es. questa chiamata: https://github.com/OCA/l10n-italy/blob/756dc8c7800053925ecbcb4f17e77d38a0f7ed50/l10n_it_fatturapa_in/wizard/wizard_import_fatturapa.py#L1068 messa lì così non va bene.

Forse, si riesce a concentrare il codice in una sola funzione, che viene chiamata solo in presenza di dati ritenute. In fatturapa_in, il metodo tira un'eccezione direttamente (senza controllare che withholding_tax ci sia o meno), il modulo ponte fa l'override di tutto il metodo, facendo le chiamate ai metodi di withholding_tax.

[github-actions[bot]]

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.

[francesco-ooops]

@OCA/local-italy-maintainers teniamo aperto?

[primes2h]

@OCA/local-italy-maintainers teniamo aperto?

Per me si.

[github-actions[bot]]

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.