[FIX] account,sale: fix res.partner credit_to_invoice computation #166087
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently there are 2 issues with the function used to compute `credit_to_invoice` on model 'res.partner' (`_compute_credit_to_invoice`): 1) On 17.0 a traceback has been reported. There were instances in which the `amount_to_invoice` was `None` and not `0` (to be looked at in a separate fix). In such a case the `None` value is passed to the `float` function and causes a traceback. 2) From a performance perspective it is unnecessary to aggregate all the `amount_to_invoice` values into an array and then postprocess them in python. Effectively the only thing we do in the postprocess is sum all the values but ignore all non-postive values. Thus we can just ignore sales orders with `amount_to_invoice <= 0` and let the SQL / the database handle the summing. This way we avoid the overhead from passing around the array(s) (size proportional to the number of sales orders) and just pass around a single value. This commit introduces the changes mentioned in (2). These changes also solve (1): The additional condition in the domain leads to sales orders where `amount_to_invoice` is `None` being ignored. (SQL / the DB handles (1) for us now.)
svfu-odoo
referenced
this pull request
May 18, 2024
Currently the amount of the partner credit warning
on invoices is not computed correctly in some cases.
(1) There are Sales Order credits
and we create an invoice independent of any of SO
(2) We create an invoice from a Sales Order with
an amount greater than the Sales Order.
For (1) the problem is that we substract the current
amount of the invoice from the sales order credits
(since we need to do this in the sales order to invoice flow)
But in case the invoice does not come from a sales order
this is wrong.
For (2) the problem is that the `amount_to_invoice` of a
Sales Order may be negative. This can happen if we invoice
more than the sales order amount.
E.g. we can end up with one invoiced order with -100 and
one uninvoiced order of 100. In the sum this would leave us
with "nothing to invoice" (100 + -100 = 0).
Reproduce (1):
All monetary values here are in company currency.
- Ensure that the partner credit is 0:
i.e. remove all Sales Orders and Invoices.
- Activate 'Sales Credit Limit' in the settings
and set the 'Default Credit Limit' to 100
- Create a new customer; here 'Test'
- Create a Sales Order for customer of 200
and deliver it
- The total partner credit is now 200
- Create an Invoice (not from the Sales Order)
for customer 'Test' (without any lines at first).
- There should be a warning that the total amount
due is 200 (since it exceeds the limit of 100).
- Add a line of 200 to the Invoice
(any value ≤ 200 will do).
- The total amount due in the warning is still 200
but it should be 400 (200 + 200)
- Change the line to 800 (any value > 200 will do)
- The total amount due in the warning is now 800
but it should be 1000 (200 + 800)
Reproduce (2):
All monetary values here are in company currency.
- Ensure that the partner credit is 0:
i.e. remove all Sales Orders and Invoices.
- Activate 'Sales Credit Limit' in the settings
and set the 'Default Credit Limit' to 100
- Create a new customer; here 'Test'
- Create 2 Sales Orders for customer of 200 each
and deliver it
- The total partner credit is now 400
- Create an Invoice from exactly one of the Sales Orders
(full amount or downpayment does not matter here)
- There should be a warning that the total amount
due is 400 (since it exceeds the limit of 100).
- Modify the invoice (any line from the sales order)
s.t. it has a total of 400
- Confirm the invoice
- The amount_to_invoice of the Sales Order is now -200.
The sum of the amount_to_invoice of the Sales Orders is 0.
- Create a new invoice without any lines.
- There is a warning that the total amount
due is 400 (= 200 + -200 + 400 ; SO + SO + invoice).
But it should be 600 since the "overinvoiced" SO
should just be counted with amount_to_invoice 0.
closes #164921
closes #164971
X-original-commit: ddc17e6
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Sven Führ (svfu) <svfu@odoo.com>
smetl
approved these changes
May 21, 2024
robodoo
pushed a commit
that referenced
this pull request
May 21, 2024
Currently there are 2 issues with the function used to compute `credit_to_invoice` on model 'res.partner' (`_compute_credit_to_invoice`): 1) On 17.0 a traceback has been reported. There were instances in which the `amount_to_invoice` was `None` and not `0` (to be looked at in a separate fix). In such a case the `None` value is passed to the `float` function and causes a traceback. 2) From a performance perspective it is unnecessary to aggregate all the `amount_to_invoice` values into an array and then postprocess them in python. Effectively the only thing we do in the postprocess is sum all the values but ignore all non-postive values. Thus we can just ignore sales orders with `amount_to_invoice <= 0` and let the SQL / the database handle the summing. This way we avoid the overhead from passing around the array(s) (size proportional to the number of sales orders) and just pass around a single value. This commit introduces the changes mentioned in (2). These changes also solve (1): The additional condition in the domain leads to sales orders where `amount_to_invoice` is `None` being ignored. (SQL / the DB handles (1) for us now.) closes #166087 Signed-off-by: Laurent Smet (las) <las@odoo.com>
This was referenced May 21, 2024
|
Added additional changes in 17.0+ #166236 (comment) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently there are 2 issues with the function used to compute
credit_to_invoiceon model 'res.partner' (_compute_credit_to_invoice): 1) On 17.0 a traceback has been reported.There were instances in which the
amount_to_invoicewasNoneand not0(to be looked at in a separate fix).
In such a case the
Nonevalue is passed to thefloatfunction and causes a traceback.2) From a performance perspective it is unnecessary to aggregate all the
amount_to_invoicevaluesinto an array and then postprocess them in python.
Effectively the only thing we do in the postprocess is sum all the values but ignore all non-postive values.
Thus we can just ignore sales orders with
amount_to_invoice <= 0and let the SQL / the database handle the summing.This way we avoid the overhead from passing around the array(s) (size proportional to the number of sales orders)
and just pass around a single value.
This commit introduces the changes mentioned in (2). These changes also solve (1):
The additional condition in the domain leads to sales orders where
amount_to_invoiceisNonebeing ignored. (SQL / the DB handles (1) for us now.)related PR introducing the changed lines of code: #162770
a comment about the issue in 17.0: b5d02cc#r141990142