All taxes change in Luxembourg, we added a script that will create or update taxes so the clients don't have to
manually update everything or ask the support to do it for them. We don't modify custom taxes.
closes odoo/odoo#108699
Task: 3098941
Related: #104833
X-original-commit: c44a33d67065e20c4ded2a229d0663191c91a0a0
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Claire Bretton <clbr@odoo.com>
To Reproduce
============
- enable QR code on Accounting settings
- with a vendor who has a bank account create an invoice from him/her
- print or preview the credit note
The Problem
===========
the qr code method field will not be filled with SEPA, and a QR code will not be added to the PDF or preview.
This qr reflects the vendor's bank account, so the user could scan it and send the money.
This feature was removed by PR #104496 because it was also printed in the refunds to the customers, which was odd, but as a side effect it is also removed from vendor bills.
Solution
========
The QR should not be hidden in vendor bills and purchase receipts, ( also in vendor refund it can be helpful for the vendor, but there isn't any complain about it now )
A better solution would be displaying the QR code in the form view if it is not the company's bank account (it is the partner's bank account), but it should be done in master, it is too much of change for stable versions.
Ticket No: 3071310
closesodoo/odoo#108612Closes: #108215
X-original-commit: 1b60e21c3636fffba55312525d86da5b1f14948f
Signed-off-by: Pouya Malekinejad (poma) <poma@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce:
1. Activate the hash mode on a journal
2. Create an account move
3. Choose a customer who is not a commercial partner (e.g. Brandon Freeman from Azure Interior)
4. Post the move
5. Error saying that we cannot modify the `partner_id` because the move has already been posted
This is because currently we first post the move and then we modify the `partner_id` of the lines whose `partner_id` is different from the account's `commercial_partner_id`. We can easily fix this by posting the move after the lines'`partner_id` have been modified.
closesodoo/odoo#108177
X-original-commit: 1036134a2f0d921fd6a659b4951e5fa63975b78d
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Ricardo Gomes Rodrigues (rigr) <rigr@odoo.com>
Issue:
- clicking on various account field gives traceback because
of invalid domain.
Cause:
- https://github.com/odoo/odoo/pull/105131 PR remove a leaf
from account domain but forgot to remove '&' operator.
Fix:
- removes '&' operator from account domain.
task-3099758
closesodoo/odoo#107914
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Removed annoying error raised onchange of the date/name if they don't match anymore. This was done during the update, which was dumb since it was popping in case you wanted to change both the date and the name. It now only relies on the constraint that is verified upon posting the invoice. Onchange warning is kept only for the format change.
Ensure the date constraint is always verified no matter if the invoice was already posted before, or if we're in quick edit mode: the date's info located in the name must always match the accounting date. This is ensured when posted.
task-2976499
closesodoo/odoo#108116
Forward-port-of: odoo/odoo#107867
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce:
1. Create a new tax (TAX1) with a lower sequence than VAT(15%).
2. Check Affect Base of subsequent taxes.
3. Create an invoice, add a line with a product and both taxes.
4. Remove the invoice line.
5. Check Journal Items tab: a VAT line is still there with an amount
Bug:
When we create an invoice line with (affecting + affected) taxes,
4 Journal items are created, including the affecting tax line
having the affected tax as tax id.
When we remove the invoice line, the system sync the dynamic lines,
recomputing all the taxes to check what to create/write/delete
As one of the tax entries has a tax it will be left as a needed line
while it should be removed.
FIX:
avoid computing `_compute_all_tax` for tax lines
closesodoo/odoo#108048
X-original-commit: 4fbd639965107fc9363dddb553a70461cd596c0c
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
*: base, account, crm, hr, hr_attendance, test_access_rights
The various public methods of the ORM can be override in other models,
those overrides sometime don't implement the exact same signature as the
original method in the ORM. In this work we sanitize all the overrides
to ensure a better compatibility. The background objective is to make it
possible to call any public method using kwarg: `search(domain=[...])`.
* `search`, the first parameter was renamed from `args` to `domain` in
0e9adf7 but the overrides were not updated.
* `invalidate_models` and `invalidate_recordset`, a new `flush=True`
parameter was introduced in 9c3b9a4 but the overrides were not
updated.
* `update`, there is a clash between the `update` method responsible for
writing on a record and `update` in bus responsible to update the user
presence. The bus method has been renamed so it doesn't clash with the
ORM.
This sanitization comes with a new linter that verifies that all
overrides of BaseModel public methods share a compatible signature. The
linter has been disabled for `create`, `write` and `default_get` as too
many overrides don't respect the signature of BaseModel.
closesodoo/odoo#106999
Related: odoo/enterprise#34991
Signed-off-by: Julien Castiaux <juc@odoo.com>
This commit aims at:
1. Fixing a bug where the invoice would be uploaded in the wrong journal
------------------------------------------------------------------------
To reproduce:
- Go to Customer invoices
- Upload an invoice (with an embedded FacturX)
- The journal is set to Vendor Bill
2. Letting the FacturX move type override the user-chosen move type
-------------------------------------------------------------------
Currently, if the user uploads a credit note in a customer invoice journal,
the document is not created and set to the OCR. This is due to a restrictive check
which has been removed. Therefore, when the move type is defined in the FacturX XML,
we will use it to override the user choice so that the document is always created
within the right journal.
3. Harmonizing the invoice upload between the Accounting and the Documents apps and avoid code duplication
----------------------------------------------------------------------------------------------------------
Currently, the flow of uploading an invoice from the Accounting app and the Documents app is different.
Indeed, if one uploads an invoice in the Document app and click on the "Create invoice",
the document is sent directly to the OCR. Now, instead, we will pass this document to the same upload method
of the Accounting (which will try to create the invoice from the FacturX XML if present).
Therefore, the flow will now be the same from the two apps for better harmonization.
4. Adding a 4th button in the Documents app to create a Vendor refund
---------------------------------------------------------------------
Currently, there are 3 buttons to create a customer invoice, a credit note, a vendor bill, but no vendor refund.
This is due to a duplicate xmlid which has now been fixed allowing the 4th button to be seen in the UI.
5. Adding a button "Switch into customer invoice/vendor bill" button in the account.move's form view
----------------------------------------------------------------------------------------------------
Currently, the user has access to a "Switch into credit note/refund" but not the reverse button to
go from a credit note/refund to an invoice/bill. This is now the case.
Task id 2961932
closesodoo/odoo#103427
Related: odoo/enterprise#32890
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit the canceled lines would not filter out from checks for completeness
of the statements and also the corrections in split wizard consider canceled lines as
real values. One of the results of this is when the user import statements with some
duplicate lines, the duplicates are canceled but the statement stays complete regardless
of the missing lines.
Also fixes the line date is not auto-filled when creating lines in the list view if they don't have a state
Closes PR #105708closesodoo/odoo#107894
X-original-commit: 2422b2c619209c1ff4171902dd2f90824194366d
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Pouya Malekinejad (poma) <poma@odoo.com>
Many country-specific fields were displayed while a company with another country was selected (in case of a multi-company environment).
These country-specific fields are now visible only if one of the selected companies with said country is selected.
closesodoo/odoo#106221
Related: odoo/enterprise#34226
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Changing the bank account on the bank journal led
to a traceback (expected singleton on currency_id)
when trying to open the reconciliation widget.
This is because we are trying to open a blank line
as the origin line was linked to the origin Bank account,
therefore there is no currency_id.
It has been decided to filter the statement line that
match the bank account and to adapt the action button.
Steps to reproduce:
- Create a bank statement line
- In Bank journal, change the Bank Account
- From Accounting Dashboard, click on "Reconcile X items" or
just open the Bank Journal
-> Traceback (expected singleton)
opw-3085670
closesodoo/odoo#107441
X-original-commit: c566a48c5bc528a140e6f29399ca1fbcede60490
Related: odoo/enterprise#34762
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
Improved the tooltip description of the 'Detect automatically' field for fiscal positions. The previous tooltip was "Apply automatically this fiscal position" while the new one is "Apply tax & account mappings on invoices automatically if the matching criterias (VAT/Country) are met."
task id : 3088331
PR number : #107092
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
// CASE 1: payment with different rate
1) Setup a company in USD, with EUR activated as well
2) Set a rate of 1 EUR = 2 USD for date A, and 1 EUR = 3 USD for date B
3) Setup a Cash basis tax of 1/3, with a non-reconcilable cash basis transition account
4) At date A, create an invoice with just one line with base amount=99.99 EUR ; and using the tax setup in point 3).
5) Register a full payment for this invoice at date B
===> The exchange move created by the full reconciliation consists of cash basis rounding lines for the CABA base received, transition account and tax account. 99.99 USD for the base, and 33.33 USD for the tax. Those are introduced to bring back the total amount in domestic currency to the domestic amounts computed for the invoice at date A.
Impacting the tax account and base received account is totally wrong. When doing cash basis, we want to use the rate of the payment in the amounts that get reported, as it corresponds to the money that actually came in. So, none of the lines impacting those accounts should be there.
Only the line impacting the cash basis transition account is useful, to bring its value back to 0. But it actually corresponds to an exchange difference, and we need to balance it with an exchange gain/loss account. This account can already be set as reconcilable, and if so, will be auto-reconciled. We now choose to only rely on that behavior. The account will not be brought to 0 in domestic currency if it's not reoncilable. If it is, it will create a regular exchange difference entry to handle this case properly.
// CASE 2: multiple payments in foreign currency, at different rates
1) Setup a company in USD, with EUR activated as well
2) Set a rate of 1 EUR = 3 USD for date A, and 1 EUR = 2 USD for date B and 5 EUR = 1 USD for date C
3) Setup a Cash basis tax of 1/3, with a non-reconcilable cash basis transition account
4) At date A, create an invoice with just one line with base amount=99.99 EUR ; and using the tax setup in point 3).
5) Pay 66.66 EUR at date B
6) Make a second payment of 66.66 EUR at date C
===> The problem in this case is that the tax and base amounts in foreign currency (33.33 and 99.99 EUR) will need to be divided by 2 (because we're making 2 payments, hence 2 cash basis entries), and the currency rounding will round these values to 50.0 for the base (instead of 49.995) and 16.67 (instead of 16,665) for the tax. Summing the cash basis moves will hence give a total base of 100, and tax of 33,34, which is wrong.
To handle this, a cash basis rounding of 0.01 EUR needs to be done in the exchange difference entry. The corresponding amount in domestic currency must be computed using the rate of the most recent payment, so it will be 0.05 USD here.
Before this commit, this case behaved as the first one, and brought back the reported amount to the rate of the invoice. Moreover, since it never adjusted the amount in foreign currency, the transition account could not be fully reconciled.
// FIX
To handle both those cases, we now split the behavior of the CABA adjustment:
- For rounding errors: we now check the foreign currency amount, and adjust it if necessary, reusing the rate of the most recent payment. If there is no foreign currency, the adjustement is still done for domestic currency, of course.
- Exchange rate difference of the transition account is not handled there anymore: to do this, the transition account must be reconcilable. In case of rounding error to compensate for, the adjustment line added in the exchange difference entry will be reconciled with the one on the CABA entries and on the invoice, to reach full reconciliation.
In case a transition account is not reconcilable, we only create rounding adjustments, no exchange difference.
closesodoo/odoo#107334
X-original-commit: 01cb7e960f912c4758d30c04653b599937785799
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
When filling a Sales Order applicability rule line, the financial
account prefix is useless, as it will not be used.
Thus we can make it invisible in the case of business_domain corresponding to sales and purchases.
task-3040927
closesodoo/odoo#105014
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
A move in draft created with an account that is later deprecated can
still be posted, while it shouldn't be allowed.
Thus, we add a new error blocking this wrong behaviour.
Task id #3087763closesodoo/odoo#107354
X-original-commit: d8c2ad469299349e5184bc8986183cb205beb16a
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Just change double the by single. This fixes various typos in error and
code comments.
closesodoo/odoo#107266
X-original-commit: 09dfedfc19c2bc34c2bb394dcc4bc609c5ac0107
Related: odoo/enterprise#34681
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, the default value for `filter_hierarchy`
was set to `never`. So each report had to explicitly set the value
to `by_default` or `optional` in order to make it available.
Instead, we should use the `optional` value by default and let
reports that do not want it explicitly set it to `never`.
task-3041037
closesodoo/odoo#107263
X-original-commit: a1147d91729a5eb75565f04ec10b52ed28d93c42
Related: odoo/enterprise#34675
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
In order to make this modules to also match new module l10n_latam_check.
* refactory of some methods to make it more heritable
* check number now is showed only when is defined and is related to
check_printing payment method.
X-original-commit: 9394903813947cd4bfbad87f077cdf67233907d8
Part-of: odoo/odoo#107163
* = {account, sale, purchase, hr_expense}
When a plan is mandatory for SOL, POL or expenses, the flow should still be blocked when pressing the button, and not only when creating analytic lines.
We add the info in the context of the button, so automatic flows are still not blocked.
When the applicability rule requires a mandatory analytic distribution, raise an error upon :
- confirming PO,
- sending or confirming SO
- approving Expense Report by manager.
t-3040929
closesodoo/odoo#107166
X-original-commit: 8623a7850288828759db125b1054b0fed6b6b135
Signed-off-by: William André (wan) <wan@odoo.com>
If an aml has no product, it should not trigger a model that has a product.
So, we now define the fields that have to be checked on the model, instead of just being the ones given as parameters.
The way the field `company_id` impacts the model has also been changed.
The idea is that a model with a company specified should be better than a model without one.
But we also want that a model with 1 valid rule and no company is better than one with only a good selected company.
closesodoo/odoo#107165
X-original-commit: feff1a8a056f1fbbc852f7cf164e73abf83c4cc9
Signed-off-by: William André (wan) <wan@odoo.com>
This fixes the performance of the search panel of `account.move.line`
Menu > Accounting > Accounting > Journal Items
The control panel based on the accounts' roots was the issue (call to
`search_panel_select_range`)
Before this fix, the entire table was read through the use of a
`read_group`.
Since the data returned by the `read_group` is not interresting in our
case, we can simply do a lateral join on an indexed column with a limit
in order to improve the performances.
closesodoo/odoo#107164
X-original-commit: 26dd1d9627cdd04e12c3187f0f53c0e11892a345
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Purpose of this commit is to try to make code a bit easier to follow using
dicts, sets and tuples, as well as updating some variable names.
Also rename the method to be clearer. Tools methods may omit the namespacing
to avoid too much confusion in naming.
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#106658
PURPOSE
Purpose of this task is to cleanup attachment management done in generic mail
models overrides and move it in account as model overrides.
SPECIFICATIONS
Accounting holds code to handle attachments linked to their custom composer
(``account.invoice.send``) that uses through inheritance the mail composer
(``mail.compose.message``) that has a specific processing of attachments
to link pending composer attachments to the right records.
Indeed attachments linked to the composer are pending attachments, and are
linked to the record when posting the message. This allows to know which
attachments have been added by the user, have specific rules for access
rights, ...
However this code has been wrongly added directly at mixing level at
odoo/odoo@bdcc012004. Instead ``_message_post_process_attachments`` method
should always be called based on a record, allowing to locate the override
at model level.
Task-2792146 (Mail: Move model-dependent code from composer / template)
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#106658
1) forward-port of this PR: https://github.com/odoo/odoo/pull/97000
commit: c9209664ce3a4b10142bba4da6afb912afc983c2
2) use btree_not_null instead of simple btree for space optimisation
closesodoo/odoo#106484
X-original-commit: b743e736f764fd7d6e232d2c8eaf6b2e314c5f31
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Traceback when starting odoo server
ImportError: cannot import name 'errors' from 'psycopg2'
Exception management update in commit
4b430f8e30efb15f06982e4673cd73531a2119b3
would require psycopg2 version 2.8 minimum but version in
requirements is 2.7.7
closesodoo/odoo#106369
X-original-commit: b21fdf115e855d2383603e67343012bfe346cfd9
Signed-off-by: William André (wan) <wan@odoo.com>
We should always use `invoice_date` instead of the `date` of the move for currency exchange.
Re-adding some of the changes from odoo/odoo#87984
task-2807136
closesodoo/odoo#106367
X-original-commit: 76a640d05a350840bdde1c88bd052251aabd6b12
Signed-off-by: William André (wan) <wan@odoo.com>
Change the way the uniqueness of the sequence numbers is ensured.
Instead of using a `SELECT FOR UPDATE` approach inspired from the
`ir.sequence`, or even a true UPDATE, we can use a constraint approach.
SELECT FOR UPDATE
=================
By doing a FOR UPDATE NO WAIT, we are throwing an exception when another
transaction is creating a move using the same sequence as this one, by
locking the row that holds the current greatest sequence.
Since the row doesn't change, the lock is released and the following
UPDATE is allowed. Because of this, a "useless" UPDATE was always done
on the previous row to ensure a SerializationFailureError if two
concurrent transactions were trying to assign the same number.
This means that in a database with a lot of concurrent transactions
(typically with an online shop), many transactions were
aborted/rollbacked.
This approach also has the drawback of having the constraint implemented
python side, which is less robust.
UNIQUE CONSTRAINT
=================
Using a constraint on the database level means that the database knows
when some transactions will try to do something similar. It will
therefore make the concurrent transactions wait instead of aborting the
transaction.
It is however harder to have the constraint customized by different
modules/localization because it is now done directly in the database and
not in python. Changing the constraint means deleting/recreating the
index. For now, this only happens for Latin America l10n, so a simple
hardcoded approach is implemented.
In order to achieve this, the business code is trying to use the
sequence incrementally until it gets a number it can use for when
multiple transactions are concurrent.
closesodoo/odoo#106325
X-original-commit: 4b430f8e30efb15f06982e4673cd73531a2119b3
Related: odoo/enterprise#34297
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
2 fixes are made:
* We use a FOR NO KEY UPDATE instead of FOR UPDATE because we don't want
to prevent the insertion of lines referencing the partner as a foreign
key (i.e. new invoices).
The data is purely informative and the exact value isn't too important
anyways.
* We catch SerializationFailure on top of the previously catched
LockNotAvailable. It can happen in this use case
- T1 and T2 start
- T1 acquires the lock and updates
- T1 commits
- T2 acquires the lock: it gets it because T1 released it
- T2 updates: T1 did it as well so there is a serialization failure.
X-original-commit: b1491b7663e4c6c675e88a172e4b0a812e9b00a3
Part-of: odoo/odoo#106325
Exporting a Binary field with a value of type dict from a record raises
an error
Steps to reproduce:
1. Install Accounting
2. Open Accounting and go to Vendors > Bills
3. Open any posted bill and register the payment
4. Go back to the list view and export the bill in payment
5. Add field Invoice Payments Widget to the exported fields and export
6. An error is thrown
Solution:
Make the field attribute `exportable` work (pass it in the field
description)
Make fields `invoice_outstanding_credits_debits_widget` and
`invoice_payments_widget` non-exportable as they contain computed
aggregated data for the client's benefit and it doesn't make sense to
export them
Problem:
xlsxwriter's `write` doesn't support type dict
opw-3054184
closesodoo/odoo#105972
X-original-commit: c925ecb2a22750524020f0d111888fd76eedb0cb
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
- When importing account move lines, accounts are created with `name_create`. If the `account_id` column only contains the code, like "12345", the `split_code_name`
would only return a value for the name and leave the code empty. This is because the first group in the regex expects a space in the end, so "12345 " would work correctly.
The code is a required field, hence the import fails.
Removing \s from the first group fixes the issue and the code is saved correctly.
- There should be a UserError raised in `name_create` instead of the ValueError. The message should be clearer as well.
- It should not be possible to quick create an account from product category views.
task-3056847
closesodoo/odoo#105815
X-original-commit: 24758778172595388c19fd0a83d93d35f2260261
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
We made the field cumulated balance non exportable
in the GL.
Steps:
- Go to Accounting->Accounting->General Ledger
- Unfold and select one or several lines
- export lines
-> The cumulated balance is not computed
The reason is we don't pass in the compute as we don't
come from the search_read method when exporting, so we don't have a domain
to compute the cumulated balance.
As we can't force the domain, we override the fields_get method
to make the field non exportable.
opw-2800669
closesodoo/odoo#105538
X-original-commit: bd41d369342bfc97161a4190f03c98b718458aea
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
### Steps to reproduce
* go to Accounting > Settings and activate 'Cash Basis'
* got to Chart of Accounts and create a new account of type
`Current Assets`. We'll call it `A`.
* create a new tax, we'll call it `T`, with the following parameters:
* Tax type: Purchases
* Tax computation: Percentage of Price
* Amount: 22%
* Distribution of invoices:
* add a line with the following parameters:
% = 40, Based On = 'of tax' and Account = the tax paid account.
* add a second line with the following parameters:
%= 60, Based On = 'of tax'
* Distribution of Credit Notes: Add the same lines as
'Distribution of invoices'
* In the Advanced Options tab, set :
* Tax Eligibility = 'Based on Payment'
* Cash Basis Transition Account = `A`
* create a new vendor bill and add a product line to it and set
Taxes = `T` on that line
* confirm and register payment
Now go to Accounting > Journal Items, group by Journal. Look through the
'Cash Basis Taxes' group and find the entries related to the vendor bill
you just made. One of the debit lines on account `A` is not correct.
Here, the account should be the one specified on the invoice line.
opw-2796727
closesodoo/odoo#105445
X-original-commit: b69fc397aad019cc18bd00975d38dde9ffcc985b
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
To Reproduce
============
- enable QR code on Accounting settings
- with a customer who has a bank account create a credit note for him/her
- in other info tab, make sure that the qr code method is empty
- send or print the credit note
The Problem
===========
the qr code method field will be filled with SEPA, and a QR code will be added to the PDF
Solution
========
Generating a QR code for a credit note doesn't make any sense, so the qr code method field must be hidden
and no QR code should be generated.
opw-3010649
closesodoo/odoo#105385
X-original-commit: 4b0c37833547ff45d2240e51272372a572a920d5
Signed-off-by: William André (wan) <wan@odoo.com>
Fixes parsing error that happened when formulas of reports contained indentation (white space, end of line, tabs).
The formula was then not computed correctly and an unclear error message was thrown.
closesodoo/odoo#105028
X-original-commit: 631c1292042083a566072462aa788c6fc410925a
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Fixes the problem that some syntactic sugar formulas were not updated correctly when changed in the xml of reports.
In particular, during upgrade of modules changes were not taken into account.
Concerned syntactic sugar formulas:
- <field name="account_codes_formula">
- <field name="aggregation_formula">
- <field name="domain_formula">
X-original-commit: de9bd10f6e49c529de0d9c835e7185ecb2e699e5
Part-of: odoo/odoo#105028
The smart buttons were computing the number of aml instead of the number
of invoices/bills with the account.
We now compute back the number of moves.
We also changed it so it is consistent with the view,
so it computes the number of moves with move lines that have the distribution
instead of the analytic lines with the account.
X-original-commit: 84f3ee28156721cea0b530b92ede36fad58c5db8
Part-of: odoo/odoo#104933
The import feature is using a `=` as the operator.
To reproduce:
Import a file like this
```
partner_id,journal_id,currency_id,date,invoice_line_ids/account,invoice_line_ids/name,invoice_line_ids/quantity,invoice_line_ids/price_unit,invoice_line_ids/taxes
Publiroute,Customer invoices,EUR,18/06/2021,700000,Prof services 05/2021,1,100,21%
```
In this case, the ORM would look for a tax with the name equal to `2%1`
instead of `21%`.
This of course valid for any other way of using the equality operator in
the domain.
closesodoo/odoo#104764
X-original-commit: af46d8a567215a07b18d00f7d513681d385a8e7b
Signed-off-by: Julien Castiaux <juc@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Previously, when copying a report with top-level aggregation lines that reference other top-level lines, the codes in the aggregation formula where not correctly replaced.
This commit solves the issue, so reports can be correctly copied.
closesodoo/odoo#104632
X-original-commit: 94a524a1be42e2128b291a2357a637ddef4cce6b
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
When a report was set to only accept tax exigible items (typically for the generic tax report), its children did not inherit this behavior by default. Because of that, the localized tax reports and OSS reports didn't filter the items properly.
closesodoo/odoo#104611
X-original-commit: 547c00c221606af8b385fab347a34edb15f773cb
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
In some reports, the aggregation engine could face a problem if the number of elements of an addition (for instance) were too numerous.
If they were separated by spaces or \n, the addition would not occur and the error message would not be clear.
Trimed the spaces before dealing with said formula.
closesodoo/odoo#104568
X-original-commit: 738f2ff00a687e2df92b3eacd23c3cf5e83400a7
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
When reconciling an invoice using cash basis taxes with multiple payments, it is possible that some base or tax amount falls victim of rounding errors (for example, a tax amount of 9.99 would become 4,49 when paying the invoice with two payments of half its amount, hence loosing one cent).
In this case, when the invoice gets fully paid, we fix that by using adjustment lines in an exchange difference entry (even in monocurrency).
The bug we fix here is that the lines added into this exchange difference entry were never considered as tax exigible, and hence never appeared in the tax report, even though they should. This was due to the fact tax exigibility is recomputed automatically when creating the entry, so the value needs to be set afterwards.
OPW 2888592
closesodoo/odoo#104564
X-original-commit: cc924d5c91ccbb05f0f076faf5da8fbd739660b2
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Before this fix, when reconciling an invoice with a refund (both using cash basis taxes) in a multicurrency setup, the two cash basis entries that got created were made so that the invoice's used the refund's rate, and the refund's used the invoice's one.
This caused confustion, and forced Odoo to always add cash basis adjustment journal items in the exchange difference move, in order to balance the accounts properly.
By not swapping the rates anymore, we avoid the creation of these journal items.
OPW 2888592
X-original-commit: dc27baac2b39abcd77cfe20290393b246f7b2a9c
Part-of: odoo/odoo#104564
Consider the following situation:
1) Create a company in USD
2) Have an exchange rate of 1 EUR = 2 USD
3) Create a 1/3 tax
4) Make an invoice of one line of 100 EUR on which the tax is applied
=> In 15.0, this created:
- a base line of 200 USD = 100 EUR
- a tax line of 66.66 USD = 33.33 EUR
=> In 16.0, this creates:
- a base line of 200 USD = 100 EUR
- a tax line of 66.67 USD = 33.33 EUR
This is due to the fact 16.0 computes the tax amounts twice: once in domestic currency, and once in foreign currency (while 15.0 computed everything in domestic, rounded, then converted).
So, it does 100/3 = 33.33333333, rounding it to 33.33 and 200/3 = 66.6666666, rounded to 66.67.
The problem with the way v16 does it is that the ratio amount_currency/balance becomes inaccurate to recompute the exchange rate, due to the increase of the rounding difference (indeed 33.33/66.67=0,499925004 , wich is pretty far from the original 0.5). Because of that, when using a cash basis taxe of 1/3 on the exact same setup as in our example, instead of getting a base of 200, a base of 200.01 is computed on the cash basis entry (and hence used by the reports), even though the rate hasn't changed a bit.
To fix that, we now compute the tax amount directly in foreign currency, round it accordingly, and only then, convert it to domestic currency. Doing that, our test scenario gives the following:
200/3 = 66.66666 => rounded to 66.67 => 66.67/2 = 33.335 => rounded to 33.34
The lines become:
- a base line of 200 USD = 100 EUR
- a tax line of 66.67 USD = 33.34 EUR
With this, the tax amount on the invoice is now consistent with the currency rate: 66.67/2 = 33.335, which gets rounded to 33.34. The currency rate computed by the cash basis thus becomes 33.34/66.67 = 0.5001; way closer to the original rate, and not causing a significative enough rounding error to impact the base amount anymore.
X-original-commit: 68fe20f612b8da003415a061b18bb0464329dba9
Part-of: odoo/odoo#104564
Steps to reproduce:
In a base runbot with just contacts installed and the module
"account_edi_ubl_cii".
Go to contacts, Configuration, and Bank Accounts, try to create a bank
account for any user.
Issue:
The creation throws an error and doesn't let us create any bank account.
Solution:
We need to add the missing decorator: @api.model_create_multi, which is
needed when we work with vals_list.
opw-3039048
closesodoo/odoo#104427
X-original-commit: e83da6166da40f5c30c396e6aa9811c8ee1d0e6e
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Claire Bretton (clbr)