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>
-Create a random journal entry affecting the partner A, using a receivable/payable account.
-Let the journal entry in draft.
=> The amount set on the line must not be sum in the partner's amount_due.
closesodoo/odoo#36973
X-original-commit: 3ab4589ff444da9889ac922ac9d7ba6c8e8638bc
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before Commit:
The statbutton on partner form does not work properly.
After Commit:
we change the domain because use the wrong domain in filter so
statbutton not work properly on partnerform.
task-id : 2041822
closesodoo/odoo#35290
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Task 1986647
With the reworking of the account_report_followup module, these variables and methods are no longer needed. Now everything is done with followup levels, with only one level by default
Also rename account_report_followup to account_followup.
closesodoo/odoo#35772
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
When making a test import for new users, there don't be present
in DB, so the computation of the customer/supplier rank will raise
an error.
Manage the case when user is not yet present in DB.
closesodoo/odoo#35955
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
To correctly choose in which account a line should be posted,
we have to know if the partner is a customer or a supplier.
Specification
=============
Keep track of the number of account moves "in" and "out"
a partner has. These counts should be based on the posted
account moves. A customer that has been created from the
'Customer' menuitem will have a rank=1. When a customer
invoice will be created for him, the generated account moves
will be taken into account to compute its rank. The most
invoices we have for a partner, the higher his rank is.
Note: To avoid any concurrent update failures on the partner,
if one transaction has already locked a partner row, the count
update will be skipped that time.
This means the values may be approximative in the database!
The exact values will eventually be correctly computed at
the next successfull try.
Known limitation of this approach: The computation ignores
the set of currently selected companies. Actually, storing
context dependent values in the database is a bad practice,
and is avoided in that case by taking all the companies into
account.
Use the stored fields `customer_rank` and `supplier_rank`
to order partners when searching by name. This allows to show
best customers or best suppliers on top.
To choose if best customer or supplier are shown on top,
the context key `res_partner_search_mode` is used.
The context key can take two values: 'customer' or 'supplier'.
This decision partially reverts/revamps 8766f38 to only use
account moves instead of PO and SO
On actions showing partners, set a default filters to menus to
only display customers (customer_rank > 0) if the string is
"Customers", and only suppliers if the string is "Vendors" or
"Suppliers".
TaskID: 2049131
closesodoo/odoo#35942
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
