[14.0][MIG] l10n_it_fatturapa_out_triple_discount#2760
Conversation
85306ed to
6f28831
Compare
|
Prova a fare un rebase sulla mia #2753 e poi un push -f |
6f28831 to
7eb8811
Compare
La pr indicata è chiusa. Ho fatto un rebase su |
| </template> | ||
|
|
||
| <template id="account_invoice_line_it_sconto_maggiorazione"> | ||
| <t t-set="importo" t-value="get_importo(line)" /> |
There was a problem hiding this comment.
Non riesco a capire a che serve la modifica.
There was a problem hiding this comment.
Serve a non riscrivere la funzione per il calcolo dello sconto, solo per questo.
| out.update(out_computed) | ||
| return out | ||
|
|
||
| def get_importo(line): |
There was a problem hiding this comment.
Trovo più versatile passare l'intera line piuttosto che i due valori qui. Un sottomodulo potrebbe voler fare l'override dell'importo leggendo valori presi da line. Se passi solo price_unit e discount, altri moduli non ci possono fare molto.
There was a problem hiding this comment.
A me sembra più utile non duplicare il codice per il calcolo dello sconto.
There was a problem hiding this comment.
Beh prima c'era funzione get_importo() che riceveva un parametro, line, adesso riceve due parametri, price_unit e discount, entrambi però presi da line.
È cambiata la signature della funzione, e rende la funzione meno versatile.
Forse sarebbe meglio passare un parametro aggiuntivo, opzionale, che permetta di selezionare quale sconto applicare, mantenendo la compatibilità con la base e altri (eventuali) moduli. Tipo:
def get_importo(line, discount_field="discount"):
str_number = str(line[discount_field])
che permette di mantenere la compatibilità e comunque scegliere lo sconto da applicare, in modo del tutto generale. Un domani un altro modulo potrebbe voler fare dei conti sull'importo usando campi dalla line, o introdurre in altro campo sconto da usare come base tipo discount4 (faccio per dire, non che abbia senso).
There was a problem hiding this comment.
Chiaro ma resto della mia idea; mi da l'impressione di un UCAS. Detto ciò, sentiti libero di modificare la pr.
|
@OCA/local-italy-maintainers come possiamo procedere con questa? |
|
@OCA/local-italy-maintainers potete dare un'occhio anche a questo porting? grazie! |
|
@TheMule71 puoi suggerire come implementeresti la modifica richiesta? che sennò restiamo nell'impasse e non possiamo gestire lo sconto triplo in fattura. Grazie! |
|
@SirTakobi avresti qualche indicazione su come procedere con questa migrazione? |
Me l'ero già segnata grazie, quando ho tempo ci guardo |
SirTakobi
left a comment
There was a problem hiding this comment.
Puoi correggere i test?
Suggerisco anche GSLabIt#2 per risolvere la discussione partita da #2760 (comment).
cc @TheMule71
| # TODO https://github.com/OCA/l10n-italy/issues/1588 | ||
| #from . import test_fatturapa_triple_discount | ||
| # from . import test_fatturapa_triple_discount |
There was a problem hiding this comment.
Puoi verificare se questo problema continua a verificarsi ed eventualmente ripristinare i test?
There was a problem hiding this comment.
@SirTakobi i test continuano a fallire in l10n_it_fatturapa_in e l10n_it_fatturapa_in_purchase, hai qualche suggerimento?
There was a problem hiding this comment.
@SirTakobi i test continuano a fallire in
l10n_it_fatturapa_inel10n_it_fatturapa_in_purchase, hai qualche suggerimento?
Nel commento indicavo i test di l10n_it_fatturapa_out_triple_discount, non quelli di altri moduli.
Comunque, per quanto riguarda i test di l10n_it_fatturapa_in e l10n_it_fatturapa_in_purchase: se lo riproduci in locale, andrei in debug.
Puoi anche provare se OCA/account-invoicing#876 risolve.
1fa35cc to
c372328
Compare
|
/ocabot migration l10n_it_fatturapa_out_triple_discount |
|
per caso ci sono novità su questa pr? |
per il momento no, se volete portarla avanti siamo molto contenti :) |
c372328 to
513a474
Compare
|
Utilizzando la versione 5.12.0 di isort nel file pre-commit non da problemi nei test. |
it fixes: - removes xs:dateTime if bogus and not mandatory i.e. 0001-01-01T00:00:00.000+02:00 where python raises OverflowError - removes timezone from xs:date to make pyxb able to compare with 1-1-1970, it also removes the need of patching pyxb - removes space only strings if not mandatory, else replace with a dash breaking change: modules needs to import binding.fatturapa instead of bindings.fatturapa_v_1_2, this would be asl useful for new specs
…e now rounded to the nearest even result instead of away from zero". See https://docs.python.org/3/whatsnew/3.0.html#builtins Examples: >>> '%.2f' % 75.845 '75.84' >>> '%.2f' % 75.855 '75.86' >>> round(2.5) 2 >>> round(3.5) 4
…scount: modifica del type di Importo in ScontoMaggiorazioneType (OCA#1875) * [IMP] l10n_it_fatturapa_out: change precision_rounding of ScontoMaggiorazioneType according to e-invoicing specs 1.6 * [IMP] l10n_it_fatturapa_out_triple_discount: change precision_rounding of ScontoMaggiorazioneType according to e-invoicing specs 1.6
513a474 to
0c28ad6
Compare
il pre-commit non ha dato errori, ho cmq fatto un rebase. vediamo come vanno |
|
@odooNextev se volete riprendere il lavoro in una nuova PR, siete benvenuti :) |
|
superseeded by #3269 |
#1905