92c40caccdba5a08815fb24ab467bce971553053
Make an invoice in Foreign
Make a refund in Foreign
reconcile the two, partially
Make a payment in domestic, partial also, but with writeoff
Before this commit,
The invoice was not fully reconciled and -0.02 was yet to pay on it
Notice the negativity of that number, which actually means that it HAS been
fully reconciled !!!! (there is too much payment compared to invoiced)
This was because, the account.payment in domestic currency is doing:
Invoice residual in foreign, converted to domestic
Then that amount minus payment's amount gives write off amount in domestic
Then, at reconciliation, the whole payment's amount, which is
the payment + the writeoff contained the expected and mathematically
correct conversion and currency rounding errors
(which should make out the exchange difference)
The exchange difference IS created, and rightfully too
that is, it records the exchange difference as debit 0.01 in the receivable !
What was tricky though, is that the partial line recorded the debit 0.01 receivable
as its CREDIT move line !
After this commit, the receivable line is recorded as the DEBIT move line of
the partial between the payment and the invoice
so the invoice, is fully paid.
We keenly admit this is hackish, but justified:
- business-wise: the rounding/exchange errors are appearing ex-post
to the choice of the amount of the reconciliation between the payment
and the invoice, because we are reconciling them on the domestic amount
- technically: our hands are tied because some key information is not present
every time, and weirdly, not symmetrically. That is, the computation of
line.amount_residual[currency] may be different if your are on a line with a currency,
or on a line that doesn't.
We should really think of systematically putting the currency on the line
whichever it is ! The same goes for partial reconciliation model !
Touching the current behavior is out of the question.
Moreover, we should take into account that comparing amounts at different
points in time should be done by actualizing those amounts to a common date
See #39117 for details
OPW 2057845
X-original-commit: 40db7a8
Note that the tests did not change in spirit, but the writing
of the exchange difference may vary from happened in v11.0
Indeed a quite big refactoring has been done in between
The tests reflect this
closes odoo/odoo#39727
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
…
…
…
Odoo
Odoo is a suite of web based open source business apps.
The main Odoo Apps include an Open Source CRM, Website Builder, eCommerce, Warehouse Management, Project Management, Billing & Accounting, Point of Sale, Human Resources, Marketing, Manufacturing, Purchase Management, ...
Odoo Apps can be used as stand-alone applications, but they also integrate seamlessly so you get a full-featured Open Source ERP when you install several Apps.
Getting started with Odoo
For a standard installation please follow the Setup instructions from the documentation.
Then follow the developer tutorials
Languages
Python
49.6%
JavaScript
47.8%
SCSS
2%
CSS
0.3%
HTML
0.2%