search

OCA / l10n-italy

Odoo Italian localization
https://www.odoo-italia.org
GNU Affero General Public License v3.0
147 stars 301 forks source link

[RFC] refactoring l10n_it_corrispettivi, integrazione con ricevute Odoo #2722

Open primes2h opened 2 years ago

primes2h commented 2 years ago

Versioni coinvolte

Descrizione

Dalla versione 13.0 di Odoo le ricevute sono state integrate nel modulo account diventando una move_type alla pari di fatture e note di credito:

https://github.com/odoo/odoo/blob/5b099bf6135b2ff517078d1839b513da7830f718/addons/account/models/account_move.py#L154-L163

Per visualizzarle basta solo abilitarle nelle impostazioni dell'utente (caselle Ricevute di vendita e Ricevute di acquisto).

Alla luce di questo sarebbe importante valutare l'opportunità di utilizzare le funzionalità native messe a disposizione da Odoo che coprono gran parte di quelle presenti in l10n_it_corrispettivi.

Modulo l10n_it_corrispettivi

Da una prima analisi le viste (riportate anche qui sotto) sono già presenti nel modulo account:

https://github.com/OCA/l10n-italy/blob/0709ef90a161a0e70740409a0d5a7496a075a360/l10n_it_corrispettivi/views/account_view.xml#L7-L76

La parte di stampa, con relativo report sarebbe già coperta da questa PR:

https://github.com/OCA/account-invoicing/pull/849

Alla luce di ciò sarebbe sufficiente un piccolo modulo base che aggiunge i campi di l10n_it_corrispettivi nel journal, nel partner e nella fiscal position e poco altro. (non sarebbe neanche strettamente necessario che tale modulo stia in l10n_it_italy).

L'integrazione delle funzionalità consentirebbe anche il riutilizzo di tali campi in altri moduli (vedi ad es. la PR https://github.com/OCA/vertical-association/pull/103 previa opportuna modifica). P.S.: per completezza segnalo anche quest'altra PR https://github.com/OCA/account-invoicing/pull/873

In questo modo verrebbe semplificata la gestione del codice evitando inutili doppioni tra le ricevute native e quelle introdotte da l10n_it_corrispettivi.

Che ne pensate?

SirTakobi commented 2 years ago

Giusto per coordinarsi, la migrazione del modulo è in corso:

sto lavorando alla migrazione di l10n_it_corrispettivi

Originally posted by @tafaRU in https://github.com/OCA/l10n-italy/issues/1905#issuecomment-1076513601

primes2h commented 2 years ago

Giusto per coordinarsi, la migrazione del modulo è in corso:

sto lavorando alla migrazione di l10n_it_corrispettivi Originally posted by @tafaRU in #1905 (comment)

Hai ragione,mi sono scordato di scriverlo. Ho già parlato con lui della proposta. :-)

stevech091 commented 2 years ago

L'idea di @primes2h la condivido.

TheMule71 commented 2 years ago

@primes2h ti ho fatto una PR

tafaRU commented 2 years ago

Parlandone con @primes2h siamo giunti alla conclusione che il modulo relativo ai corrispettivi sulla 14.0 non ha più ragione di esistere in questo repository. Andrò pertanto a proporre su https://github.com/OCA/account-invoicing l'aggiunta del moduloaccount_receipt (con funzionalità equivalenti a quelle di l10n_it_corrispettivi).

Task list:

primes2h commented 2 years ago 
* [ ]  rilascio di `account_portal_receipt` tramite [[14.0] [ADD] new module account_portal_receipt account-invoicing#873](https://github.com/OCA/account-invoicing/pull/873)

Questa PR ora può essere testata in runboat.

SirTakobi commented 2 years ago

Parlandone con @primes2h siamo giunti alla conclusione che il modulo relativo ai corrispettivi sulla 14.0 non ha più ragione di esistere in questo repository. Andrò pertanto a proporre su https://github.com/OCA/account-invoicing l'aggiunta del moduloaccount_receipt (con funzionalità equivalenti a quelle di l10n_it_corrispettivi).

Task list:

Quindi sarebbe account_receipt a contenere la migrazione dei dati di l10n_it_corrispettivi? Giusto per capire se è il piccolo modulo base di cui scriveva @primes2h nella sua analisi:

Alla luce di ciò sarebbe sufficiente un piccolo modulo base che aggiunge i campi di l10n_it_corrispettivi nel journal, nel partner e nella fiscal position e poco altro. (non sarebbe neanche strettamente necessario che tale modulo stia in l10n_it_italy).

stevech091 commented 2 years ago

@SirTakobi ho solo un dubbio sul "rintracciarlo" quel modulo. Mi spiego: se entro in l10_it V14 come faccio a sapere che è stato fatto un modulo utilizzabile per l'Italia che copre quella funzionalità?

SirTakobi commented 2 years ago

@SirTakobi ho solo un dubbio sul "rintracciarlo" quel modulo. Mi spiego: se entro in l10_it V14 come faccio a sapere che è stato fatto un modulo utilizzabile per l'Italia che copre quella funzionalità?

Penso che questo sia più un problema di documentazione, comunque da chiarire, ma dovresti chiedere a chi si occupa di questo sviluppo. cc @tafaRU e @primes2h

In https://github.com/OCA/l10n-italy/issues/2722#issuecomment-1188737171 ho chiesto invece un chiarimento per quanto riguarda la migrazione dei dati.

tafaRU commented 2 years ago

Quindi sarebbe account_receipt a contenere la migrazione dei dati di l10n_it_corrispettivi?

Dal momento che il modulo atterrerebbe su https://github.com/OCA/account-invoicing non è pensabile farlo dipendere da un modulo della localizzazione italiana. Quello che possiamo fare è aggiungere le indicazioni di come effettuare la migrazione nel README del modulo stesso.

SirTakobi commented 2 years ago

Quindi sarebbe account_receipt a contenere la migrazione dei dati di l10n_it_corrispettivi?

Dal momento che il modulo atterrerebbe su https://github.com/OCA/account-invoicing non è pensabile farlo dipendere da un modulo della localizzazione italiana. Quello che possiamo fare è aggiungere le indicazioni di come effettuare la migrazione nel README del modulo stesso.

Grazie, mi interessava solo capire se la migrazione dei dati sarà responsabilità di account_receipt; per i dettagli della migrazione via script o README vedremo poi nella PR

primes2h commented 2 years ago

@SirTakobi ho solo un dubbio sul "rintracciarlo" quel modulo. Mi spiego: se entro in l10_it V14 come faccio a sapere che è stato fatto un modulo utilizzabile per l'Italia che copre quella funzionalità?

Penso che questo sia più un problema di documentazione, comunque da chiarire, ma dovresti chiedere a chi si occupa di questo sviluppo. cc @tafaRU e @primes2h

Si esatto, quello è principalmente un problema di documentazione da discutere a tempo debito.

Per quanto riguarda la migrazione dei dati, uno spunto potrebbe essere quello che è stato fatto tra ddt e delivery_note.

https://github.com/OCA/l10n-italy/tree/14.0/l10n_it_delivery_note#migrazione-dei-dati-da-l10n-it-ddt

SirTakobi commented 2 years ago

@SirTakobi ho solo un dubbio sul "rintracciarlo" quel modulo. Mi spiego: se entro in l10_it V14 come faccio a sapere che è stato fatto un modulo utilizzabile per l'Italia che copre quella funzionalità?

Penso che questo sia più un problema di documentazione, comunque da chiarire, ma dovresti chiedere a chi si occupa di questo sviluppo. cc @tafaRU e @primes2h

Si esatto, quello è principalmente un problema di documentazione da discutere a tempo debito.

Per quanto riguarda la migrazione dei dati, uno spunto potrebbe essere quello che è stato fatto tra ddt e delivery_note.

https://github.com/OCA/l10n-italy/tree/14.0/l10n_it_delivery_note#migrazione-dei-dati-da-l10n-it-ddt

Quella procedura serviva per rendere la migrazione opzionale, ed era per migrare i dati all'interno della stessa versione; nel nostro caso invece non si avrà scelta (la migrazione, se necessaria, deve essere eseguita) e la migrazione sarà tra due versioni di Odoo diverse. Quindi penso sia meglio avere uno script di migrazione o qualcosa che si esegua in automatico, se possibile.

Per buttare lì un'altra idea: in questo caso non vedrei problemi ad inserire nel modulo account_receipt uno script di pre/post_init che faccia qualcosa tipo https://github.com/OCA/l10n-italy/blob/0f6d2480597b555066598ee84d1906cf4decdc81/l10n_it_fatturapa_pec/migrations/12.0.1.10.0/pre-migration.py per quanto riguarda i dati del modulo l10n_it_corrispettivi. Per uno script del genere non credo serva nessuna dipendenza, ma forse mi sono perso qualche pezzo quindi per andare avanti con l'analisi penso sia meglio avere almeno una bozza di codice davanti, per questo ho scritto

per i dettagli della migrazione via script o README vedremo poi nella PR

primes2h commented 2 years ago

@SirTakobi ho solo un dubbio sul "rintracciarlo" quel modulo. Mi spiego: se entro in l10_it V14 come faccio a sapere che è stato fatto un modulo utilizzabile per l'Italia che copre quella funzionalità?

Penso che questo sia più un problema di documentazione, comunque da chiarire, ma dovresti chiedere a chi si occupa di questo sviluppo. cc @tafaRU e @primes2h

Si esatto, quello è principalmente un problema di documentazione da discutere a tempo debito. Per quanto riguarda la migrazione dei dati, uno spunto potrebbe essere quello che è stato fatto tra ddt e delivery_note. https://github.com/OCA/l10n-italy/tree/14.0/l10n_it_delivery_note#migrazione-dei-dati-da-l10n-it-ddt

Quella procedura serviva per rendere la migrazione opzionale, ed era per migrare i dati all'interno della stessa versione; nel nostro caso invece non si avrà scelta (la migrazione, se necessaria, deve essere eseguita) e la migrazione sarà tra due versioni di Odoo diverse. Quindi penso sia meglio avere uno script di migrazione o qualcosa che si esegua in automatico, se possibile.

Certamente, esplicito un po' meglio l'idea. Perché non pensare ad alcuni moduli "dummy" che avrebbero l'unica funzione di installare il corrispondente modulo nuovo e lanciare automaticamente lo script di migrazione dei dati?

Es. modulo dummy l10n_it_corrispettivi per la v. 14.0, che avrebbe come dipendenza account_receipt (che contiene la nuova struttura/campi). Questo modulo si occuperebbe solo di lanciare lo script per la migrazione dei dati, tipo quello tra ddt e delivery note, ma in modo automatico. Inoltre il suo README conterrebbe tutte le istruzioni sullo scopo del modulo e su come utilizzarlo. Oltre a risolvere il problema della documentazione, un altro grosso vantaggio è che permetterebbe di automatizzare la migrazione del modulo tra la 12.0 e la 14.0. Una volta terminata la migrazione il modulo dummy può essere disinstallato.

Quindi, ad es.: Modulo dummy l10n_corrispettivi v.14.0 → avrebbe come dipendenza account_receipt Modulo dummy l10n_corrispettivi_sale v.14.0 → avrebbe come dipendenza account_receipt_sale (vedi https://github.com/OCA/l10n-italy/issues/2862#issuecomment-1184587146) ecc..

Sarebbe una soluzione un po' atipica in Odoo ma, se fattibile, risolverebbe in modo elegante il problema. [1]

[1] metodologia utilizzata anche in altri ambiti software (es. https://serverfault.com/questions/610028/what-is-a-dummy-package)

eLBati commented 1 year ago

aggiunta del moduloaccount_receipt (con funzionalità equivalenti a quelle di l10n_it_corrispettivi).

Provo a riassumere le funzionalità attualmente mancanti su v14 in merito alle ricevute:

La gestione dei campi Receipts su posizione fiscale e partner diventa superflua, in quanto la scelta se fare o meno una ricevuta viene fatta prima, dall'utente, facendo click sul menù Receipts, o da altri moduli, impostando move_type (o default_move_type) a out_receipt.

In pratica, tramite lo stesso form non può essere possibile decidere se fare una fattura o una ricevuta in base al cliente e alla posizione fiscale, come avviene adesso con l10n_it_corrispettivi.

creazione modulo account_receipt che dipende dai due precedenti

Considerate le funzionalità elencate sopra, non credo debba dipendere dagli altri 2 moduli e credo si possa chiamare account_receipt_journal.

Per quanto riguarda gli script di upgrade, appoggio l'idea del modulo dummy l10n_it_corrispettivi

@tafaRU @primes2h se non ci state lavorando, posso iniziare io.

tafaRU commented 1 year ago

@tafaRU @primes2h se non ci state lavorando, posso iniziare io.

al momento non ci sto lavorando, procedi pure, grazie :+1:

eLBati commented 1 year ago

https://github.com/OCA/account-invoicing/pull/1260

primes2h commented 1 year ago

aggiunta del moduloaccount_receipt (con funzionalità equivalenti a quelle di l10n_it_corrispettivi).

Provo a riassumere le funzionalità attualmente mancanti su v14 in merito alle ricevute:

* Identificare i registri di tipo Receipts

* Creare un Receipts Journal

* Impostare automaticamente nella ricevuta un Receipts Journal

La gestione dei campi Receipts su posizione fiscale e partner diventa superflua, in quanto la scelta se fare o meno una ricevuta viene fatta prima, dall'utente, facendo click sul menù Receipts, o da altri moduli, impostando move_type (o default_move_type) a out_receipt.

In pratica, tramite lo stesso form non può essere possibile decidere se fare una fattura o una ricevuta in base al cliente e alla posizione fiscale, come avviene adesso con l10n_it_corrispettivi.

creazione modulo account_receipt che dipende dai due precedenti

Considerate le funzionalità elencate sopra, non credo debba dipendere dagli altri 2 moduli e credo si possa chiamare account_receipt_journal.

Per quanto riguarda gli script di upgrade, appoggio l'idea del modulo dummy l10n_it_corrispettivi

@tafaRU @primes2h se non ci state lavorando, posso iniziare io.

Procedi pure, grazie mille!

eLBati commented 1 year ago

https://github.com/OCA/l10n-italy/pull/2972#issuecomment-1281901222

primes2h commented 1 year ago

Parlandone con @primes2h siamo giunti alla conclusione che il modulo relativo ai corrispettivi sulla 14.0 non ha più ragione di esistere in questo repository. Andrò pertanto a proporre su https://github.com/OCA/account-invoicing l'aggiunta del moduloaccount_receipt (con funzionalità equivalenti a quelle di l10n_it_corrispettivi).

Task list:

* [x]   rilascio di `account_receipt_print` tramite [[14.0] [ADD] new module account_receipt_print account-invoicing#849](https://github.com/OCA/account-invoicing/pull/849)

* [ ]  rilascio di `account_portal_receipt` tramite [[14.0] [ADD] new module account_portal_receipt account-invoicing#873](https://github.com/OCA/account-invoicing/pull/873)

* [ ]  creazione modulo `account_receipt` che dipende dai due precedenti

Mi sono accorto ora che c'è un errore. Non è dipende dai due precedenti ma è dipendenza dei due precedenti. Alla luce di questo, è il caso che vengano rivalutati i successivi commenti.

Se poi il modulo è superfluo e le sue funzionalità (campi "Receipts" per posizione fiscale e partner) non servono come indicato qui da @eLBati allora nessun problema.

Vedi anche https://github.com/OCA/account-invoicing/pull/1267

eLBati commented 1 year ago

I moduli per le ricevute su v14 sono sostanzialmente 2:

  1. account_receipt_journal
  2. account_receipt_sale

In più c'è l10n_it_corrispettivi_fatturapa_out che si occupa di nascondere, per le ricevute, le parti di interfaccia relative alle fatture elettroniche, tipo il pulsante Export E-invoice

primes2h commented 1 year ago

I moduli per le ricevute su v14 sono sostanzialmente 2:

1. [account_receipt_journal](https://github.com/OCA/account-invoicing/pull/1260)
2. [account_receipt_sale](https://github.com/OCA/account-invoicing/pull/1267)

Avere due soli moduli comporta il seguente problema.

account_receipt_journal è generico. Aggiunge due journal, quindi supporta sia le ricevute di vendita che quelle di acquisto.

La gestione dei campi Receipts su posizione fiscale e partner è stata spostata invece in account_receipt_sale, quindi attualmente è legata solo alla parte vendite. Ciò significa che se in un qualsiasi altro modulo volessi utilizzare quei campi (es. quello in partner) per gestire le ricevute di acquisto sarei obbligato a installare anche la parte di vendita. La cosa potrebbe essere gestita da un altro modulo, (es. account_receipt_purchase) ma a quel punto avremmo due campi Receiptsnel partner che fanno sostanzialmente la stessa cosa.

È per questo motivo che qui si parlava della necessità di avere il modulo generico account_receipt contenente la parte di gestione dei campi Receipts per partner e posizione fiscale. (sostituto di l10n_it_corrispettivi), non legato nello specifico a vendite o acquisti.

Tra l'altro il modulo account_receipt_sale, dato che consente di creare ricevute da ordini di vendita, dovrebbe dipendere da sale_management e non da sale.

In più c'è l10n_it_corrispettivi_fatturapa_out che si occupa di nascondere, per le ricevute, le parti di interfaccia relative alle fatture elettroniche, tipo il pulsante Export E-invoice

:+1: ~P.S: per coerenza con il resto dovrebbe però cambiare nome in l10n_it_receipt_fatturapa_out.~ (è stato incluso in l10n_it_fatturapa_out).

github-actions[bot] commented 8 months 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.

primes2h commented 6 months ago

Ho aperto questa PR per visualizzare le ricevute nel portale

https://github.com/OCA/account-invoicing/pull/1685

primes2h commented 6 months ago

Ho aperto questa PR per che consente di pagare le ricevute di vendita dal portale.

https://github.com/OCA/account-payment/pull/719

SirAionTech commented 5 months ago

@primes2h grazie, ma sono funzionalità che erano in l10n_it_corrispettivi o sono cose nuove?

Se le funzionalità di l10n_it_corrispettivi sono coperte (le PR che le implementano sono mergiate) chiuderei questa issue: le PR in descrizione sono tutte mergiate quindi forse si può chiudere? Altrimenti, potresti aggiornare la descrizione per elencare cosa manca per chiudere la issue?

primes2h commented 5 months ago

@primes2h grazie, ma sono funzionalità che erano in l10n_it_corrispettivi o sono cose nuove?

Sono funzionalità nuove.

Se le funzionalità di l10n_it_corrispettivi sono coperte (le PR che le implementano sono mergiate) chiuderei questa issue: le PR in descrizione sono tutte mergiate quindi forse si può chiudere? Altrimenti, potresti aggiornare la descrizione per elencare cosa manca per chiudere la issue?

Le funzionalità principali ci sono tutte, mancano quelle relative a: https://github.com/OCA/l10n-italy/tree/12.0/l10n_it_website_portal_corrispettivi https://github.com/OCA/l10n-italy/tree/12.0/l10n_it_website_sale_corrispettivi

Ho aggiornato la descrizione.

SirAionTech commented 5 months ago

Se le funzionalità di l10n_it_corrispettivi sono coperte (le PR che le implementano sono mergiate) chiuderei questa issue: le PR in descrizione sono tutte mergiate quindi forse si può chiudere? Altrimenti, potresti aggiornare la descrizione per elencare cosa manca per chiudere la issue?

Le funzionalità principali ci sono tutte, mancano quelle relative a: https://github.com/OCA/l10n-italy/tree/12.0/l10n_it_website_portal_corrispettivi https://github.com/OCA/l10n-italy/tree/12.0/l10n_it_website_sale_corrispettivi

Ho aggiornato la descrizione.

Capito grazie, quindi le due PR https://github.com/OCA/account-invoicing/pull/1685 e https://github.com/OCA/account-payment/pull/719 che hai linkato in https://github.com/OCA/l10n-italy/issues/2722#issuecomment-1999164309 e https://github.com/OCA/l10n-italy/issues/2722#issuecomment-2000145480 sono extra, mentre per chiudere la issue manca solo la migrazione di questi ultimi due moduli.