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
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
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
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
In case there is a large amount of data to display, the 'Manual
Reconciliation' widget suffers from high CPU consumption, and therefore
slowness.
This is mainly due to the line rendering (function `_renderLines`).
Indeed, unlike the 'Bank Statement Reconciliation' widget which
retrieves the data partially, the 'Manual Reconciliation' widget
retrieves and renders all the data. No offset is implemented in this
case, neither for data retrieval nor rendering.
With this commit, we implement a partial rendering of the data
retrieved. This means that all data are fetched when loading the widget,
but only a part of it is rendered. We make use of the existing 'Load
More' mechanism to display more data. By default, 30 accounts or
partners are loaded.
By combining this with PR #28958, we aim to make the widget more usable
for large data volumes.
opw-1903575
closesodoo/odoo#28959
opw-1916511
When you try to change the accounting plan it sets off an access error.
To change the accounting plan it must delete and create some records in
the model 'ir.property' and none of the current security groups have
access to do it.
This issue was not present in the version 11.0 because in that version
the administrator was also the super-user.
In version 12.0 the administrator and the super-user were dissociated.
This was changed to level-up (sudo) the rights of the administrator
when the ir.property are deleted.
Note that, this fonction have two pre-existing constraints to avoid
issues when configuring an accounting plan: it can only be changed if
there are not alredy existings accounting entries;
and only the administrator can change it.
closesodoo/odoo#29493
Have an invoice and a credit not in one journal
Go on the dashboard for journals
Before this commit, the count of invoices in draft took into account
both invoices and credit notes, while clicking on the button to see the invoices/credit notes
only showed invoices
After this commit, clicking on the button show both invoices and credit notes
It is worth noting that this is the behavior in v11.0
And that the way the dashboard is computed cannot allow to differentiate
within the kanban records, invoices and refunds as two separate buttons
OPW 1916135
closesodoo/odoo#29482
Create a "Cash Rounding Method" C with
Rounding Precision: 0.05,
Rounding Strategy: Modify tax amount,
Rounding Method: DOWN.
Create an invoice I with rounding of currency C, with some tax line and nonzero
rounding.
When you now print the invoice, the tax amount is not the same,
as it shows the field "amount" instead of "amount_total".
Fix courtesy of Olivier Jossen, Braintec
opw 1909215
closesodoo/odoo#29079
When the method _toggle_reconcile_to_false was called on an empty recordset (e.g existing account is imported with reconcile=False and the field was already False), an SQL error was raised.
Fixes#29326closesodoo/odoo#29458
- When installing account using a request (e.g. http route auth set to `None`) not bound to a database,
the installation fails.
To avoid this, we check if the request we are using is bound to a
database, if not, the fallback code is executed.
The reference is not copied to the invoice move because the invoice needs the move to get the
right number and then, we need the invoice number to compute the reference.
So, this commit is required to copy the reference to the move after the invoice validation.
/!\ DO NOT FORWARD-PORT!
This behavior has been already fixed in 12.1 but with too much refactoring for a stable branch.
closesodoo/odoo#29391
1. Create odoo instance with "--without-demo=ALL" option.
2. Install Accounting module.
3. Add Chart of Accounts manually (e.g. code 111111 Bank and Cash and 222222 Other Income)
4. Create Journal.
5. Create Journal Entries.
6. Activate multi-company.
7. Set new company to current user and set the new company as current company.
8. Install accounting localization: Accounting >> Configuration >> Settings >> Install More Packages >> (install any localization module)
Before this commit, there was an error because when installing any module,
the environment in which it happens is in uid = 1 and doesn't have a context anymore
Thus, when arriving in the charts of accounts code, the env's user is still 1
Which doesn't mean anything in V12, since it is the system user
After this commit, the user is retrieved from the request
OPW 1911677
closesodoo/odoo#29310
Suppose a statement line having 'SO022' as name.
Suppose a move having 'INV/2018/0001' as name and 'INV/2018/0001 SO022' as ref.
The previous behavior didn't work because '20180001 022' = ANY({'022'}) was False.
This commit changes the matching by computing the array in both size and checking the intersection.
{'20180001', '022'} && {'022'} is True
closesodoo/odoo#29299
When trying to reconcile the following line with the manual reconciliation widget
(company currency in EUR)
Debit Credit Amount_currency Date Currency
13.11 0 0 10/26/2018 /
0 34.16 -39 11/09/2018 USD
And a write off with the following value:
Debit: 21.05
The write-off created was not with the correct debit and the entries were not totally reconciled.
The reason being that the method was converting the 21.05 with the USD rate of today and changed the debit.
We should never convert debit/credit as debit/credit in the manual reconciliation widget is always displayed in company currency. However if all entries are with the same currency, the writeoff should also have that currency set.
This commit fixes this behavior.
Joining on a case is far to be optimal. doing 3 left joins and a coalesce is faster.
partner_id is a required field in res.partner.bank, but some migrated database have
records in res.partner.bank model without id. To keep existing behaviour, the third
join (the one on the name) is kept for backward compatibility.
closesodoo/odoo#29276
Take explanation of
commit d94e8a0
but this time, have a suffix with a flavor of %(year)s
Before this commit, validating the invoice crashes
After this commit it doesn't.
OPW 1912954
closesodoo/odoo#29160
Fix Error:
`ERROR: syntax error at or near ")"
LINE 7: ... WHERE full_reconcile_id IS NULL and account_id IN ()`
This can occurs when:
- using write to some account like:
`some_account.write({'reconcile': True})`
closesodoo/odoo#29164
When importing a bank statement, we need to prevent the case that an inconsistent
currency_id is set on statement line (= statement currency).
E.g. Your company is EUR, your journal is EUR, your statement is imported with a csv having
currency_id = EUR.
The amount currency will be used in the reconciliation widget instead of the
amount. Furthermore, if you are not in the multi-currency group, the currency_id is invisible and
then, it becomes difficult to understand the reconciliation propositions in the widget.
-task: 1909317
- Suppose a bank statement line with partner_name = x and partner = None.
- Create a reconciliation model with write-off suggestion and auto-validate = True.
- Open the reconciliation Widget.
- Check the lines created automatically: The partner_id is missing.
- Suppose a bank statement line with partner_name = x.
- Create a partner with name = x.
- Open the reconciliation widget: The partner is set by default thanks to this commit.
- Import 2 bank statement lines having acc_number set but no res.partner.bank having this account
number.
- Reconcile the first one with a line: a res.partner.bank is created.
- Reconcile the second one with a line: UserError('Account number must be unique!')
As the journal is mostly set in the Odoo world the _default_journal
method is not needed during create, but in case you only have
partner_id, account_id and type in vals you will have retrieved a wrong
journal in case you have an incoming invoice.
closesodoo/odoo#28635
Nicolas Martinelli