[14.0][MIG] l10n_it_fatturapa_in #1990
Conversation
@TheMule71 puoi fare delle PR in bozza e segnarle come 'pronte per review' quando le hai completate |
|
@SimoRubi posso cambiare lo stato anche adesso? o va rifatta? |
Puoi farlo anche adesso, dovresti avere un 'convert to draft' vicino a dove sarà la lista dei reviewer: |
|
Fatto, grazie. |
TheMule71
force-pushed
the
14.0-mig-l10n_it_fatturapa_in
branch
from
101e5f3
to
4608797
Compare
|
@TheMule71 FYI: il modulo pare funzionare correttamente con xmlschema 1.4.x ma non con xmlschema 1.5.x. Con 1.5 ricevo: |
TheMule71
force-pushed
the
14.0-mig-l10n_it_fatturapa_in
branch
2 times, most recently
from
2e799cd
to
99390cb
Compare
|
Un esempio di fattura in con cassa e ritenuta d'acconto che al momento rompe l'import. |
| self.set_roundings(FatturaBody, invoice) | ||
|
|
||
| # compute the invoice | ||
| invoice._move_autocomplete_invoice_lines_values() |
There was a problem hiding this comment.
@TheMule71
In caso di fatture con arrotondamento IVA quel _move_autocomplete_invoice_line_values pare che faccia casino.
Ad esempio con quasi tutte le fatture amazon. Ho provato a capirci qualcosa ma non ho risolto nulla.
Posso fornire un XML di esempio.
| wiz_obj = self.env["wizard.import.fatturapa"].with_context( | ||
| from_attachment=att | ||
| ) | ||
| if wiz_obj: |
There was a problem hiding this comment.
Dato che wiz_obj non ha dati, tutti i campi messi a False sopra non verranno mai popolati.
Potresti togliere la if così da far popolare gli altri campi.
TheMule71
force-pushed
the
14.0-mig-l10n_it_fatturapa_in
branch
from
856c4a8
to
3f2204f
Compare
|
Anche: #2264 |
TheMule71
force-pushed
the
14.0-mig-l10n_it_fatturapa_in
branch
3 times, most recently
from
2a7725d
to
4e253f1
Compare
|
Se si mergia withholding_tax (e reasons) anche i test di fatturapa_in dovrebbero essere verdi:
|
| @@ -998,7 +998,8 @@ def invoiceCreate(self, fatt, fatturapa_attachment, FatturaBody, partner_id): | |||
| invoice.id, FatturaBody.DatiGenerali.DatiGeneraliDocumento | |||
| ) | |||
|
|
|||
| self.set_roundings(FatturaBody, invoice) | |||
| if self.e_invoice_detail_level != "1": | |||
| self.set_roundings(FatturaBody, invoice) | |||
There was a problem hiding this comment.
Questo sarebbe da fare anche su v12?
|
Ho trovato una PR mancante non tracciata: #2000 |
|
Anche #2097 |
Mi sa che di fatto sono due file diversi o quanto meno per test diversi. Di solito parto dall'ultimo test e ne copio il file aumentanto il progressivo, probabilmente ho fatto la stessa cosa in due momenti diversi sui due alberi 12 e 14. Nell'attuale branch per la pr del porting alla 14, è stato introdotto a novembre con 7e9f3de. Si tratta del file usato dal test_45_xml_many_zeros(). Probabilmente copiato da IT05979361218_015.xml e adattato. Nella 12, è stato introdotto con eb67d3f, a febbraio (#2107), ed è il file per il test_46_xml_import(). Nella 12 è praticamente identico a IT05979361218_015.xml, per cui si potrebbe eliminarlo e modificare il test per usare IT05979361218_015.xml. Il backporting del test_45_xml_many_zeros() non è stato fatto (né ha senso farlo) perché è un problema specifico della 14.0 ("baco" di xmlschema/python). L'alternativa è "bumpare" il numero del test sulla 14.0 (che va fatto comunque, perché test_45 sulla 12.0 fa un'altra cosa) e conseguentemente il nome del file (tipo IT05979361218_016.xml -> IT05979361218_017.xml). Cosa di sembra meglio? Rimozione di un file mi pare inutile dalla 12.0 ("liberando" il nome IT05979361218_016.xml) oppure rename del test e del file sulla 14.0? |
Anzi, ripensandoci, io farei così: La PR è il porting di un branch parallelo della 12.0 (xmlschema) datato a novembre. Per es. il file IT05979361218_016.xml non c'era (quindi lo introduce da zero). Immediatamente dopo il merge, si fa il forward porting delle PR sucessive sulla 12.0. Per es., #2000 introduce un test_45, per cui test_45_xml_many_zeros viene rinominato a test_46_xml_many_zeros come parte delle modifiche relative. Quando #2107 verrà portata, (se decidiamo di mantenere il file extra sulla 12) il IT05979361218_016.xml della 14.0 verrà rinominato IT05979361218_017.xml come parte delle modifiche relative al porting (e test_46_xml_many_zeros diventa test_47_xml_many_zeros ecc.) In questo modo si ha l'history più pulita possibile. È comunque un principio generale, nel fare il forward port delle modifiche queste cose succedono sempre, potenzialmente. Se una PR sulla 14 (e solo su quella) in futuro introdurrà per es. test_50_xxx e poi successivamente una PR sulla 12 (ma per qualcosa che si applica anche alla 14) introdurrà test_50_yyy bisognerà gestire il caso di "collisione". A meno che non decidiamo di far partire i numeri dei test per la sola 14 (da non backportare) da test_140 in su. In tal caso rinominiamo subito test_45_xml_many_zeros in test_140_xml_many_zeros e ce lo togliamo di torno anche per il futuro. Quello si può fare prima del merge oppure come prima modifica dopo (non cambia nulla). |
|
Congratulations, your PR was merged at 30d6e67. Thanks a lot for contributing to OCA. ❤️ |
Migrazione dalla 12.0 alla 14.0
DA COMPLETARE
--
Confermo di aver firmato il CLA https://odoo-community.org/page/cla e di aver letto le linee guida su https://odoo-community.org/page/contributing