-
-
Notifications
You must be signed in to change notification settings - Fork 693
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
[13.0][MIG] account_invoice_triple_discount #661
[13.0][MIG] account_invoice_triple_discount #661
Conversation
1fa83cd
to
3e7e792
Compare
@bealdav @pedrobaeza @Nikul-Chaudhary Since v13 is a big change in account invoice, so I have to change the calc logic quite a bit. But I tested it have the same result. I think it is ok, but you might want to look? Due to v13 also, I do have difficulty writing test. I have the error here, Because when we change the discount, on screen onchange do not trigger write immediately, and so it works fine. Are there anyway I to imitate onchange in test script properly? (I try with Form, it also not work) |
@kittiu I think I found some bug. Process:
|
3e7e792
to
f542381
Compare
@ps-tubtim thanks for reporting. This is interesting, I found resolution here, |
77d0ff5
to
29cdd46
Compare
Travis failed coz of black. So I did the rebase. |
discount3 = fields.Float("Discount 3 (%)", digits="Discount") | ||
|
||
@api.onchange("discount1", "discount2", "discount3") | ||
def _onchange_triple_discount(self): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should not be a compute function ? otherwise, a self.env["account.move.line"].create({"discount1": 10, "discount2": 20}) will not raise the compute of discount. Don't you think ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you, this is a good comment.
Fixed.
Could you fix travis please? Then we can see the results of the unit tests. EDIT: tests fails when started them locally |
Hi @kittiu, any news about this? |
Sorry, I am back now. :) Will continue. |
Currently translated at 100,0% (4 of 4 strings) Translation: account-invoicing-11.0/account-invoicing-11.0-account_invoice_triple_discount Translate-URL: https://translation.odoo-community.org/projects/account-invoicing-11-0/account-invoicing-11-0-account_invoice_triple_discount/de/
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate. Translation: account-invoicing-12.0/account-invoicing-12.0-account_invoice_triple_discount Translate-URL: https://translation.odoo-community.org/projects/account-invoicing-12-0/account-invoicing-12-0-account_invoice_triple_discount/
Currently translated at 100.0% (4 of 4 strings) Translation: account-invoicing-12.0/account-invoicing-12.0-account_invoice_triple_discount Translate-URL: https://translation.odoo-community.org/projects/account-invoicing-12-0/account-invoicing-12-0-account_invoice_triple_discount/pt_BR/
29cdd46
to
ad37c33
Compare
Done. |
@benwillig @legalsylvain @ps-tubtim ready for review. Thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
functionnal tests and code review, LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure but introducing discount 1 will break all the native feature when invoices are created from sale /purchase order. Dont you think ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure but introducing discount 1 will break all the native feature when invoices are created from sale /purchase order. Dont you think ?
@legalsylvain might be right as we can see here. Don't we simply need to set an inverse function on discount to store the value in discount1? Not sure if we will get an infinite loop here.
what about the previous design ? without |
@legalsylvain If you still insist, I will try again. |
Another though, what if when the original discount has value, and others don't. I will distribute it into discount_1. In other words, I will ensure that, the discount will always equal to discount_1 * discount_2 * discount_3 The new account.move in v13, is much more complex than v12, that is one reason. Another reasons is the code of v12 by itself is much more complex without having discount_1. I still think, this PR is also the improvement. WDYT? |
The problem here is changing |
@benwillig OK. |
@benwillig @legalsylvain I must confess.
I understand this PR also need migration script from v12 to v13, not very elegant PR also. |
I will make further investigations on my side and make a PR if possible. |
As most people agree to move to this approach #733, so I would like to close this for now. @ps-tubtim please help fix OCA/sale-workflow#1138 for this #733 (when it is ready) |
Standard migration
Test error from other modules, awaiting for following merge,