[ADD] new module l10n_it_fatturapa_auto_downpayment

[TheMule71]

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]

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]

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.

[MaurizioPellegrinet]

Functional test: OK

[SirAionTech]

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

[SirAionTech]

Il metodo in super

l10n-italy/l10n_it_fiscal_document_type/models/account_move.py

Line 30 in 0403b98

def _get_document_fiscal_type(

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?

[TheMule71]

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.

[SirAionTech]

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

[TheMule71]

La _get_document_fiscal_type viene chiamata da una compute

l10n-italy/l10n_it_fiscal_document_type/models/account_move.py

Lines 8 to 28 in f35ef20

	def _compute_set_document_fiscal_type(self):
	for invoice in self:
	# Edit only draft invoices
	# or invoices that do not have a document type
	if invoice.state != "draft" and invoice.fiscal_document_type_id:
	continue
	# If there is already a fitting document type, do not change it
	accepted_document_type_ids = invoice._get_document_fiscal_type(
	invoice.move_type,
	invoice.partner_id,
	invoice.fiscal_position_id,
	invoice.journal_id,
	)
	if invoice.fiscal_document_type_id.id in accepted_document_type_ids:
	continue
	document_type = False
	if accepted_document_type_ids:
	document_type = accepted_document_type_ids[0]
	invoice.fiscal_document_type_id = document_type

fattura per fattura.

Per qualche motivo, chi l'ha scritta ha deciso di passare uno ad uno i campi usati per decidere, data una
fattura, l'elenco dei tipi documento disponibili per la scelta.

Si tratta di scelta discutibile, un metodo che li legga da self avrebbe avuto molto più senso. Ma rimane che la logica della funzione - sia per come è definita, sia per come è usata - è quella di fornire i possibili valore del document type di una singola fattura.

La scelta ha fatto si che sia tecnicamente possibile chiamarla su in recordset, ma logicamente non ha senso, visto che comunque o gestisci il fatto che fatture diverse hatto tutte gli stessi valori per i campi in questione, oppure semplicemente la chiami coi valori fattura per fattura, oppure ottieni una risposta che non si puó applicare ad un recordset, ma solo alla fattura di cui hai passato i valori.

In altre parole, il metodo prende comunue i dati specifici singoli e non supporta in ogni caso un recordset, sul quale funziona per caso e non fornisce la risposta giusta. Visto che stiamo parlando di un ipotetico modulo la usasse in quel modo, funzionerebbe solo per caso e non farebbe quello che dovrebbe comunque, visto che non lavora sul recordset ma sui singoli valori. Sarebbe comunque un bug, che non tira eccezione solo grazie a un secondo bug (o scelta di design molto discutibile).

Per altro, non c'è soluzione... se _get_document_fiscal_type() fornisce l'elenco dei possibili valore del document type di una specifica fattura, se la si vuole estendere a criteri che vanno oltre agli argomenti già previsti, bisogna accedere a self. E a quel punto, che ci sia ensure_one in testa o dia errore dopo cambia poco. La posso anche togliere, ma l'eccezione la tirerebbe dopo comunque.

Posso anche riscrivere il metodo per loopare sui record, controllare che siano tutte fatture di downpayment, e restituire un elenco di valori, per poi tirare un'eccezione se le fatture non sono omogenee (o tutte acconti o tutte no). Ma non cambia il fatto che comunque l'ipotetico modulo che chiama il metodo su recordset non omogenei si troverebbe un'eccezione che ieri non c'era.

E poi se parliamo di ipotetici moduli là fuori, ogni volta che si fixa un bug si va a rischio di "rompere" un qualche modulo che implementi una fix o un workaround del bug. La cosa non ci deve impedire di fixare bug, e nel modo migliore.

[TheMule71]

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

[ADD] for adding new modules

Corretto. Grazie per la review!

[sergiocorato]

@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]

ci sono novità in questo modulo?

[TheMule71]

ci sono novità in questo modulo?

Dovrebbe essere tutto a posto.

[SirAionTech]

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

[SirAionTech]

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

[TheMule71]

Fatto.

[SirAionTech]

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

[TheMule71]

Fatto.

[github-actions]

There hasn't been any activity on this pull request in the past 4 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 PR to never become stale, please ask a PSC member to apply the "no stale" label.

[TheMule71]

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

Visto, ma passi dalla creazione fattura via sale order. Io per es. ho implementato un modo diverso di creare le fatture di downpayment per un cliente, che vedeva proprio una limitazione nel dover passare dal SO. Gli acconti che preparano sono slegati da un singolo SO e fatture di SO diversi possono andare a scontare dalla stessa fattura di acconto.

È compatibile con il resto di Odoo perche _is_downpayment() fa la cosa giusta e riconosce sia le fatture di acconto standard Odoo sia quelle create direttamente senza passare da SO.

Abbiamo già una funzione che prende:

                invoice.move_type,
                invoice.partner_id,
                invoice.fiscal_position_id,
                invoice.journal_id,

e propone un elenco di possibili TD* da presentare all'utente. Il che è un po' diverso da impostare un default.