From 16.0 any user can delete a customer invoice/vendor bill even if it creates a sequence gap.
This commit updates the rights and the warning message:
- The deletion confirmation message contains a warning about the sequence gap
- Only a Billing Administrator/Accountant can delete customer invoices/vendor bills creating the gap
- Also, if the fiduciary mode is on (`quick_edit_mode`) it should be possible to delete
invoices/bills regardless of the user group
task-3284218
closesodoo/odoo#128556
X-original-commit: 2249f899049ef94b14b083c8db976662b868b026
Related: odoo/enterprise#44128
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Since 7bd93cc64b, we add the amounts to
invoice from sales order to the credit limit warning. When looking at
the credit amount on a partner from an accounting perspective, it is
not correct though that sales orders to invoice are considered as well.
In this change we split the credit amount from invoices and from sales
orders to invoice. On the partner we only show the credit amount from
invoices. In other places we add both.
task-3375260
closesodoo/odoo#128158
X-original-commit: 94eae9b73995dbf2175ecee65548ace5a382f5f8
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
Issue Description
When a user changes the sequence of the lines which have a parent_id field,
particularly when it changes the sequence and the parent field of the line is
after the line, then it will give an error in the opening of the reports.
Steps to Reproduce:
[This step is only used for this traceback. But the issue occurs in all the
account reports.]
1. Install the account_reports module.
2. Open accounting and go to configuration.
3. Then, click on accounting reports and select the profit and loss report.
4. Change the sequence of the lines.
5. Save the changes.
6. Click on the reporting menu and select the profit and loss report.
7. The traceback will generate.
Fix:
This commit resolves the above issue by throwing a validation exception
when the parent line is set after the line. And also throws a validation
exception when the user sets the parent line as itself.
Sentry ID: 3944989529
closesodoo/odoo#128209
X-original-commit: a8a147dab40af4732bbe072cfd9cff1d1ba80e36
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
When '_seek_for_lines' returns multiple suspense_line for
transaction_amount calculation, then the user will face this
issue 'Expected singleton: account.move.line(516, 517)'.
Steps to reproduce:
- Create a new transaction in Journal (Bank) by Accounting Journal
> Bank Reconcilation > Add a Transaction.
- While creating a transaction add a partner, amount (amount > 0),
Foreign Currency, Amount in currency and then save it.
- Go to Journal Entries by Accounting > Journal Entries
and then open your recently created journal entry.
- Click on reset to draft and then in 'Journal Items'
add a line with some credit amount such that total credit and debit should be
equal. (Under Account it should be Bank Suspense Account).
- Now click on 'Bank Transaction' button in the form view.
By following above steps you will be able to reproduce the error.
Applying the changes will resolve the issue.
sentry-4217912848
closesodoo/odoo#126284
X-original-commit: 12a75a8521f8150c382645215c440d39af4b50aa
Signed-off-by: Laurent Smet (las) <las@odoo.com>
The bills upload widget uses a custom attr "linkText". translate.py will only generate terms that are in the TRANSLATED_ATTRS constant, thereby not including these in the po template file.
To fix this, the attribute is changed to a recognised attr "title".
The JS widget will still recognize linkText, for databases that have not updated the module.
Task-3335585
closesodoo/odoo#125516
X-original-commit: 8569ceb101f6dfe5882c33c120b9ed6d76ccf5be
Related: odoo/enterprise#42755
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Steps to reproduce:
- install l10n_be (company B)
- stay on Company A and create a cash rounding
- Go to Company B and create an invoice
- In Other Infos > Cash Rouding Method, set it to the earlier created one
- Save
Issue:
You won't be able to save. But the message is too generic to know what is the cause of it
"Missing required account on accountable invoice line."
Cause:
The field `profit_account_id` is company_dependent. Therefore, the same cash rounding record will be accessible in both companies but in Company B the `profit_account_id` won't be set.
When Saving, we compute a cash difference (rounding) and try to create a new line for it. But since there is no account set, the sql constraint will be raised.
Solution:
The less dirty solution is to have an onchange that check that whenever we want to set a cash rounding method, it has all the required fields set
opw-3185950
closesodoo/odoo#123072
X-original-commit: e0df7cafefa3c2956105bd35c5bedc0c5bcdffaa
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
At the moment, the lock date message is generated in
_compute_tax_lock_date_message. We delegate it to a separate function
in order to use this message elsewhere as well.
Note: this refactor introduces minor changes in behaviour:
- we remove the second part of the lock date message (that mentions
other lock dates than the most blocking one), because it is too much
information.
- we calculate the new accounting date from the existing accounting date
rather than from the existing invoice date. This should not change
anything in practice, since the new accounting date will be the last
day of the period after the lock date.
task-2823170
X-original-commit: aeb6707dfc0f4aa093d7687bbb0e488558d2a99f
Part-of: odoo/odoo#122997
Currently, only stable releases see their translations updated. This has
resulted in master accumulating outdated stuff for years, which can be
confusing for users testing master on runbot.
This one-shot commit resynchronizes master translations based on the
content from 16.0 and removes empty PO files (i.e. no longer containing
translations).
closesodoo/odoo#121629
Related: odoo/enterprise#41171
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
To reproduce the issue:
1. Change the language to french
2. Go to Accounting > Payment terms
3. Select one payment term
4. Look at the example section
5. Examples are in English
Error: The examples should have been in French
The sentence was hardcoded and not translatable
OPW-3203268
closesodoo/odoo#116883
X-original-commit: 7b244e71284d9bfb7186caa82f33f39902937b96
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Demany Antoine (ande) <ande@odoo.com>
They dates from < 2027 and are quite outdated. Favour the nl
translation instead.
n_BE is not on Transifex so it was not possible to correct bad
translations.
closesodoo/odoo#115845
X-original-commit: d04c8b7e484db8306d858c891a7a2b11885fdcd9
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Using the bank recon widget (enterprise), it is possible to create bank statements from the list view.
The default start and end balances were not computed.
This PR fixes that (computes the balances) and has a few additional improvements:
- A warning is added to the statement form view to indicate the problem with the statement
- Statement validity can be computed before the statement is saved, to guide the user when manually creating statements
- balance_start, balance_end_real are now computed fields
- default_get method is simplified and moved
- the action "Create Statement" is removed in favour of multi-edit
- tests and translation templates
related enterprise PR contains the necessary view changes.
closesodoo/odoo#115174
X-original-commit: dfae9e204195abc1b776b9797043ceb38318de08
Related: odoo/enterprise#38131
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Ayob Habib (ayh) <ayh@odoo.com>
Signed-off-by: Christophe Simonis <chs@odoo.com>
Currently, it is possible to resequence account moves which are hashed.
This should not be the case. Therefore, we are adding the name of the
move into the list of hashed fields.
However, since we are changing the hashing algorithm by including a new
field in its computation, we must add a versioning system to make sure
we don't break the integrity (data inalterability) report.
In practice, this means that prior to this commit, all hashed moves used
the fields of v1, and moves after this commit will use v2 (which adds
the name into the list of hashed fields). Thus, whenever we generate
the integrity report, we will run the v1 algorithm, and if it a
potential corrupted move is found, we will switch to v2 and check again.
If it also fails, this means the hash is indeed corrupted.
task-id 3102481
closesodoo/odoo#114376
X-original-commit: cb76725b071d89a9f3e81861f19d073138741b58
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Ricardo Gomes Rodrigues (rigr) <rigr@odoo.com>
In case of the user have no access to all account.move, the hash result can be wrong.
Before this PR a user with limited access can print this report.
closesodoo/odoo#112970
X-original-commit: 8263b210ea980539941ce10f5c102c9056959b72
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Co-authored-by: John Laterre (jol) <jol@odoo.com>
With this commit, when importing an account,
we post the opening move only when importing
opening balance field.
Steps to reproduce:
- import a coa template
-> an opening move has been created and posted
- import an account
-> Error: The entry MISC/XXXX/XX/XXXX (id XX) is already posted
Issue happened because we try to post the opening move
when entering in the account_account.load method.
With this commit wemodify and post the opening move only
if we try to import this field.
opw-3105083
closesodoo/odoo#112739
X-original-commit: 27ef0b93770c4e358a8cf4082afcfeb2da96f6c6
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
To reproduce
============
- create a vendor Bill
- add the PDF (from ticket attached files) in chatter
- go back to list view and select the bill -> print Original Bills
a traceback is raised
Problem
=======
for some excptional PDF files (like the one attached in the ticket),
the library PyPDF2 that we use to manage PDF files crashes.
Solution
========
a [fix](https://github.com/odoo/odoo/commit/e55196375aa124558b87ebd50012d5664295ca07) was backported from 16 and updated
so that we don't block the flow, we let a message on chatter that there was an error and we ignore adding the banner.
opw-3141143
closesodoo/odoo#112467
X-original-commit: d73a6261b9c7de41a1de6a2cd888c131ecee023b
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: abla001 <abla@odoo.com>
before this commit, the action name was not translatable into user language and always displayed in english.
after this commit, the action name will be translatable and will be showing the value based on user language preference.
closesodoo/odoo#111991
X-original-commit: 6aa80ca670476494b10115f61805324811b73a58
Signed-off-by: John Laterre (jol) <jol@odoo.com>
odoo/enterprise#36355 adds the ability to generate PDF's and attach them to the statement. To give the user feedback of completion, the PDF is then downloaded. Since this is a duplication of features, the report is no longer bound to the print menu.
Task-3151040
closesodoo/odoo#111542
X-original-commit: 331aabe79b80b06f44bc2de1712742ec8f00f735
Related: odoo/enterprise#36559
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Ayob Habib (ayh) <ayh@odoo.com>
before this commit, the action name was not getting translated to user language.
after this commit, the action name will get translated to user language.
closesodoo/odoo#110856
X-original-commit: 6758cde0358359d76642b0cbea4c208eac57dd92
Signed-off-by: Tiffany Chang <tic@odoo.com>
Steps to reproduce:
- Create an invoice with a product.
- Confirm it.
- Go to the product and select a UoM of another UoM category.
Issue:
Traceback
Cause:
https://github.com/odoo/odoo/blob/51ead4b2d52e0faec2065b475dac7f376328c425/addons/uom/models/uom_uom.py#L155-L159
Solution:
Add a constraint to prevent the user from changing the UoM category
of a product if it is used in a posted invoice.
At the same time, a similar constraint is added on `account.move.line`
to make sure the line's uom remains consistent with its product.
opw-3039419
closesodoo/odoo#110102
X-original-commit: aeb798d01aafee5fcaa8614f7e2b39a380d0b6ce
Related: odoo/enterprise#35887
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
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>
// 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>
- 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>
Most of the dropdown of the account reconcile model view were weirdly displayed, the case was too small for the text, by removing the class oe_inline most of the dropdown were fixed, and for the other just a slight modification on the width did the job.
Also on the left column the two first line were not aligned with the rest, same for the right column on the first line, now it's fixed but I had to put the invisible in the field
Other thing, the counterpart entries were too much on the left of the page due to a useless group, it's now removed
Also change some display name and added the translation
closesodoo/odoo#103682
Task-id: 3000402
X-original-commit: 487cc0959991d804a48f44b914540786a85f180f
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>
Currently, there is no check when deleting an account report that has variants. Deleting such a report leads to variants not being accessible anymore.
When duplicating an account report, the columns are not duplicated and it can be tedious to duplicate them by hand.
There is also a bug when copying lines that have parent lines (no report_id set)
This commit fixes these issues by:
- raising a UserError when trying to delete reports with variants
- duplicating columns when duplicating a report
- correctly setting the report_id for all duplicated lines
Part of the big task fixing bugs in accounting
Task id=2996493
closesodoo/odoo#102846
X-original-commit: a84c7c6f210434dfcbf5c6a316f20981d06a3925
Related: odoo/enterprise#32607
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Popeler Antoine (anpp) <anpp@odoo.com>
You cannot set a receivable or payable account as a bank account of
a bank journal directly, but it is very possible to just set an
account of another type, then change the type of this account to
receivable.
This new constrains will make sure that you cannot change the type of
an account.account set as bank account on a bank journal to any of those
two types.
closesodoo/odoo#102790
X-original-commit: f9500ca4c898cd86681cc2e48ec2c66cf5670917
Related: odoo/enterprise#32579
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>
Change 'Invoice date' label on report according move_type
closesodoo/odoo#102005
X-original-commit: c8991f2760c1ac81ec2a64553744cef9321f2531
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: wan <wan@odoo.com>
The current message may make you believe the date on
the invoice will be changed when it's the accounting date
This aims to clarify that the move.invoice_date will stay
the same when it's the move.date that will be changed
closesodoo/odoo#101820
X-original-commit: 5f5dbbcc66f4ded1388949386faf90e0d406a4b2
Signed-off-by: Julien Alardot (jual) <jual@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce:
- install the "account" module (Invoicing app);
- create an invoice;
- make partial payments in other currencies,
- print the payment receipt.
Issues:
The amount and the currency do not match.
In addition, it is difficult to see the conversion between the payment currency and the invoice currency.
Causes:
The currency symbol of the line corresponds to the payment currency.
The amount of the line corresponds to the amount converted into the base currency of the invoice.
Solutions:
Add one column named "Amount In Currency" and add the amount in the currency of the payment.
In the column "Amount", correct the symbol of the currency.
opw-2973067
closesodoo/odoo#101489
X-original-commit: b05d95a046fb7cfd438adce3d5f1e8b2f84953bf
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
In order to better display the functionalities, we will change how
the demo data for bank statement are created. There will now be one
bank statement and multiple bank transactions not linked to a statement.
Also rewords one error to be clearer.
closesodoo/odoo#101466
X-original-commit: 5e14b28905fc00bad2c2ccd40328c676d049917d
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>
Only for terms containing Credit Note and expenses
closesodoo/odoo#97840
X-original-commit: 1754b094a66476a0bdb29fe60dc5583c03336c3f
Related: odoo/enterprise#30262
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Steps to reproduce:
- Create a partner-individual, assign to a company
- Create an invoice and set the new partner as the customer
- Go to the partner view
- Delete it
Issue:
- It is possible to delete it
Cause:
The constraint in "account.move.line" uses the "commercial_partner_id" as the partner
Solution:
- Prevent the unlink if the partner is used in 'account.move' -> To delete in Master
- add "ondelete='restrict' for partner and commercial_parner in 'account.move'
opw-2858789
closesodoo/odoo#94591
X-original-commit: 7d37f5ef7ecd87aea666d96dc8200a74c8dc0b31
Signed-off-by: William André (wan) <wan@odoo.com>
Do not allow users to create accrual entries for locked periods.
This would either create an entry for another date, since the date is
changed automatically by `_get_accounting_date` when posting.
Reproduce:
* Set a lock date
* Do an automatic entry for either changing the account or the period
before that lock date
Or it would traceback because the date would be changed automatically
and no matching would be possible when changing the period.
* Set a lock date
* Create an automatic entry to change the period of an entry before the
tax lock date
closesodoo/odoo#87391
X-original-commit: f830b008781c2f6f5644395688654e64edd5c836
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
aliya