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

[ADD] new module l10n_it_fatturapa_auto_downpayment #4230

Open
wants to merge 1 commit into
base: 16.0
Choose a base branch
from

Conversation

TheMule71
Copy link
Contributor

@TheMule71 TheMule71 commented Jun 25, 2024

Se la fattura è un acconto, setta automaticamente TD02 come tipo documento fiscale.
Tale comportamento è simile a l10n_it_edi

Rimpiazza #4222

Fixes: #4221

@francesco-ooops
Copy link
Contributor

Non so dare una valutazione su questo caso specifico, ma credo che un obiettivo di oca-italy dovrebbe essere cercare di evitare la proliferazione di nuovi moduli per la contabilità... che ne pensate?

@TheMule71 TheMule71 force-pushed the 16.0-new-l10n_it_fatturapa_auto_downpayment branch from 0e68b98 to 9f96f96 Compare June 25, 2024 13:09
@TheMule71
Copy link
Contributor Author

Non so dare una valutazione su questo caso specifico, ma credo che un obiettivo di oca-italy dovrebbe essere cercare di evitare la proliferazione di nuovi moduli per la contabilità... che ne pensate?

#4222 (comment)

Ho fatto sia una PR come modifica a modulo esistente e sia una PR come modulo nuovo. Il motivo per avere un nuovo modulo è solo per evitare di introdurre la dipendenza dal modulo sale su l10n_it_fiscal_document_type.

@TheMule71 TheMule71 force-pushed the 16.0-new-l10n_it_fatturapa_auto_downpayment branch 2 times, most recently from fd91b78 to 5c5592b Compare June 25, 2024 14:02
Copy link

@MaurizioPellegrinet MaurizioPellegrinet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Functional test: OK

Copy link
Contributor

@SirAionTech SirAionTech left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Grazie della PR!
Potresti mettere [ADD] invece di [IMP] nel messaggio del commit?

[ADD] for adding new modules

(da https://www.odoo.com/documentation/16.0/contributing/development/git_guidelines.html#tag-and-module-name)

Grande che hai messo un test 😄 fammi sapere cosa ne pensi delle note qui sotto, le uniche cose bloccanti per me sono nell'override

def _get_document_fiscal_type(
self, move_type=None, partner=None, fiscal_position=None, journal=None
):
self.ensure_one()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Il metodo in super

non impone questo vincolo, quindi in teoria può gestire un recordset.
È possibile spostare questo vincolo e il resto del codice che ne ha bisogno dentro un if len(self) == 1 o qualcosa di analogo?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

L'unico punto in cui è chiamata è la _compute_set_document_fiscal_type(), all'interno di un loop fattura per fattura.

Piu di quello però, il valore di ritorno è un alista di possibili TDxx validi per una sola fattura. La funziona ignora self di fatto (potrebbe essere @api.model), ma gli vengono passati un solo partner, una sola posizione fiscale, un solo journal, relativi ad una sola fattura.

In pratica la funzione originale è usata come se fosse self.ensure_one() e scritta come se fosse @api.model . Non credo possa essere chiamata su un recordset, visto che per avere un risultato sensato dovresti assicurarti a priori che sono fatture con lo stesso partner, stessa fpos, stesso journal.

Io ho aggiunto self.ensure_one() perché effettivamente uso self.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

È vero che il metodo in super si comporta come un api.model e il risultato dipende solo dai suoi parametri, però credo che questo sia un motivo in più perché l'override aggiunto in questa PR non debba aggiungere vincoli a self.

Attualmente potrebbero esserci altri moduli che chiamano _get_document_fiscal_type su un recordset e funzionano; dopo l'installazione di questo modulo invece verrebbe sollevato un errore, credo sia meglio evitarlo e rimanere compatibili con il codice esistente.
Non è detto che lo facciano perché si aspettano un risultato in base a self, ma semplicemente perché è possibile farlo (come è possibile farlo per i metodi api.model).

l10n_it_fatturapa_auto_downpayment/readme/CONFIGURE.md Outdated Show resolved Hide resolved
l10n_it_fatturapa_auto_downpayment/models/account_move.py Outdated Show resolved Hide resolved
@TheMule71
Copy link
Contributor Author

TheMule71 commented Jul 19, 2024

Grazie della PR! Potresti mettere [ADD] invece di [IMP] nel messaggio del commit?

[ADD] for adding new modules

Corretto. Grazie per la review!

@TheMule71 TheMule71 force-pushed the 16.0-new-l10n_it_fatturapa_auto_downpayment branch 2 times, most recently from b79d2be to 8cbb8df Compare July 19, 2024 08:27
@sergiocorato
Copy link
Contributor

sergiocorato commented Aug 28, 2024

@TheMule71 ho aggiunto la PR che avevo proposto in precedenza sulla 14.0, erede di quella proposta sulla 12.0, che hanno un approccio diverso al problema.

@matteoopenf
Copy link
Contributor

ci sono novità in questo modulo?

@TheMule71 TheMule71 force-pushed the 16.0-new-l10n_it_fatturapa_auto_downpayment branch from 8cbb8df to 02b2b34 Compare October 21, 2024 13:22
@TheMule71 TheMule71 requested a review from SirAionTech October 21, 2024 13:23
@TheMule71
Copy link
Contributor Author

ci sono novità in questo modulo?

Dovrebbe essere tutto a posto.

@francesco-ooops francesco-ooops changed the title [IMP] new module l10n_it_fatturapa_auto_downpayment [ADD] new module l10n_it_fatturapa_auto_downpayment Oct 21, 2024
def _get_document_fiscal_type(
self, move_type=None, partner=None, fiscal_position=None, journal=None
):
self.ensure_one()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

È vero che il metodo in super si comporta come un api.model e il risultato dipende solo dai suoi parametri, però credo che questo sia un motivo in più perché l'override aggiunto in questa PR non debba aggiungere vincoli a self.

Attualmente potrebbero esserci altri moduli che chiamano _get_document_fiscal_type su un recordset e funzionano; dopo l'installazione di questo modulo invece verrebbe sollevato un errore, credo sia meglio evitarlo e rimanere compatibili con il codice esistente.
Non è detto che lo facciano perché si aspettano un risultato in base a self, ma semplicemente perché è possibile farlo (come è possibile farlo per i metodi api.model).

Comment on lines +47 to +50
Installation
============


Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Puoi eliminare INSTALL.md? Altrimenti viene creata questa sezione vuota.

Comment on lines +3 to +4
Alla creazione di una fattura di downpayment, viene settato
TD02 come fiscal document type.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Visto che non c'è nulla da configurare, penso sia meglio rimuovere questo file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

TD02 come default per il tipo documento nelle fatture di acconto
6 participants