-
-
Notifications
You must be signed in to change notification settings - Fork 306
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
Comments
Giusto per coordinarsi, la migrazione del modulo è in corso:
|
Hai ragione,mi sono scordato di scriverlo. Ho già parlato con lui della proposta. :-) |
L'idea di @primes2h la condivido. |
@primes2h |
Parlandone con @primes2h siamo giunti alla conclusione che il modulo relativo ai corrispettivi sulla Task list:
|
Questa PR ora può essere testata in runboat. |
Quindi sarebbe
|
@SirTakobi ho solo un dubbio sul "rintracciarlo" quel modulo. |
Penso che questo sia più un problema di documentazione, comunque da chiarire, ma dovresti chiedere a chi si occupa di questo sviluppo. In #2722 (comment) ho chiesto invece un chiarimento per quanto riguarda la migrazione dei dati. |
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 |
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. Per buttare lì un'altra idea: in questo caso non vedrei problemi ad inserire nel modulo
|
Certamente, esplicito un po' meglio l'idea. Es. modulo dummy Quindi, ad es.: 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) |
Provo a riassumere le funzionalità attualmente mancanti su v14 in merito alle ricevute:
La gestione dei campi 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
Considerate le funzionalità elencate sopra, non credo debba dipendere dagli altri 2 moduli e credo si possa chiamare 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! |
Mi sono accorto ora che c'è un errore. Non è 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 |
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 |
Avere due soli moduli comporta il seguente problema.
La gestione dei campi È per questo motivo che qui si parlava della necessità di avere il modulo generico Tra l'altro il modulo
👍 |
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. |
Ho aperto questa PR per visualizzare le ricevute nel portale |
Ho aperto questa PR per che consente di pagare le ricevute di vendita dal portale. |
@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? |
Sono funzionalità nuove.
Le funzionalità principali ci sono tutte, mancano quelle relative a: 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. |
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. |
Versioni coinvolte
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 unamove_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
eRicevute 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
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: