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>
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>
// 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>
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>
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>
- 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>
### 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>
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:
- create two journals, A and B, which have the default accounts defined in the payment method manual in "outstanding receipts accounts".
- create a payment with a journal A;
- duplicate the draft of the payment (because it is not possible to change a journal if it was posted before);
- select the journal B and save (or confirm)
- The journal is changed, but the default journal B accounts are not applied.
Issue:
Despite the payment is in draft and has not been posted before, move_line accounts do not change with the journal selected for the move.
Cause:
When a payment is duplicate, records are save in the database.
Modify the journal en then save will trigger the write method of the payment model (and not the create).
During this method, we begin to find the move lines which correspond to liquidity, counterpart and writeoff lines.
Unfortunately, the line corresponding to the old journal will be detected as a writeoff and not as a liquidity line (because the journal has changed).
This fault will cause a balance error in the rest of the procedure.
Solution:
Take into account the case where writeoffs are detected when there is no liquidity line (and no counterpart line).
In this case, force the no writeoff line.
Generate the correct ORM commands taking in consideration if the line exist (1: update) or not (0: create).
opw-2998031
closesodoo/odoo#103496
X-original-commit: cf277b2685a72e0a8ca44c4a59331136a722fbed
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
The `analytic_distribution` field is a Json.
It was stored temporarily as a char.
Search is not available yet, so we do queries by hand when we need to search on keys.
Also added a constraint on account_analytic_distribution_model,
so we don't have models with accounts specific to a company when the model has no company or another company.
It would cause an issue when looking at the models from another company.
X-original-commit: 7064c95aa04e5138bb12ae97acfee04ebb67cc0e
Part-of: odoo/odoo#103097
Analytic distributions that contain mandatory plans should be blocked from posting.
However, automatic flows (for example subscription invoices) should not be blocked.
For this reason, the context is used to determine whether the distribution should be validated.
closesodoo/odoo#102720
X-original-commit: 7b11af76598c0782ac2097d3cbeb718962be2537
Signed-off-by: William André (wan) <wan@odoo.com>
Currently, in a Journal Entry, applying a tax on any journal item doesn't compute the corresponding tax line.
We end up in a situation where the move appears balanced but doesn't take into account the taxes applied. Moreover, the move cannot be posted.
The solution involves several steps:
- Changing a tax on a line now triggers a save.
- Changing the debit or credit on a line with taxes will also trigger a save.
- The company's suspense account is used for the balancing line.
During the save, a check is added to see if the move is unbalanced.
In that case, a balancing line will automatically be created to ensure the move can be saved.
X-original-commit: a3e9ca9586cba9d6161d4c05a7bfff9beeeddea7
Part-of: odoo/odoo#102487
Currently, the user can resequence invoices that are in a locked period.
This is not desirable, this commit fixes this.
closesodoo/odoo#102469
X-original-commit: b1009e4aa514215054de44544a8914c16932f55e
Related: odoo/enterprise#32423
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Ricardo Gomes Rodrigues (rigr) <rigr@odoo.com>
The condition that determines whether to display the tax base was wrong
It should be displayed when either condition is met:
- There are multiple tax base amounts
- The only tax base amount is not the same as the untaxed amount
Note that this last case may happen with cash discounts
closesodoo/odoo#102247
X-original-commit: a8ff4b876c8ab48177795e6ace1bb1361744c8a7
Signed-off-by: Camille Spiritus (casp) <casp@odoo.com>
Signed-off-by: Stanislas Gueniffey (stgu) <stgu@odoo.com>
The early payment cash discount functionality was merged in 16.0.
This PR allows for the behavior to be as localization specific as possible.
This concerns :
The tax computation (some countries leave it untouched after the discount, some countries discount it, and Belgium has a mixed behaviour)
The account in which the cash difference resulting of the cash discount should be put.
task- 2983913
related to #99572closesodoo/odoo#102032
X-original-commit: 591757902dcdf1e3609d9c5ae23e2b134ee8e4da
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Camille Spiritus (casp) <casp@odoo.com>
When using complex sub-totals, the total sum of taxes was always removed
from the total amount.
________________________________________________________________________
This also allows more flexibility for ordering tax groups.
Before cd6c33575b, it was possible to have this:
* Tax Exempt 2% (preceeding subtotal "Discounted")
* VAT 21% (no preceeding subtotal, take default)
* Reapply 2% (preceeding subtotal "Reapply")
The value for groups without preceeding subtotals was always 0 and
* before the commit mentionned above, it was possible to reach 0 too for
the groups with a preceeding subtotal
* but after +1 was added making it impossible from the view
We now always take the group's order (or the smallest one for groups
without a preceeding subtotal)
Followup on d8d47f9ff8
task-2956509
X-original-commit: d3471336b85f17fe274acf6a01b71c5d1483e94a
Part-of: odoo/odoo#101994
This commit improves the fiduciary mode by:
- removing message error about the change of sequence format
- suggesting the Customer Invoice / Vendor Bill date according to the following heuristic:
- Last day of the month of the most recent Customer Invoice / Vendor Bill (ignoring drafts) OR today (whichever is the smallest)
- If this date falls before a Lock Date, pick the last day of the first month that is not locked
- Examples:
- Example 1 :
We are June 17th 2022. No Lock date. Bill Date of the most recent Vendor Bill : March 15th 2022
==> Default New Vendor Bill date = March 31st 2022 (last day of March 2022)
- Example 2 :
We are June 17th 2022. No Lock date. Bill Date of the most recent Vendor Bill : March 31st 2022
==> Default New Vendor Bill date = March 31st 2022 (last day of March 2022)
- Example 3 :
We are June 17th 2022. No Lock date. Bill Date of the most recent Vendor Bill : June 2nd 2022
==> Default New Vendor Bill date = June 17th 2022 (today is the smallest)
- Example 4 :
We are June 17th 2022. Lock date : April 30th 2022. Bill Date of the most recent Vendor Bill : April 30th 2022
==> Default New Vendor Bill date = May 31st 2022 (last day of the first month not locked)
- renaming the invoice according to the suggested date
Task id: 2887007
closesodoo/odoo#101799
X-original-commit: 179f4f83db0d029850375012bbf80dedc6679505
Signed-off-by: William André (wan) <wan@odoo.com>
Some payment terms with early payment cash discount weren't giving out the correct computation.
Example of a problematic set up :
Payment term with multiple lines (percentage X, percentage Y, balance)
Cash Discount tax computation : mixed
The journal items of the invoice and the total amount wouldn't correctly take into account the different discount percentages of the payment term lines.
Fixed it by applying the line percentage to the epd lines computation.
closesodoo/odoo#101341
X-original-commit: 4af4d0e3bc25a5f81eabd1c2068fd6bf6a25621d
Related: odoo/enterprise#31874
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Camille Spiritus (casp) <casp@odoo.com>
Chances are that Journal Entries are coming from previous migration and they
could trigger the creation of CABA Journal Entries even when the company at
stake is a non Cash Basis Company.
closesodoo/odoo#98954
X-original-commit: fcad4dbdbd65775b75aa94049da06bd0b07295d8
Related: odoo/enterprise#30763
Signed-off-by: Laurent Smet <las@odoo.com>
Bank statements are now optional in accounting. The users add statements directly and can assign statements for control reasons.
The users can enter end date and end balance real for the statements and attach the bank statement scan.
The system checks if there is a gap (lines without statement) before current statement and warns the user
with decoration, also we check if the ending balance match the accumulated balance of the last line.
Bank statement lines now show an accumulated balance and can be sorted by drag and drop in the same date, if the user drags a line
to a position with lines of another date, it simply doesn't have any effect.
Rename accumulated balance to cumulative balance, a better name
closesodoo/odoo#99092
Task: 2879904
Related: odoo/upgrade#3906
Related: odoo/enterprise#30824
Signed-off-by: Laurent Smet <las@odoo.com>
The goal of this commit is to get rid of the analytic tags as they were confusing, serving tag purposes as well as distribution on analytic accounts.
Everywhere analytic tags were used as a distribution have been replaced with a new widget that will dispatch distribution on analytic accounts. If there was an analytic account field next to the tags, it has been included in the distribution.
Analytic tags that were used simply as information tags have been removed.
To fill the new widget, there are now 2 kind of rules that will help fill and prefill it.
The first are applicability: previous groups have been removed, and have by replaced by plans. Each account is required to have a plan. These plans define when they are available in the widget: a default applicability per plan and applicability lines that can specify rules following the context of the widget.
The second one are distribution models, that will replace previous default rules but follow the same principles. The accounts (and so the plans) that will be given by the distribution model can override the applicability rules from before.
closesodoo/odoo#98914
Related: odoo/upgrade#3885
Related: odoo/enterprise#30743
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: Habib (ayh) <ayh@odoo.com>
Purpose :
Improve multiple use cases while handling the Accounting part of Cash Discounts in Odoo.
When creating a Payment Term, the user can now specifically design an early payment discount for each payment term lines.
The user can choose between three different kind of tax computation for the discount. If the conditions for the cash discount are fulfilled, the tax will either be:
- included : the tax and base amounts will be discounted.
- excluded : the tax will be left untouched, the base amount will be discounted.
- mixed : the tax is durably discounted, the base is discounted if the early payment occurs.
The discounted amount and the conditions to fulfill are printed below the invoice PDF if the option to do so is checked.
Took the opportunity to improve the display of the payment terms on the invoice in general.
Registering a payment while filling the condition for an early payment discount will prefill the fields accordingly.
The Journal Items in the account.move, the payment and the reconciliation are modified as needed to take the discount into account.
Reconciliation --> In the reconciliation widget, the logic of Early Payments Discounts is also applied to allow as often as possible for an automatic reconciliation.
Related : odoo/enterprise#28607
Task-2968644
closesodoo/odoo#99572
Related: odoo/enterprise#31225
Signed-off-by: Laurent Smet <las@odoo.com>
Currently using the ``chatter_post`` route to post a message implicitly checks
for access rights on related record. It is done manually in ``message_post``
that is called by the route. It is done because record name is accessed as
sudo and an explicit access has been added because of fear of information
leak.
However this is a bit out of scope for ``message_post`` to perform that check
at that point. As the underlying record is accessed numerous times, adding
an explicit check just adds queries.
In portal, users may have a token and/or a hash and a partner_id, in which
case they enter sudo mode if valid, and an error is raised otherwise. However
when not using a token and/or a hash and a PID access check is now done
directly in the controller helper. Moreover this allows to have the access
error directly instead of being possibly hidden by another error, which was
the case before this fix (was actually raising about missing email_from).
In this commit we add an explicit check on record access before entering
the post computation. That way access errors are directly raised.
A fix in accounting is necessary to ensure the right error is raised. Indeed
otherwise it currently raises due to non existing email_from, and should
raise due to ACL instead. Tests are now more inlined with classic flows.
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#99654
Not entirely sure about TestAllocationRights. For TestEsEdiCommon
issue is quite obviously that it's inherited by tests which are
external, so when the `post_install_l10n` tag gets applied those tests
get run during "normal" l10n and they break.
closesodoo/odoo#98814
Related: odoo/enterprise#30825
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
plus_report_line_ids and minus_report_line_ids have now been replaced by plus_report_expression_ids and minus_report_expression_ids on tax templates.
The test was failing locally but not on runbot, because it was missing the post_install tag.
closesodoo/odoo#99462
Signed-off-by: Laurent Smet <las@odoo.com>
This commit improves the payment terms by:
- making the payment terms lines editable on-the-fly removing the need for a wizard
- refactoring the computation of the payment terms
- adds new demo data for payment terms
- adds an example section where the user can test and preview the due dates and amount of its payment terms
- adding a new parameter "Display terms on invoice". If set, the payment deadlines and respective due amounts will be detailed on invoices.
The refactoring:
- adds a field `months` (months to add after the invoice date)
- adds a field `end_month` (if True, switch to the end of the month after having added months or days)
- renames the field `day_of_the_month` to `days_after` (days to be added after the switching to the end of the month, only if `end_month` is set)
- deletes the field `option` which was too restrictive
- modifies the calculation of the payments terms taking into account these new fields
This allows some combinations that were not possible before.
Example: The French payment terms "30 jours fin de mois le 10" (which should be interpreted as "10 days after the end of the next month") can be encoded as
```
months = 1
days = 0
end_month = True
days_after = 10
```
Task id 2852814
closesodoo/odoo#91490
Related: odoo/enterprise#29661
Related: odoo/upgrade#3524
Signed-off-by: Laurent Smet <las@odoo.com>
The current taxes computation method defined in account_edi has been moved to account on account.tax to be usable on any models.
closesodoo/odoo#99401
Related: odoo/enterprise#30967
Signed-off-by: Laurent Smet <las@odoo.com>
On a bank statement line:
If a foreign currency is set and the amount in currency is not set, the line is reconciled automatically (because the amount is 0) and this should not be the case.
Add a constraint on `account.bank.statement.line`: raise an error if the foreign currency is added, but the amount in currency is not.
This conflicts with the tests that allow this behaviour, so the related tests are deleted as this should not be allowed anymore.
task-2956422
closesodoo/odoo#99028
X-original-commit: 1dfa3d074c7368abb51df56cb7fd1ee5115399b1
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Current task is not covered the whole cash discount feature. For now, we decided to revert the current feature and make a new more complete one later.
This reverts commit 7482aff6d7.
closesodoo/odoo#98986
Related: odoo/enterprise#30783
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
This commit adapts account's model to the new report engine introduced for v16, and updates the data files accordingly.
account.report model is now declared in community, together with the other models used by the reporting. This is done so that the tax tags can properly be created by the tax report and used on tax templates. All the actual computation logic stays in enterprise.
See enterprise commit for full details.
Task 2524389
Part-of: odoo/odoo#94125
When using CABA and reversing a move, we expect the CABA move to
be the one impacting the tax grids, and not the reversed move.
Thus, we now avoid setting the tax grids for CABA taxes on
move lines created when making a reverse move.
Task id # 2895267
closesodoo/odoo#98789
X-original-commit: 5dd50ac1433be262ddd49d8b165e240afd16e675
Signed-off-by: Laurent Smet <las@odoo.com>
The aim of this commit is to improve UX by helping the user to find duplicate
bills in a more convenient way.
With this commit, when a user create a bill or credit note on bill that might
be a duplicate, a warning banner is displayed on the Form view of the
account.move.
On this banner there is a button that leads to the list of the duplicate
bill/credit note.
The previous warning message on post is also replaced by a RedirectWarning
Context:
Previously, the warning for duplicated bills was thrown when the bill was
saved. This was changed with https://github.com/odoo/odoo/pull/81748
It made the blocking warning being delayed until the bill is posted.
Previous to this commit:
A duplicate bill can only be detected automatically when posting the bill with
a non convenient blocking warning preventing the user to post his bill(s).
After this commit:
- A warning banner is displayed on the bill form during the bill creation.
- The banner contains a button leading to the list of duplicates.
- The blocking warning is improved by providing redirections to the duplicate
move.
closesodoo/odoo#81765
Community-pr: https://github.com/odoo/odoo/pull/81765
Task: #2612299
Signed-off-by: William André (wan) <wan@odoo.com>
Currently, computing an account's current balance takes canceled and
draft invoices into account. Only posted invoices should be considered.
opw-2896728
closesodoo/odoo#98843
X-original-commit: d3a7115feab9ca1bd8372f4450d3abc3eb52cdb0
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
Fix the accounting date in a few scenarios, such as exchange difference
or CABA moves reversal.
Also avoid updating the currency rate when reversing exchange difference
moves.
closesodoo/odoo#98543
X-original-commit: 2b8df0c111a785a9e51dc2f528ac5b00cb0eadb9
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>
Improvement of https://github.com/odoo/odoo/commit/e66663b52920ad5a647b03a8fd9ade4070f09158
The commit mentioned above introduced a bug, which
prevent the user to select payment method when register
a payment for multiple partners, even if the payments
were from the same type.
The solution here is to allow the selection of payment method
in any case, the _create_payment_vals_from_batch method will
change the payment method if it is not available on the journal.
Note: for the forward port from 15.0, only test is adapted, as the bug
does not happen.
opw-2954325
closesodoo/odoo#98574
X-original-commit: d16946b450356922b69e6152bd343229ed4d2bb3
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
Purpose :
Improve multiple use cases while handling the Accounting part of Cash Discounts in Odoo.
When creating a Payment Term, the user can now specifically design an early payment discount through an additional part in the wizard.
This will, amongst other things, allow the user to choose in which way the tax should be computed on the discounted invoice (tax included/excluded).
The discounted amount and the conditions to fulfill are printed below the invoice PDF, as well as the details.
Registering a payment while filling the condition for an early payment discount will prefill the fields accordingly.
Reconciliation --> In the reconciliation widget, the logic of Early Payments Discounts are also applied.
Related : odoo/enterprise#28607
Task:2729038
Part-of: odoo/odoo#94050
This commit fix a bug noticed when fixing this other
one in v15 https://github.com/odoo/odoo/pull/93943.
We notice that, in addition to not set correctly
the payment type, the payment method was wrong too.
With this commit, when creating payments from batch,
we check for each payment if its type is the same
as the one set on the wizard. If not (which means
that there are payments of differents types), we set
the payment method regarding the payment type.
opw-2852186
closesodoo/odoo#98153
X-original-commit: af1fab8dab141c49d98b431a40a5ce98f2f3249c
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
When register a payment for a bill an a credit note,
the two payments have the same type.
Steps:
- Create a Vendor Bill, and a Vendor Bill Credit Note
- Select both and register payment without grouping them
-> The two created payments have the same type
With this commit, if the field group_payment is True, we
set the payment type regarding the balance of the move line.
opw-2852186
closesodoo/odoo#98010
X-original-commit: 2ad78818b59350cf5e9367802c41820e36d05db1
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
Walid HANNICHE (waha)