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

primes2h · 2022-03-24T10:18:47Z

Versioni coinvolte

14.0 [14.0] ADD account_receipt_journal: Define and use journals dedicated to receipts account-invoicing#1260 + [14.0] ADD account_receipt_sale account-invoicing#1267
Funzionalità non ancora migrate:
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

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:

l10n-italy/l10n_it_corrispettivi/views/account_view.xml

Lines 7 to 76 in 0709ef9

    
           <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?

The text was updated successfully, but these errors were encountered:

SirTakobi · 2022-03-24T10:26:35Z

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 · 2022-03-24T10:43:58Z

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 · 2022-03-28T13:57:39Z

L'idea di @primes2h la condivido.

TheMule71 · 2022-06-17T11:55:42Z

@primes2h
ti ho fatto una PR

tafaRU · 2022-07-14T15:27:00Z

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:

rilascio di account_receipt_print tramite [14.0] [ADD] new module account_receipt_print account-invoicing#849
~~[ ] rilascio di account_portal_receipt tramite [14.0] [ADD] new module account_portal_receipt account-invoicing#873~~
rilascio di account_receipt_portal tramite [14.0] [ADD] new module account_receipt_portal account-invoicing#1685
rilascio di account_receipt_payment tramite [14.0] [ADD] new module account_receipt_payment account-payment#719
creazione modulo account_receipt che dipende dai due precedenti

primes2h · 2022-07-14T19:00:10Z

* [ ]  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 · 2022-07-19T08:09:30Z

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:

rilascio di account_receipt_print tramite [14.0] [ADD] new module account_receipt_print account-invoicing#849

rilascio di account_portal_receipt tramite [14.0] [ADD] new module account_portal_receipt account-invoicing#873

creazione modulo account_receipt che dipende dai due precedenti

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 · 2022-07-19T08:52:05Z

@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 · 2022-07-19T09:04:44Z

@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 · 2022-07-19T09:19:23Z

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 · 2022-07-19T09:33:10Z

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 · 2022-07-19T10:08:39Z

@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 · 2022-07-19T10:52:29Z

@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 · 2022-07-19T12:45:30Z

@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 · 2022-10-09T08:41:59Z

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 · 2022-10-10T12:49:32Z

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

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

eLBati · 2022-10-10T13:40:00Z

OCA/account-invoicing#1260

primes2h · 2022-10-10T15:47:33Z

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 · 2022-10-18T07:00:29Z

#2972 (comment)

primes2h · 2023-01-18T14:49:35Z

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 · 2023-02-01T05:58:48Z

I moduli per le ricevute su v14 sono sostanzialmente 2:

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 · 2023-02-01T16:02:54Z

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).

github-actions · 2024-01-07T12:27:12Z

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 · 2024-03-15T08:32:06Z

Ho aperto questa PR per visualizzare le ricevute nel portale

OCA/account-invoicing#1685

primes2h · 2024-03-15T17:42:34Z

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

OCA/account-payment#719

SirAionTech · 2024-03-18T08:11:08Z

@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 · 2024-03-19T20:35:12Z

@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 · 2024-03-20T08:22:12Z

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.

github-actions · 2024-09-22T12:33:30Z

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 added the enhancement label Mar 24, 2022

tafaRU mentioned this issue May 11, 2022

14.0 mig l10n it corrispettivi #2504

Closed

tafaRU added 14.0 triaged labels Jul 8, 2022

FrancescoBallerini mentioned this issue Jul 9, 2022

[14.0] Gestione move_type per ricevute legate agli ordini #2862

Closed

tafaRU self-assigned this Jul 13, 2022

eLBati mentioned this issue Oct 10, 2022

[14.0] porting l10n_it_corrispettivi #2972

Closed

This was referenced Oct 20, 2022

Migration to version 14.0 #1905

Open

[MIG] l10n_it_corrispettivi_fatturapa_out #2979

Merged

primes2h mentioned this issue Jan 18, 2023

[14.0] ADD account_receipt_sale OCA/account-invoicing#1267

Merged

github-actions bot added the stale PR/Issue without recent activity, it'll be soon closed automatically. label Jan 7, 2024

primes2h removed the stale PR/Issue without recent activity, it'll be soon closed automatically. label Jan 29, 2024

github-actions bot added the stale PR/Issue without recent activity, it'll be soon closed automatically. label Sep 22, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

primes2h commented Mar 24, 2022 •

edited

Loading

SirTakobi commented Mar 24, 2022

primes2h commented Mar 24, 2022

stevech091 commented Mar 28, 2022

TheMule71 commented Jun 17, 2022

tafaRU commented Jul 14, 2022 •

edited by primes2h

Loading

primes2h commented Jul 14, 2022 •

edited

Loading

SirTakobi commented Jul 19, 2022

stevech091 commented Jul 19, 2022

SirTakobi commented Jul 19, 2022

tafaRU commented Jul 19, 2022

SirTakobi commented Jul 19, 2022

primes2h commented Jul 19, 2022

SirTakobi commented Jul 19, 2022

primes2h commented Jul 19, 2022 •

edited

Loading

eLBati commented Oct 9, 2022

tafaRU commented Oct 10, 2022

eLBati commented Oct 10, 2022

primes2h commented Oct 10, 2022

eLBati commented Oct 18, 2022

primes2h commented Jan 18, 2023 •

edited

Loading

eLBati commented Feb 1, 2023

primes2h commented Feb 1, 2023 •

edited

Loading

github-actions bot commented Jan 7, 2024

primes2h commented Mar 15, 2024

primes2h commented Mar 15, 2024

SirAionTech commented Mar 18, 2024

primes2h commented Mar 19, 2024

SirAionTech commented Mar 20, 2024

github-actions bot commented Sep 22, 2024

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

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

Comments

primes2h commented Mar 24, 2022 • edited Loading

Modulo l10n_it_corrispettivi

SirTakobi commented Mar 24, 2022

primes2h commented Mar 24, 2022

stevech091 commented Mar 28, 2022

TheMule71 commented Jun 17, 2022

tafaRU commented Jul 14, 2022 • edited by primes2h Loading

primes2h commented Jul 14, 2022 • edited Loading

SirTakobi commented Jul 19, 2022

stevech091 commented Jul 19, 2022

SirTakobi commented Jul 19, 2022

tafaRU commented Jul 19, 2022

SirTakobi commented Jul 19, 2022

primes2h commented Jul 19, 2022

SirTakobi commented Jul 19, 2022

primes2h commented Jul 19, 2022 • edited Loading

eLBati commented Oct 9, 2022

tafaRU commented Oct 10, 2022

eLBati commented Oct 10, 2022

primes2h commented Oct 10, 2022

eLBati commented Oct 18, 2022

primes2h commented Jan 18, 2023 • edited Loading

eLBati commented Feb 1, 2023

primes2h commented Feb 1, 2023 • edited Loading

github-actions bot commented Jan 7, 2024

primes2h commented Mar 15, 2024

primes2h commented Mar 15, 2024

SirAionTech commented Mar 18, 2024

primes2h commented Mar 19, 2024

SirAionTech commented Mar 20, 2024

github-actions bot commented Sep 22, 2024

primes2h commented Mar 24, 2022 •

edited

Loading

Modulo `l10n_it_corrispettivi`

tafaRU commented Jul 14, 2022 •

edited by primes2h

Loading

primes2h commented Jul 14, 2022 •

edited

Loading

primes2h commented Jul 19, 2022 •

edited

Loading

primes2h commented Jan 18, 2023 •

edited

Loading

primes2h commented Feb 1, 2023 •

edited

Loading