Some countries, such as Portugal, persons also have VAT-like tax
numbers, that can be used in invoices, just like company VAT numbers
can.
However, the VIES service does not work for these person VAT numbers,
only for companies.
This fix ensures that VIES validation is only used for companies.
closesodoo/odoo#80521
X-original-commit: 87028f8b08628b8c643d84b0c19810470f540533
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: Daniel Reis <dreis.pt@hotmail.com>
Co-authored-by: Ricardo Gomes Rodrigues (rigr) <rigr@odoo.com>
https://github.com/odoo/odoo/pull/68253 fixed a bug in check_vat that caused it not to run any check when called on a partner with no country.
However, doing this caused another issue because of an ORM limitation: when writing vat and country_id with a single write() on the res.company, two distinct write are triggered on the related res.partner, one for each field. Both those write trigger the check_vat constraint.
Depending on the order in which the keys of the dictionnary passed to res.company's write were ordered, country_id could or could not be written before vat. If vat was written first and did not start with a country code, the write() on res.partner failed the constraint, because country_id wasn't set yet. This was wrong, but used to pass as there was no country_id on the partner, before https://github.com/odoo/odoo/pull/68253 fixed that.
To circumvent the issue, we now allow entering any vat number without performing any check if it does not start with a country code and no country_id is set on the partner.
closesodoo/odoo#69243
X-original-commit: 7036b671228fdb5986b4f62a610a2e4d4132b8b1
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Before this, when making a partner without any country_id, any VAT could be set to it, which was inconsistent with the module's purpose.
closesodoo/odoo#68815
X-original-commit: 72606f14d0c1d86d7a205fd29aec8d66d3e98678
Related: odoo/enterprise#17505
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
The function was wrongly imported and used, and it was hidden by a
generic catching of all exceptions.
The return value and some legit exceptions were also badly handled:
* The return value was always thruthy as it returns an object containing
information about the check.
* Exceptions can be raised if the format is not correct. In that case,
we don't want to go to the simple vat check.
Fixes#64897
opw-2451951
closesodoo/odoo#66522
X-original-commit: e711f359fef7ed4c37cb26d3946744e140bf00e0
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit, a lot of leftover import shims existed in the
codebase for py2-py3 compatibility, these are no longer needed since
Odoo 13.0+ doesn't support Python 2 anymore and is (finally) in EOL.
With this commit, these shims are dropped, making the code cleaner,
easier to read and with one less dependency.
Queue -> queue -> py2-py3 compatibility
xmlrpclib -> xmlrpc.client -> py2-py3 compatibility
ConfigParser -> configparser -> py2-py3 compatibility
itertools.izip_longest -> itertools.zip_longest -> py2-py3 compatibility
urllib -> urllib.request -> py2-py3 compatibility
__builtins__ -> builtins -> py2-py3 compatibility
_winreg -> winreg -> py2-py3 compatibility
mock -> unittest.mock -> merged into CPython
The debian/fedora packages and requirements.txt have been updated accordingly
closesodoo/odoo#44601
Related: odoo/enterprise#8141
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Create a new contact with:
- Name [DEMO]
- VAT RORO790707I47
- Country Mexico
An error inform the user that the vat is not valid, this happens because
the vat number is recognized as romanian and compacted before passing
to actual vat checking. Skip the check if the country of the new
partner does not match what is detected on the vat, assuming the user
know what he/she is doing
opw-2218491
closesodoo/odoo#48273
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The synchronisation of commercial_partner_id was introduced at
0d68acff8e as a way to ensure the value is always correct.
The order or the operation was not important though.
This synchronisation has a side effect in the following scenario:
0. install base_vat
1. disable vat_check_vies in the settings
2. set an invalid VAT number on a company with at least one contact
3. enable vat_check_vies in the settings
4. correct the VAT number on the company with a valid one
--> an error was raised for an invalid VAT number on the contact
This is because the commercial_partner_id synchronisation is done
before the update of the VAT number. Even if the value has not
changed, this triggers the check_vat method.
Invert both instructions
Courtesy of Wolfgang Taferner
Closesodoo/odoo#43065Closesodoo/odoo#42973closesodoo/odoo#47543
X-original-commit: d9b2605eadc129924d085fffc4056d777cfbbbeb
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
base_vat: Correct management of the check of peruvian VAT without prefix.
l10n_pe: Correct income account the last one is not correct.
l10n_pe: Forced Round globally for peruvian companies once l10n_pe is
installed, and with the onchange.
l10n_pe: For peruvian companies it does not make sense a sequence per
year and the year in the prefix is incorrect, we must force XXX- as
a sequence prefix.
closes odoo/odoo#38854
Forward-port-of: #38764
Signed-off-by: Josse Colpaert <jco@openerp.com>
