Before that, when reversing an account.move, if two lines of the move shared the same account, we tried reconciling them once for each line: it worked the first time but triggered an error message the second, since the lines had already been reconciled.
Before that, taxes were only applied with the most recent currency rate, which caused problems in multi currencies, when reconciling statement lines made in the past with invoices, causing the amount currencies in the payment account.move to be wrong.
//Scenario to reproduce the issue (from customer ticket 1903497):
(for a company with USD as base currency)
1. Create a new bank journal for EUR payments
2. Create a new customer invoice for 90€
3. Create a new tax for the reconciliation model, price-included and amounting to 15%
4. Create a new reconciliation model using this tax
5. Use the currency rates from the demo data, add one that is closer to current date than the most recent one.
6. Create a new bank statement for the created EUR bank journal. Make sure that the transaction is less than the actual amount due on the invoice so that we can apply the reconciliation model. Also make sure to set a date on the transaction that lies in the past at some point when the currency rate was (significantly) different.
7. Hit the reconcile button, select the amount due from the invoice and apply the discount reconciliation model(take note of the amount on the created tax move line). Now reconcile.
What is the current behavior that you observe?
Now go back to the bank statement and check the created journal entries. You will see a difference in the amount currency values of the payment and the tax account move line. This difference should not exist.
- Activate multi-currency
- Create an Journal Entry manually
- Create a line
Do not fill Account
Fill in Amount Currency
Fill in Currency
A traceback occurs because `line.company_currency_id`.
An extra condition `and line.company_currency_id` is not sufficient to
have the onchange working properly. Indeed, the related field
`company_currency_id` goes through another related field (`company_id`),
leading to an empty value in some cases.
opw-1904854
closesodoo/odoo#28389
Steps to reproduce the bug:
- Create a credit note for an amount of 100$
- Validate it and register a payment
- Let's pay an amount of 90$ and mark this credit note as fully paid
Bug:
An error message was raised saying: Wrong credit or debit value in accounting entry !
The field residual_company_signed must be positive for out_invoice and in_refund and
negative for in_invoice and out_refund. In this way, the correct writeoff amount
can be computed in function _create_payment_entry.
PS: In function _compute_payment_amount, the field residual_signed and residual_company_signed
are already signed, that's why it was wrong to multiply a second time on it with MAP_INVOICE_TYPE_PAYMENT_SIGN
opw:1893570
closesodoo/odoo#28148
Until v12, doing this is wrong. The currency_id field of account.journal should only be used if the journal is in a different currency. Otherwise, this field should stay empty.
//NOTE FOR FORWARD-PORT: this commit should not be ported to 12.0 and further.
Steps to reproduce the bug:
- Create a customer invoice I with an amount of 100$ and validate it
- Register three payments P1 at 11/10, P2 at 12/10 and P3 at 13/10
- Click on button "Print" and the report displays the payments in the right order
P3, P2, P1
- Click on button "Send by email" and click on the attachment with the report
Bug:
The report didn't display the payments in the same order, it displayed P1, P2, P3
opw:1888251
closesodoo/odoo#27895
Ensure the write method in account.journal is working with multiple records.
The for loop indicates it was the intention to be used on several records but
self was still used instead of journal
Some methods like _update_mail_alias work with an ensure_one
closesodoo/odoo#28246
Before this commit:
* Enable UOMs
* Create a new invoice and invoice line
* Set *only* the uom field of the invoice line
* Singleton expected error
This happens because the method _compute_price of `uom.uom` expects a
singleton, however since no product has been defined yet, it gets an
empty recordset which of course doesn't comply with self.ensure_one(),
raising a Singleton Error.
Functionally speaking, it makes sense to define a product before
choosing an uom, however a Singleton Error is an unexpected error, so
instead of doing that, we only calculate the price_unit if a product has
been chosen.
Fixes#28269closesodoo/odoo#28278
Set a suffix on the sequence that will determines an invoice's move's name
Validate an invoice
Before this commit, there was a traceback because the regex that matches the invoice number
did not match anything due to the suffix
After this commit, it works as expected
OPW 1903326
closesodoo/odoo#28241
Design: remove empty space in the dialog form.
Opening date:
-fix move line not created introduced by c4b9c51abf. This prevented saving the opening date;
-set default date to start of current year.
Add a validation on fiscal year last day:
-the automatic calculation was removed in 90cdc91638 but no validation was set;
-the help message became irrelevant;
-the fiscal year end date was set as readonly in 52a8ed3c0c and not fixed in 3f4f77fd9d.
Nicolas Martinelli