To enable VAT validation (VIES/ simple), the base_vat module needs to be installed.
base_vat extends models where the validation should apply. This means it only works with models in account, unless the module is added as a dependency (base_vat depends on account)
To avoid this dependency (in account reports - see enterprise PR odoo/enterprise#34068), two methods required for VAT validation are added to res.partner so that the enterprise module is able to use this feature with/without base_vat.
closesodoo/odoo#106046
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
.. to other deeper logic.
As spotted on the ticket, if there is an ARCHIVED outgoing
email server and an invoice is created after clicking
on the smart button of a Contact,
the active_test=False is propagated and the email is sent
using the archived outgoing mail server.
The propagation of this context key can impact a lot of
other logic and is even more risky in accounting.
Reverting fe9b460d29d6537e0c14af54ba31d935c746810b
is solving the issue.
The main error reported on 2853525 that led to this previous
commit seems also solved somewhere else (that I did not find)
opw-3217999
closesodoo/odoo#116136
X-original-commit: 3d82e5aa5bc5960f8fb04fa0b085f33547f05c27
Signed-off-by: William André (wan) <wan@odoo.com>
Refactoring send&print wizard.
==============================
Main reason for this commit is that we want to let the user
decide when to generate the relevant documents / approvals
for its invoices. The natural choice is when the information
leaves Odoo. So now, each time the users decide to
download/send its invoices, he will be able to select the
relevant documents to be generated and the approvals to be
requested from the send&print wizard.
This used to happen automatically during the posting with lots
of undesirable behaviors (difficulty to update/revert, hard to
know exactly what will happen,...)
Main changes:
1/ Send&print wizard
- The model 'account.invoice.send' has been replaced by
'account.move.send' and became models.Model to handle
asynchrounous generation of documents (webservice,..) in
case of more than one invoice.
- The wizard is meant to be overriden in order to add
checkbox and document to be generated. A comprehensive exemple
can be found in account_edi_ubl_cii.
2/ Import invoice from attachments
- The decoding logic has moved from account_edi to account
on the attachemnts.
- The function _extend_with_attachments() serve as a common
entry point for import (from chatter, dashboard).
3/ Export invoice pdf / document
- All the specific actions to export attachments should be
implemented on the account.move and called from the wizard in
_generate_documents()
- The official pdf for the invoice is now only generated once
the user request it. In order to regenerate the pdf and
documents, it needs to be deleted.
task-id: 3117238
[enterprise](https://github.com/odoo/enterprise/pull/36757)
[community](https://github.com/odoo/odoo/pull/111857
)
[IMP] web: enable close on ir.actions.act_url in wizard
Before this commit, calling ir.actions.act_url on a modal
leaves the modal open. Which feels ackward in the send&print
wizard.
We now enable 'close' parameter on ir.actions.act_url. If set,
the wizard will close after act_url.
closesodoo/odoo#111857
Related: odoo/enterprise#36757
Related: odoo/upgrade#4387
Signed-off-by: Laurent Smet <las@odoo.com>
Rewrite the whole chart template mechanism, removing the templates
stored in the database. The new format will mainly use CSV.
Speed up install time
---------------------
* About half of the time of installing a localization for the first time is
taken by creating the template records. This new in code format gets
completely rid of this.
* Creating the template records could often not be done in batch because
of parent/children relations.
* The instanciation of the accounts on the company has been entirely
reworked too, by
- optimizing the order of creation of records to avoid UPDATE queries
- using precomputed fields to avoid UPDATE queries
- updating the translation in batch
- deactivating logging in the chatter
- avoiding access rights checks by checking the rights at the start
Overall, when installing a chart template for the first time, it is 4
times faster because half of the time spent on saving the template in
the database is not done at all anymore, and the instanciation on the
company is more than twice as fast.
Reduce technical debt
---------------------
There is no need to synchronize the templates with the real records
anymore. No need to use hooks to copy the data from one to the other.
It is easier to change a template in a stable version, which can often
be necessary due to legal reasons (i.e. a change of tax rates, reporting
tags,...)
Two modules have been removed:
* `l10n_generic_coa`: since there is nothing left datawise in this
module, it can be integrated in `account` for free. It is just code
and CSV.
* `l10n_multilang`: the fields that this module modified to be
translatable are now always translatable:
- there was an issue when updating modules that deleted all the
translations because the fields were not translatable at some point
during the loading of the registry, then they because translatable
again but lost all translations because of the column type change.
- most devs are not able to understand all the languages needed for
all the localization available. Therefore, english has been added in
the sources in most localization to understand better issues while
debugging.
- no need to call post init hooks anymore, doing the sync with the
templates.
- more: see "Translations" section
Because most of the data is now in CSV, it is also easier for product
owners to edit, audit, modify files themselves, removing one layer
during trivial development processes when only data should be changed.
More flexibility for declaration
--------------------------------
The data declaration can now be done easily in python or CSV.
A nice feature is that you can declare everything at once, even for some
more complex chart of accounts:
* if you have to set default taxes on accounts, would need to
- declare the accounts because accounts are required on the taxes
- declare the taxes
- declare the taxes to put on the accounts
This would lead to scatter information in multiple files. Now,
everything can be declared in the same place and the loading of the
chart of accounts will do the 3 steps automatically.
* if you have a relation of child/parent, you would first need to
declare the parents then the children, and the loading would not be
efficient because done one by one. Now, everything is done in batch
automatically without having to think about it.
It is also easier to update fields on records where there was no field
for that on the templates, like
* setting a restriction for journals on accounts
* setting specific values on the company
* modifying journals and linking them easily by using the xml_id instead
of having to compute it manually
Translations
------------
Some countries have multiple languages (i.e. Belgium uses officially
French, Dutch and German, and the CoA also has an official English
version) and we must support the languages in all these countries.
All these translations are known, and hard coded without using out
translation platform (Transifex). We also like to have the English
version (even if an official one doesn't exist) so that support can be
done more easily in databases using chart templates in other languages
(especially using a non roman alphabet).
Because the translations were not on Transifex for these records, it was
really hard to maintain: the translation templates (`.pot` files) were
not easy to extract as the automatic export would give values mixing
both the CoA and the menuitmes, the fields' strings,... But we don't
want to translate the CoA as we already know the value.
Managing the translations in the `.po` files was also annoying:
- it is easy to forget that the translations need an update too
- it requires a special editor, special terminal commands that everyone
is not familiar with
- it is easy to make mistakes in the source string
The new format is the following: `field@en_US` where `field` is the
translatable field (usually `name`) and `en_US` is the locale code.
This allows to have the whole declaration on one line, everything in one
file. It also makes the process easier when debugging: instead of
searching for the translation in the `.po` files, it directly appears
next to the configuration of the account/tax/... .
Update of the code
------------------
The code can be updated using this script
https://github.com/william-andre/transform_coa
Forward ports can be managed too by stashing/resetting/checkout the new
modules or the changes in the modules updated in the same PR.
task-2687567
Part-of: odoo/odoo#110016
Many country-specific fields were displayed while a company with another country was selected (in case of a multi-company environment).
These country-specific fields are now visible only if one of the selected companies with said country is selected.
closesodoo/odoo#106221
Related: odoo/enterprise#34226
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Improved the tooltip description of the 'Detect automatically' field for fiscal positions. The previous tooltip was "Apply automatically this fiscal position" while the new one is "Apply tax & account mappings on invoices automatically if the matching criterias (VAT/Country) are met."
task id : 3088331
PR number : #107092
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
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>
2 fixes are made:
* We use a FOR NO KEY UPDATE instead of FOR UPDATE because we don't want
to prevent the insertion of lines referencing the partner as a foreign
key (i.e. new invoices).
The data is purely informative and the exact value isn't too important
anyways.
* We catch SerializationFailure on top of the previously catched
LockNotAvailable. It can happen in this use case
- T1 and T2 start
- T1 acquires the lock and updates
- T1 commits
- T2 acquires the lock: it gets it because T1 released it
- T2 updates: T1 did it as well so there is a serialization failure.
X-original-commit: b1491b7663e4c6c675e88a172e4b0a812e9b00a3
Part-of: odoo/odoo#106325
Some countries, such as mexico, require a seller to be able to
generate an invoices from a ticket from a sale done in a shop,
even after a few days.
This change aims to allow this, by allowing to create an invoice at
a later date after the POS has been closed.
This is done by partially reversing the POS closing entry, and then
generating an invoice the same way it would be done at the POS closing.
The customer can scan a QR code if enabled in order to request the
invoice by himself, requiring him to fill a for to give the customer
information required for the invoicing.
Allows to fill additional fields dependent on the localization that are
required to be set on the partner or the invoice.
Task id #2946604closesodoo/odoo#97675
Related: odoo/enterprise#30599
Signed-off-by: Laurent Smet <las@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
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>
Habib (ayh)