Conversation
7f73e83 to
131b279
Compare
DantePereyra
left a comment
There was a problem hiding this comment.
Tested on local environment and works perfect! Only minor comment.
d4ca0ae to
71b5164
Compare
71b5164 to
c50b776
Compare
|
This PR has the |
11c6440 to
243b4ef
Compare
|
@hildickethan We have detected a problem with the discount calculation; when setting certain discounts and then changing the "discounting_type" field from "multiplicative" to "additive", the discount is not recalculated. |
I think the additive type is a bit abandoned right now since no one seems to actually use it anymore, talked about more in depth in #3649. That issue proposes just hiding it for now which I think is done in the 18.0 PR so I will probably copy that if a simple change doesn't fix the issue |
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate. Translation: sale-workflow-16.0/sale-workflow-16.0-sale_triple_discount Translate-URL: https://translation.odoo-community.org/projects/sale-workflow-16-0/sale-workflow-16-0-sale_triple_discount/
Currently translated at 100.0% (12 of 12 strings) Translation: sale-workflow-16.0/sale-workflow-16.0-sale_triple_discount Translate-URL: https://translation.odoo-community.org/projects/sale-workflow-16-0/sale-workflow-16-0-sale_triple_discount/es_MX/
Currently translated at 100.0% (12 of 12 strings) Translation: sale-workflow-16.0/sale-workflow-16.0-sale_triple_discount Translate-URL: https://translation.odoo-community.org/projects/sale-workflow-16-0/sale-workflow-16-0-sale_triple_discount/it/
Currently translated at 100.0% (12 of 12 strings) Translation: sale-workflow-16.0/sale-workflow-16.0-sale_triple_discount Translate-URL: https://translation.odoo-community.org/projects/sale-workflow-16-0/sale-workflow-16-0-sale_triple_discount/es/
Currently translated at 100.0% (12 of 12 strings) Translation: sale-workflow-16.0/sale-workflow-16.0-sale_triple_discount Translate-URL: https://translation.odoo-community.org/projects/sale-workflow-16-0/sale-workflow-16-0-sale_triple_discount/it/
Currently translated at 100.0% (12 of 12 strings) Translation: sale-workflow-16.0/sale-workflow-16.0-sale_triple_discount Translate-URL: https://translation.odoo-community.org/projects/sale-workflow-16-0/sale-workflow-16-0-sale_triple_discount/de/
Currently translated at 100.0% (12 of 12 strings) Translation: sale-workflow-16.0/sale-workflow-16.0-sale_triple_discount Translate-URL: https://translation.odoo-community.org/projects/sale-workflow-16-0/sale-workflow-16-0-sale_triple_discount/pt_BR/
Method 'invalidate_cache' is deprecated. To invalidate specific field's value into the cache for a recordset we must use the 'invalidate_recordset' method on the recordset itself.
When computing the amount total on a sale.order.line, we now avoid to play with the cache since this change introduced in OCA@e3e59ba introduces a decline in performance. When the cache in invalidated, fields are flushed to the database and depending computed fields are recomputed..... This ultimately leads to temporary inconsistencies breaking others addons relaying on this one. Moreover, the method used in this original commit 'self.invalidate_cache(fnames=self._discount_fields(), ids=self.ids)' is deprecated and the use of the recommended new one lead to others side effects. The original approach is replaced by a contextual method modifying only the discount field when we need it's needed to don't break code relaying on the fact that the discount field is the total discount to apply to a line. This contextual method ensures that the original value is properly restored on exit and that it will not trigger additional recompute due to the temporary change of the discount value
Currently translated at 16.6% (2 of 12 strings) Translation: sale-workflow-16.0/sale-workflow-16.0-sale_triple_discount Translate-URL: https://translation.odoo-community.org/projects/sale-workflow-16-0/sale-workflow-16-0-sale_triple_discount/fr/
Until now, the triple discount feature did use the standard Odoo field as the first discount field, adding only extra fields for the second and the third discount. This implied we had to override any function using discount to consider the other discounts properly. By adding an extra field discount1 to store the first discount, it allows to redefine the standard discount field to a computed field that will consolidate the triple discount from the other fields, and avoid the need to redefine anything relying on the discount field as it will already consider the triple discounts. Apply rounding on discount Fix computed fields dependencies The issue with actual implementation is that discount is already a computed field in std Odoo (eg to apply discount from pricelist). Therefore, the value computed by Odoo must be stored in another field, (ie discount1) for discount to be used to consolidate the multiple discount. For this, we assign _compute_discount as the compute of discount1 and redefine a new function to compute discount as consolidated from the other discount fields. Manually bump major version to play upgrade script Fix migration script import Fix init discount from pricelist Fix invoicing Add error in case of dependency module version mismatch
…ibles and can not work together by design. similar to account_invoice_fixed_discount and account_invoice_triple_discount
The goal is to keep the sale refactor in line with the invoice one. OCA/account-invoicing#1840 OCA/account-invoicing#2109
243b4ef to
39d0b9d
Compare
thank you chatgpt, at least it did catch one bug that was pretty much impossible to see without messing with the db but a bug nonetheless |
|
@hildickethan Thanks for addressing the review points and for catching the discount calculation bug. The migration looks solid. |

Notably this PR adds the
discount1field compared to the previous migration PR which would require migrating data but it doesn't make sense to include here in code, so you would have to do that manually (like this)