This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Task: 2856281
- Remove user_type_id, account.account.type model, internal_type
- Add account_type that is a simple selection field
- Move internal_group and include_initial_balance to account.account
- Because of these changes, type_control_ids on account.journal is also removed
closesodoo/odoo#93212
Related: odoo/documentation#2223
Related: odoo/upgrade#3595
Related: odoo/enterprise#28205
Signed-off-by: Cedric Snauwaert <csn@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>
Current behavior:
If you made a sales with a partner wich is part of a company.
And then archive that partner and click on the sales smart button
from the company the sales from that partner wouldn't appear in
the list. The problem is the same for the invoices
Steps to reproduce:
- Install sales and contacts
- Create a sale for a partner (e.g. Edwin Hansen from Gemini)
- Archive that partner
- Go in the company view, click on sales button
- The sale from the archived partner do not appear in the
company sales list
opw-2850115
closesodoo/odoo#93587
X-original-commit: 8e46a00356a85b42078637d97ec6d0ef204f370a
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Total invoiced is computed with `active_test=False` [1], however the
corresponding action didn't have that context. Since Odoo 14 `child_of` domain
filters out unaccessible records (including archived ones) [2].
Fix it by adding the context to the action.
STEPS:
1. Have a active contact that has an amount invoiced (invoices pointing to this contact name).
2. Click through on the amount invoiced button, and receive a list of relevant invoices.
3. Now go back to the contact, and archive the contact.
4. The smart button containing the amount invoiced stays the same.
5. Click through on the smart button again
BEFORE: no invoices
AFTER : listed invoices corresponds to the computed total value
[1]: https://github.com/odoo/odoo/blob/574ca75ab6fa583aabc0c1cfc65206e72864e546/addons/account/models/partner.py#L379
[2]: https://github.com/odoo/odoo/commit/3e1b960acf3f6a726338476ba9e62e5ef5c84ef9
opw-2853525
closesodoo/odoo#91828
X-original-commit: bf96188abbf8ad19d1a2f8f82a1e6248245778b5
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
There is an issue where we redirect to a list view/form view of
res.partner but with id's from res.partner.bank, thus redirecting to
the wrong views.
closesodoo/odoo#88865
X-original-commit: a1cce790fcd2d1823fb9e3d5c3c3e916d34568e5
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>
The Credit Limit group on the res.partner record
doesn't appear until you save the record.
This means you have to perform extra clicks
if you want to edit this value.
The goal is to show the `credit` field on the accounting tab
on creation if `res.partner` is a company and
Credit Limit setting is activated.
task-2817650
closesodoo/odoo#88830
X-original-commit: 0ac5f58d4d4786a0b86bf0b71406d7d2c5d470bf
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: John Laterre <jol@odoo.com>
Most of the extensions of `_name_get` are very similar and only want to
search for the given string in multiple fields.
A lot of extensions also don't take into account the negative operators.
Some implementations were also really outdated and needlessly
complicated.
closesodoo/odoo#86588
Related: odoo/enterprise#25608
Signed-off-by: Raphael Collet <rco@odoo.com>
The basic idea of this functionality is for users
to be able to put limits on Partners that would
trigger non-blocking warnings when trying to confirm new:
- Sales Orders
- Invoices
when that partner has too many open invoices.
task-2722165
Part-of: odoo/odoo#83205
This commit modifies most of the usages of read_group and uses
_read_group instead. _read_group doesn't join automatically on the
many2one fields when no order_by is specified, making it more performant
when the "name" of the many2one is not relevant, which is the case for
most back-end cases
closesodoo/odoo#84908
Task-id: 2479334
Related: odoo/enterprise#24877
Signed-off-by: Raphael Collet <rco@odoo.com>
If partner is copied, it will copy customer_rank/supplier_rank and it
will be treated as such even though such partner has no references to
invoices for example.
closesodoo/odoo#85102
X-original-commit: c0161736db4f2415e6a44674d872bf8aa2972287
Signed-off-by: William André (wan) <wan@odoo.com>
For this case is wrong use the company of the user, because you may in other company at this moment and the search is not
working properly.
The way to solve this is use the "env" company as use in the computed method.
closesodoo/odoo#84037
X-original-commit: ee264787841395a95162ae809928ee71fd1b7c84
Signed-off-by: William André (wan) <wan@odoo.com>
Some use cases require the use of the same account number on multiple
partners. This will relax the constraints to allows such use cases, and
adapt to avoid setting the partner or bank when we cannot be sure of the
one we should take (on bank statement line, and during reconciliation)
Task id #2692025closesodoo/odoo#81362
Related: odoo/enterprise#22881
Signed-off-by: Laurent Smet <las@odoo.com>
The goal is to ensure that 2 conditions are met for a fiscal position to
be applied (within the EU):
- The customer must have a valid VAT number from another EU Member State
- The goods must leave the country of origin
Task: 2596204
X-original-commit: ca0fc6cda38fd1e4d3c8cd8953bea790a90001f5
Part-of: odoo/odoo#81832
Expected Behaviour
When clicking on the "XX Unpaid Invoices" link on the main dashboard of the accounting app, we should get to a list view with only unpaid (and partially paid) invoices
Observed Behaviour
When cliking on the link, we get all the invoices, even the paid ones.
Reproducibility
This bug can be reproduced following these steps :
1. Create some invoices
2. Make sure some of them are paid and some are not
3. Go to the main dashboard
4. Click on the "XX Unpaid Invoices" link in the "Customer Invoices" app
Problem Root Cause
The problem comes from a change in the filter name from V14 to V15 ("unpaid" category has been replaced by "open").
Related issues
opw-2681099
closesodoo/odoo#79643
X-original-commit: 9212d07c5919470361b638f0e70c2069957c7d6f
Related: odoo/enterprise#22221
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Hendrickx Anthony (anhe) <anhe@odoo.com>
In case the address of the company is in a different country as its fiscal country, the taxes available as "source tax" on the fiscal position lines were not the right ones (the country of the address was used to fetch them).
closesodoo/odoo#79144
Signed-off-by: Laurent Smet <las@openerp.com>
Having the same VAT fiscal position for the same region multiple times doesn't make sense and is not supported by the report enfinge. We should prevent that.
closesodoo/odoo#77663
X-original-commit: d9dfeeb498dab359df52db87ff601d68fcf0ad7c
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
In multivat setup, we need to create taxes in foreign countries to map them with domestic taxes. Before this commit, this was only possible manually, even though all the necessary information lies in Odoo's account.tax.template objects created by l10n modules.
We now display a banner on top of foreign vat fiscal positions with a button allowing instantiating those templates directly from them when it's appropriate.
closesodoo/odoo#75803
Task: 2453325
Related: odoo/enterprise#20553
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
This reverts the following commits:
- 164409b00106a5f91d8b84ac698f4cf2aebedb91
- f11c807217cccd96fa18fe24c0cbb436bb1830d1
- c92ebc91e261827dfafa602eae5408de2a072609
The fix we initially made did not cover every possible scenario,
and applied to every fiscal position, which was not required.
It requires a more in depth rework that is under way
and will come in a future PR.
closesodoo/odoo#75284
X-original-commit: d470f2b4fbc7440d19d07268980394909c47ee22
Signed-off-by: Florian Gilbert <FlorianGilbert@users.noreply.github.com>
The goal is to take into consideration that in case the TAX ID
is issued by the same member state as the vendor's,
then VAT charge is not reversed.
The VAT ID must be foreign as from the vendor's point of view.
closesodoo/odoo#74566
Task: 2596204
X-original-commit: c92ebc91e261827dfafa602eae5408de2a072609
Signed-off-by: William André (wan) <wan@odoo.com>
Replace text fields to html fields as we have our own 'OdooEditor'.
Indeed, it gives more options to users in the way they format their
content without weighting too much on the UI
(tools appear on demand and not by default).
Models -> Fields
1) account.move -> narration
2) account.payment.term -> note
3) account.fiscal.position -> note
4) res.company -> invoice_terms
5) res.config.settings -> invoice_terms
Task Id: 2499504
X-original-commit: 0f3c7f153e8bd20f83b7d1df031634996d36935b
Have a Fiscal position FPOS which map tax A to tax B
Have products DEMO with tax A and DEMO2
Allow FPOS in POS, Open a session, activate FPOS, sell DEMO and DEMO2
Close POS
Go to Orders, select the last one, hit return, edit, delete DEMO2 line
Tax will be wrong.
This occcur because the fiscal position mapping fail an equivalence
check with a virtual record, so the tax is calculated as A and not B
opw-2485399
closesodoo/odoo#69952
X-original-commit: 983797e626f742e84710de7ec8487824d6eaa7f1
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Before, account_fiscal_country_id was only use for tax operations; and country_id was used for all the other accounting stuff. Now, with the new ability to use foreign tax reports (with foreign VAT fiscal positions), we can generalize the fiscal country, sot that it is the one that needs to be used for the whole accounting. Since foreign tax reports were not supported before, account_fiscal_country_id is already set on existing database as the country for the "main" accounting, so the impact of this change is small.
closesodoo/odoo#68349
Related: odoo/upgrade#2322
Related: odoo/enterprise#17299
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Such fiscal positions define an alternate VAT for a specific region. When foreign_vat is set, a country must be set on the fiscal position; it'll be used to know for which tax report the fiscal position must be available as an alternate VAT (in the tax report; see enterprise branch). Note that it is possible to defined several foreign VATs for the same country, as long as they belong to different states within that country.
Note that this new feature is only for FOREIGN stuff; so, when you have to submit a tax report in different regions than yours. For example if you have a Belgian accounting, have French customers, and have a French VAT in addition to your Belgian VAT, to submit a tax report in France. For domestic operations, simply use your the vat field of your company, just like before.
[IMP] account: add country_id on taxes and filter them on invoices
The invoices now compute the country from which they should accept the taxes: it's either the one defined by fiscal_position_id.country_id (if fiscal_position_id is a foreign VAT fiscal position, i.e. it defines a foreign_vat value), or the company's account_fiscal_country_id.
Taxes from other countries are filtered from the view; we don't want them to be available there. There is also a constraint ensuring that. Same goes for tax repartition lines and tags from other countries.
We don't want to mix taxes, tags and foreign VAT fiscal positions from different countries, as it would break the tax report in enterprise. Doing this ensures the tax report can efficiently discriminate the move lines between the different regions whose report they have to appear in.
[IMP] account: add country_id to account.chart.template
This is done so that the taxes are created in the right country, and the fiscal country is initialized in a consistent way when instantiating the CoA on the company.
[IMP] account: print foreign VAT on invoice instead of company VAT if one is defined
[IMP] web: allow forcing company vat on document templates
This is done to allow the use of foreign vat fiscal position on invoices: in that case, we don't want to use the company VAT, but the value of fiscal_position_id.foreign_vat. So, when such a value exists, the invoice simply set the force_vat variable to the right value.
[IMP] base_vat: also validate VAT of foreign VAT fiscal positions
We generalize the code formerly only done for res.partner so that the foreign_vat field of account.fiscal.position can be checked in the same way.
By counting the number of customers/suppliers before doing the query and
updating all at once, we can reduce the number of queries done quite a
lot for big batches of invoices.
closesodoo/odoo#56848
X-original-commit: b0e0035b585f976e912e97e7f95f66b525bc8e43
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: wan <william-andre@users.noreply.github.com>
Use _for_xml_id to replace all the self.env.ref().read()[0]
This has the advantage of having a single point of control and to add
the fields filtering and model verification.
Add sudo for other operations on ir.actions.*
Wrong usage of self in for loop
closesodoo/odoo#55334
X-original-commit: 5a0b06ab0447f2b09e71934f2cc3209e6ebe9359
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Add Total Receivable and Total Payable to contacts list view.
Create Vendor Bill for a partner with $0 Receivable and Payable - the
Payable amount is updated in the list view.
Create an invoice for this partner - the Total Payable is changed to $0,
and the Total Receivable is updated in the list view.
Create a Vendor Bill for a partner having a Receivable amount - the
Payable is not updated.
This occured after commit 9920f20e4c
In a situation in which the lines retrieved from the db are arranged
like
|pid| type | val |
|---|-----------|-----|
| 10| payable| 500|
| 14| receivable| 200|
| 14| payable| 300|
line 3 will cancel line 2 because partner credit will be set to false
after the debit update.
Fixing by checking that the same partner has not been processed yet
opw-2250989
closesodoo/odoo#51351
X-original-commit: 0274d61a11c6f5220d6af37a38adafb3e5276224
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Such a change breaks XML-RPC calls. Moreover, it allows the creation of
partners without the accounts set, which will cause inconsistencies
later on.
This reverts commit 29c362b7c3353c2be11ab117f454d04ed9853f75.
opw-2241875
closesodoo/odoo#49982
X-original-commit: f720602ac24246d29de4919f18ae7c32cce2ffc2
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
During the onboarding, if Invoicing is installed but no chart of account
is set the field property_account_receivable_id and
property_account_payable_id prevent from validating a new partner
because they are required but not auto-filled, and the fields are not
visible if Invoicing is not installed.
closesodoo/odoo#49732
X-original-commit: 29c362b7c3353c2be11ab117f454d04ed9853f75
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: wan <william-andre@users.noreply.github.com>
- Activate multi-currency
Company currency: USD
EUR rate: 0.14
- Set the decimal accuracy of Product Price to 5
- Create the following invoice in EUR:
Name Qty Price Unit Subtotal
A 38.0 38.73553 1471.95
B 222.0 4083.19000 906468.18
C 35.0 49.45257 1730.84
D 1.0 17.99000 17.99
- Save the invoice
- Edit the invoice and set a payment term, e.g. 30 days
- Save
There is a difference in debit and credit of 0.01 coming from the
following:
1471.95 / 0.14 = 10513.93
906468.18 / 0.14 = 6474772.71
1730.84 / 0.14 = 12363.14
17.99 / 0.14 = 128.50
SUM = 6497778.28
But the receivable account:
909688.96 / 0.14 = 6497778.285714286 => 6497778.29
When changing the payment term, all invoice lines are recomputed.
`price_unit` and `tax_ids` are in the list of the updated fields, which
triggers the synchronization of accounting and business fields. During
this synchronization, `_get_fields_onchange_subtotal_model` is called
and recomputes the debit amount, leading to the difference.
We only synchronize if the value of the business fields have changed.
opw-2209543
closesodoo/odoo#49605
X-original-commit: 70bd2c9c7a7c8ec832edd2c158f4f61b78cdeb37
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
There is a default filter on Posted, no need to add it in the domain.
This prevented seeing draft invoices.
closesodoo/odoo#48635
X-original-commit: ca67c83e8d36ececaf97a7579c3ff2529b3e227c
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Create a demo fiscal position with automatic detection enabled and
country group assigned (ex. Europe).
Create a new Vendor with such fiscal position assigned.
Create a product in which the product category has an account which can
be mapped with the demo fiscal position
Create a new Vendor Bill, select the partner, create an invoice line,
fill in the product: no fiscal position will apply
In the process of auto detecting fiscal position the company_id may be
enforced by the context and this would conflict when the fiscal position
company is unset. Adding a default False condition fix
the issue
opw-2192733
closesodoo/odoo#46508
X-original-commit: 57a4038554b00a487bf7b176dd780192654b136a
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Task 2092079
Accounting firms that want to give access to their customers avoiding
mistakes and risks will love this profile that can't do anything
wrong... Maybe as well as companies auditors..?
closesodoo/odoo#39860
Related: odoo/enterprise#6576
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Pretty straightforward so long as you know `current_company_id` is the
currently active company for the user, which is exactly what we need.
Task 2115472
closesodoo/odoo#41869
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Steps to reproduce:
-install the POS module
-install the Contacts module
-create or use an existing partner as a customer during the pos session
-go to contacts and activate the "customer" filter
-> partners used during the pos session are not showing in the list
The problem was that the 'customer_rank' property
https://github.com/odoo/odoo/blob/d8d7635d6cf2af60791f25201a7bd1c2d5ec238b/addons/account/models/partner.py#L430
was not updated properly after a pos account move was done
Previous behavior
After ending a POS session, partners that are created and/or used
during the session are not showing on the Contacts views when the
'customer' filter is active
Current behavior:
The customer_rank of the partners is increased by one for every sale
during the pos session
Partners created or linked during a POS session are now considered
customers and appear in the contact view when the "customer"
filter is active
opw-2148894
closesodoo/odoo#41792
X-original-commit: 22874376594f94232e0c4ad5a4db3ee76f24b39a
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Fabien Pinckaers