Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
1 task
primes2h opened this issue Mar 24, 2022 · 29 comments
Closed
1 task
Assignees
Labels
14.0 enhancement stale PR/Issue without recent activity, it'll be soon closed automatically. triaged

Comments

@primes2h
Copy link
Contributor

primes2h commented Mar 24, 2022

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:

<record id="invoice_form" model="ir.ui.view">
<field name="name">account.invoice.form</field>
<field name="model">account.invoice</field>
<field name="type">form</field>
<field name="inherit_id" ref="account.invoice_form"/>
<field name="arch" type="xml">
<field name="fiscal_position_id" position="after">
<field name="corrispettivo"/>
</field>
</field>
</record>
<record id="corrispettivi_form" model="ir.ui.view">
<field name="name">account.corrispettivi.form</field>
<field name="model">account.invoice</field>
<field name="type">form</field>
<field name="mode">primary</field>
<field name="inherit_id" ref="account.invoice_form"/>
<field name="arch" type="xml">
<header position="inside">
<button name="corrispettivo_print" string="Print Receipt"
type="object" class="oe_highlight" groups="base.group_user"
attrs="{'invisible':['|',('sent','=',True), ('state', 'not in', ('open', 'in_payment', 'paid'))]}"/>
<button name="corrispettivo_print" string="Print Receipt"
type="object" groups="base.group_user"
attrs="{'invisible':['|',('sent','=',False), ('state', 'not in', ('open', 'in_payment', 'paid'))]}"/>
</header>
<xpath expr="//button[@name='action_invoice_sent' and hasclass('oe_highlight')]" position="attributes">
<attribute name="invisible">True</attribute>
</xpath>
<xpath expr="//button[@name='action_invoice_sent' and not(hasclass('oe_highlight'))]" position="attributes">
<attribute name="invisible">True</attribute>
</xpath>
</field>
</record>
<record id="account.action_invoice_tree" model="ir.actions.act_window">
<field name="domain">[('corrispettivo', '=', False)]</field>
</record>
<record id="account.action_invoice_tree1" model="ir.actions.act_window">
<field name="domain">[('type', 'in', ('out_invoice', 'out_refund')), ('corrispettivo', '=', False)]</field>
</record>
<record id="action_corrispettivi_tree1" model="ir.actions.act_window">
<field name="name">Receipts</field>
<field name="res_model">account.invoice</field>
<field name="view_type">form</field>
<field name="view_mode">tree,kanban,form,calendar,pivot,graph</field>
<field eval="False" name="view_id"/>
<field name="domain">[('type','in',('out_invoice', 'out_refund')), ('corrispettivo', '=', True)]</field>
<field name="context">{'type':'out_invoice', 'journal_type': 'sale', 'default_corrispettivi': True}</field>
</record>
<record id="action_corrispettivi_tree1_view1" model="ir.actions.act_window.view">
<field eval="1" name="sequence"/>
<field name="view_mode">tree</field>
<field name="view_id" ref="account.invoice_tree"/>
<field name="act_window_id" ref="action_corrispettivi_tree1"/>
</record>
<record id="action_corrispettivi_tree1_view2" model="ir.actions.act_window.view">
<field eval="2" name="sequence"/>
<field name="view_mode">form</field>
<field name="view_id" ref="l10n_it_corrispettivi.corrispettivi_form"/>
<field name="act_window_id" ref="action_corrispettivi_tree1"/>
</record>
<menuitem action="action_corrispettivi_tree1" id="menu_action_corrispettivi_tree"
parent="account.menu_finance_receivables"/>

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

OCA/account-invoicing#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 OCA/vertical-association#103 previa opportuna modifica).
P.S.: per completezza segnalo anche quest'altra PR OCA/account-invoicing#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
Copy link
Contributor

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

sto lavorando alla migrazione di l10n_it_corrispettivi

Originally posted by @tafaRU in #1905 (comment)

@primes2h
Copy link
Contributor Author

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
Copy link

L'idea di @primes2h la condivido.

@TheMule71
Copy link
Contributor

@primes2h
ti ho fatto una PR

@tafaRU
Copy link
Member

tafaRU commented Jul 14, 2022

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
Copy link
Contributor Author

primes2h commented Jul 14, 2022

* [ ]  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
Copy link
Contributor

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
Copy link

@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
Copy link
Contributor

@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 #2722 (comment) ho chiesto invece un chiarimento per quanto riguarda la migrazione dei dati.

@tafaRU
Copy link
Member

tafaRU commented Jul 19, 2022

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
Copy link
Contributor

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
Copy link
Contributor Author

@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
Copy link
Contributor

@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
Copy link
Contributor Author

primes2h commented Jul 19, 2022

@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 #2862 (comment))
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
Copy link
Member

eLBati commented Oct 9, 2022

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.

@tafaRU
Copy link
Member

tafaRU commented Oct 10, 2022

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

al momento non ci sto lavorando, procedi pure, grazie 👍

@eLBati
Copy link
Member

eLBati commented Oct 10, 2022

@primes2h
Copy link
Contributor Author

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
Copy link
Member

eLBati commented Oct 18, 2022

#2972 (comment)

@primes2h
Copy link
Contributor Author

primes2h commented Jan 18, 2023

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 OCA/account-invoicing#1267

@eLBati
Copy link
Member

eLBati commented Feb 1, 2023

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
Copy link
Contributor Author

primes2h commented Feb 1, 2023

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

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

Copy link

github-actions bot commented Jan 7, 2024

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.

@github-actions github-actions bot added the stale PR/Issue without recent activity, it'll be soon closed automatically. label Jan 7, 2024
@primes2h primes2h removed the stale PR/Issue without recent activity, it'll be soon closed automatically. label Jan 29, 2024
@primes2h
Copy link
Contributor Author

Ho aperto questa PR per visualizzare le ricevute nel portale

OCA/account-invoicing#1685

@primes2h
Copy link
Contributor Author

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

OCA/account-payment#719

@SirAionTech
Copy link
Contributor

@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
Copy link
Contributor Author

@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
Copy link
Contributor

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 OCA/account-invoicing#1685 e OCA/account-payment#719 che hai linkato in #2722 (comment) e #2722 (comment) sono extra, mentre per chiudere la issue manca solo la migrazione di questi ultimi due moduli.

Copy link

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.

@github-actions github-actions bot added the stale PR/Issue without recent activity, it'll be soon closed automatically. label Sep 22, 2024
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Oct 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
14.0 enhancement stale PR/Issue without recent activity, it'll be soon closed automatically. triaged
Projects
None yet
Development

No branches or pull requests

7 participants