When importing an invoice without specifying the type, the invoice type
is set to `out_invoice`, but the account set is the supplier account.
At this point, the invoice type is simply undefined (`False`). It will
be set by default at creation to `out_invoice`. Therefore, we reach the
`else` condition which uses the supplier info.
We simply inverse the condition, so it creates a consistent object.
However, it raises a bigger question about how the action context should
be kept at invoice. We won't address it :-)
opw-1925547
closesodoo/odoo#30154
The aged reports were wrongly taking the previous day of the requested date to compute the different report periods.
E.g: An aged balance requested for the 31-12-2018 was excluding entries made on the that exact date and was starting from the 30-12-2018
closesodoo/odoo#30195
When selection an invoice in the view list and send it from the
"action > send" button, the checkbox for the print option is
not checked according to the configuration.
This fix remove the context that was forcing the print checkbox on
false.
opw-1927126
closesodoo/odoo#30175
Make an expense report containing 2 expenses
one of them has tax exigible on payment
Validate the whole thing and make a payment
Before this commit, the journal entries were wrong
this was because:
- there were 2 move lines in the payable account
Each of them wanting to reconcile with the payment, and each of them trying
to create an cash basis entry
- the amounts were incorrect too, as the matched percentage was computed
on move lines that were not in a payable/receivable, but in taxes accounts
OPW 1912247
closesodoo/odoo#29878
opw-1922531
Before this commit, the product's description for customers was not translated in the
invoice.
Now, the product's description for customers is translated in the invoice.
closesodoo/odoo#30107
utils.round_precision() is expecting a float as precision (0.01) whereas utils.round_decimals() is expecting the number of digits to consider after the coma (2).
The previous code was totally wrong in that regard, which led to reconciliation wrongly considered as total in foreign currency, as long as the amount_currency difference was lower than the currency precision digits.
closesodoo/odoo#30091
opw-1917605
Before this commit, when accounting is set to global rounding, the base
amount per tax is not correctly calculated.
Now, the Base amount per tax is calculated adding the rounded lines.
To test this issue, you need to set to global rounding and create a
customer invoice with the following lines :
line 1 = Qty:40; unit price:2.27; tax:15%; discount: 10%
line 2 = Qty:21; unit price:2.77; tax:15%; discount: 10%
line 3 = Qty:21; unit price:2.77; tax:15%; discount: 10%
When the invoce is printed, you would notice that the amount is 186.43
and it should be 186.42.
closesodoo/odoo#30021
Before this commit, when the fiscal year was setting to 29/02.
The function that compute the fiscal year dates gives an error.
This occurs when the date passed as parameter wasn't a leap year.
Now, for the non leap years we use the 28/02.
opw-1917035
closesodoo/odoo#29932
When creating a new line on a customer invoice, we could get the price
unit in the company currency instead of the invoice currency.
This is because the uom_id onchange would ignore currency when setting
the price.
Changing an invoice line's price unit on uom_id change was introduced
in february 2018 in saas-11.3 with 3a38080ff.
Change to how currency is applied when setting an invoice line's price
unit was introduced in june 2018 in 9.0 with 367fadc8.
So there was a missing part in saas-11.3 to adapt 367fadc8 for 3a38080ff
change that is added with this commit.
Without the fix, the added test failed with:
AssertionError: 10.0 != 20
opw-1920504
closes#29776
Create a paiement, post it, cancel it, set it to draft, post it again:
The move_name has been incremented instead of staying the same as before.
-opw: 1919241
Search bank account without partner to handle the case the res.partner.bank already exists but is set
on a different partner. Without this commit, the error 'An account with the same number already exists'
was raised.
- When installing an accounting l10n module, the method `try_loading_for_current_company`
is called and could cause a deadlock.
The deadlock is caused by the fact that if the installation is started
via a web request the code tries to retrieve the current user's
company by doing `request.env.user.company_id`.
This causes issues since the installation code has its own postgresql
cursor while calling `request.env.user.company_id` will create its own
cursor.
So two cursors exists for the same Odoo worker.
The installation cursor asks for a lock on `res_users` while the
second cursor (the request one) will try to read on `res_users` and
wait the first lock to be dropped.
The lock is never dropped since the python code isn't running anymore
waiting for the `request.env.user.company_id` to be completed.
Causing the deadlock.
To fix the issue, we avoid the creation/usage of a cursor created by
`requesŧ`.
So to retrieve the current user's company, we read the user id on the
request's session, then browse the `res.user` record with the
installation cusror.
Fix issue introduced by commit d40956c790closesodoo/odoo#29927
Create a vendor payment of 100€
Create a bank statement line with an amount lower than the payment
Open bank reconciliation view
Reconcile the bank statement line with the blue line of 100€, the triangle for partial reconcile appear.
Current behavior:
If you click the triangle, you can reconcile this payment with the statement line but it becomes unbalanced.
Expected behavior:
The triangle should not appear.
Fixes odoo#29654
closesodoo/odoo#29718
Backport of commit 771f65ecf5
Payments created without partner_type (field not required)
were previously not shown anywhere, as well as internal transfers.
opw 1910590
closesodoo/odoo#29647
* = account, sale_management, website
Settings that are using groups internally should not appear on the user form
without using debug mode.
The admin should not get the idea that he should configure those per user,
because they are going to be reset if/when changing the general setting.
closes#29842
PR: #29860
Suppose calling get_fiscal_year(date, day=29, month=2) with date(year=2017, month=2, day=28)
The computation steps are:
date_from = date(year=2017, month=2, day=28) - 1 year = date(year=2016, month=2, day=28)
date_from = date_from + 1 day = date(year=2016, month=2, day=29)
It's incorrect because the value of date_from must be date(year=2016, month=3, day=1)
closesodoo/odoo#29416
- Install a second language, e.g. French
- Set Parter A language to French
- Create an invoice for A with a date due in the past
- On the partner form view, print the 'Due Payments'
The body of the letter is not translated in French.
Something quite weird appears:
- The corresponding string is exported in the `stock` module
- It is linked to the demo data `stock.res_company_1`, which corresponds
to 'My Company, Chicago'.
Therefore, the translation cannot be found by the corresponding query
generated in `_generate_translated_field` and `_read_from_database`:
```
SELECT "res_company"."id" as "id",COALESCE("res_company__overdue_msg"."value", "res_company"."overdue_msg") as "overdue_msg" FROM "res_company" LEFT JOIN
(SELECT DISTINCT ON (res_id) res_id, value
FROM "ir_translation"
WHERE name='res.company,overdue_msg' AND lang='fr_BE' AND value!=''
ORDER BY res_id, id DESC)
as "res_company__overdue_msg" ON ("res_company"."id" = "res_company__overdue_msg"."res_id")
WHERE "res_company".id = 1 ORDER BY "res_company"."sequence" ,"res_company"."name"
```
Indeed, `res_company.id` is 1, while `res_company__overdue_msg.res_id`
is 3.
The root cause has been solved in v11, to we only export the necessary
term.
opw-1908337
closesodoo/odoo#29525
used to fetch debit & credit recorded in Tax Cash Basis Journal Entries
Main
-
By allowing to change the `amount_mnt` var we will be able to change the
values recorded in Tax Cash Basis Journal Entries, i.e, debit & credit
values.
Explanation
-
We want to keep the `amount` just the way it has been computed because
that is right. We don't want to change that.
Our issue is the`rounded_amt` which is the value that is passed to the
debit and credit downwards.
We have only hooked a new method to allow us later inherit that method
and make our own computations regarding the `rounded_amt` which is the
main subject of this PR and later pass it down to the debit & credit
fields as need for localizations that could be facing the problem of
having the computation of taxes at date of invoicing instead of date of
payment.
`amount` var is used here:
`
'amount_currency': self.amount_currency and
line.currency_id.round(-line.amount_currency * amount / line.balance) or
0.0,`
and we are not intending to change that because the value written to the
`amount_currency` field is right.
What we intend is to compute the values for debit and credit fields
which were computed in this method at invoice date, some l18n need them
at payment date, e.g, l18n_mx.
Be aware
-
Do not be mislead by the fact that `rounded_amt` var is the one taken to
do those computations. It is just a mean to the final goal. Rounding is
not an issue and has never been.
Background
-
By allowing this merge to flow we will be able to address the following issues:
https://github.com/odoo/odoo/issues/25057https://github.com/odoo/odoo/pull/17196https://github.com/odoo/odoo/issues/9972
Final Goal
-
Being able to perform the computation of the debits and credits
according to l10n_mx in odoo/enterprise#3137closesodoo/odoo#28991
The "customer invoice" and "vendor bill" string was untranslated.
Instead of adding a _ call, properly translate it.
No need to try saving bytes by splitting the sentences, this makes it very
difficult to translate in some languages where the order of words are not the
same as English
closesodoo/odoo#29690
Nicolas Martinelli