The issue:
Currently, in Indonesia, the regulation for tax ID is 15 digits.
But a new regulation is coming where Tax ID is now 16 digits by adding 0 in front
The fix:
Remove the first zero and leave the rest for the _run_vat_test function
Related PR: #146111
opw-3782636
closesodoo/odoo#157885
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
The API of zeep changes according to the version of zeep.
We want to limit the number of used methods and attributes
of the zeep client by our developers.
Hence, we provide our own zeep Client limited to the
attribute and method we really need.
In addition, a timeout for GET/POST requests
should be applied by default when creating a new Client,
which is not the case by default.
We override that behavior to always provide a default timeout,
and an easier API for developers wanting to change
the default timeout.
Before it was needed to import `Transport` from `zeep`,
instanciate that `Transport`, with a timeout and optionally
a session, and then pass that transport instance to the creation
of the Client.
We provide a way to directly pass these timeout parameters
through the Client constructor.
In addition, we serialize the returned values of Zeep service operation
calls, to make sure we return simple types in methods of models
e.g. bools, integers, string, ...
According to https://www.easytax.co/en/countries/greece
the vat number format for Greece is EL123456783
instead of GR12345670.
We also delete the line for country code `el`
from `_ref_vat` dict as we use `gr` for Greece.
opw-3845662
closesodoo/odoo#161955
X-original-commit: b97c74e43638d685b2af8ede4940f37b6a5cd031
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
`base_vat.view_partner_base_vat_form` creates a new div `vat_vies_container` referenced by other views such as `l10n_mx_edi_stock.mx_partner_operator_form`
All these extension views have the same priority and in this case the later is trying to access the div before it is even created.
We fix this issue by changing the priority of the view that creates the div from 16 to 15.
closesodoo/odoo#161902
X-original-commit: 67e7289296ea12e69cb07864a2974cd5d4e46cf2
Signed-off-by: William André (wan) <wan@odoo.com>
Currently some VAT examples that contain other terms than only the
number are always displayed in English. This commit makes sure they can
be translated.
closesodoo/odoo#159724
X-original-commit: 504240b8633aac91eee421f3268550a1c04142a2
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
Having the VAT VIES Check valid field directly next to the VAT number
as an inline element becomes unreadable, so we wrap it add padding and text-nowrap
closesodoo/odoo#159332
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce:
- Activate "Verify VAT Numbers" option in the Settings
- Go to Contacts and create a new one
- Enter a valid EU VAT Number
Issue:
It happens that VIES service could not process the VAT number for some reason
and returns an error.
That error is silently caught without notification to user and "Intra-Community Valid"
field is set to False.
The user will wrongly think that the VAT number is not valid, but it hasn't been
processed at all.
Here's the list of the potential errors returned by VIES service:
- INVALID_INPUT
- INVALID_REQUESTER_INFO
- SERVICE_UNAVAILABLE
- MS_UNAVAILABLE
- TIMEOUT
- VAT_BLOCKED
- IP_BLOCKED
- GLOBAL_MAX_CONCURRENT_REQ
- GLOBAL_MAX_CONCURRENT_REQ_TIME
- MS_MAX_CONCURRENT_REQ
- MS_MAX_CONCURRENT_REQ_TIME
Solution:
Log a note with the error (as it is done for some other error) to warn the user that
the VAT number hasn't been processed.
opw-3687968
closesodoo/odoo#155525
X-original-commit: a15e5430d46b48821f062ffe07fd979b2f19a234
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
The xpath used in the res_partner_view replaces the vat field with
a div, containing the partner vat and the VIES valid field (such that
they are displayed on a single row). This results in the
partner-autocomplete being removed from the field.
The solution is to make a div, and a subsequent xpath that moves the
"vat" field into this div (alongside the vies valid field). This no
longer overrides the partner-autocomplete xpath.
closesodoo/odoo#154506
Task-id: none
X-original-commit: ffc8441b4ba09e3d10f15425c32f8fdb3fb7d863
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
Co-authored-by: aliya <alta@odoo.com>
There are multiple types of Identification Numbers in Romania and if you invoice
to a natural person, you are also required to send an electronic invoice.
Thus, we will add a check to allow the two TIN numbers that needs to be correct.
Example of valid tax number 'RO1234567897 or 'xyyzzaabbxxxx' or '9000xxxxxxxx'.
-Tin1: For xyyzzaabbxxxx, 'x' can be any number, 'y' is the two last digit of a
year (in the range 00…99), 'a' is a month, b is a day of the month, the number 8
and 9 are Country or district code
-Tin2: 9000xxxxxxxx, start with 9000 and then is filled by number (range 0 to 9)
Also stdum also checks the CUI or CIF (Romanian company identifier). So a number
like '123456897' will pass.
This commit will remove some test that are not relevant anymore since we can't
apply a vat number that don't follow the legal convention.
closesodoo/odoo#152649
Task: 3716671
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
For a first iteration, Russian translations were done using DeepL using
1 large .pot file of all the standard modules to translate (e.g. no
localizations, no test modules, etc). Unfortunately for some reason
doing a msgmerge with the existing ru.po files didn't seem to work, so
old "Translators" metadata at top of files were lost (maybe they will be
re-added during next Transifex sync?)
Part-of: odoo/odoo#152285
Recently, the vat validation was changed to
support 16 digits vat introduced in Indonesia
in January 2024.
This change replaced the stdnum validation,
but did not handle vat numbers written using
the standard presentation format.
This is fixed here, where we will remove the
characters used in this format and strip the
vat before doing the validation on the digit
amount.
closesodoo/odoo#148386
X-original-commit: 4c8629228f7842501d5a067451abca24d1089bf9
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Description of the issue/feature this commit addresses:
On the first of Janurary 2024, Indonesia will use 16 digits VAT numbers in
addition to 15 digits ones. This commit makes it possible to use any of these
two possibilites when entering the VAT number on an indonesian company.
Desired behavior after this commit is merged:
This commit makes it possible to enter either a 15 or 16 digit VAT Number on
an Indonesian company.
task-3636748
closesodoo/odoo#147215
X-original-commit: aae3495334f02eaf43e0396b040b75c926406fbd
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Signed-off-by: Thomas Becquevort (thbe) <thbe@odoo.com>
Summary
-------
Foreign companies that trade with non-enterprises in the EU may have a
VATIN starting with "EU" instead of a country code. However, the tax ID
validation does not account for that.
Steps to reproduce
------------------
* install base_vat and contacts
* create a Canadian company with a tax with the format EU00000000
=> you should be met with a validation error.
opw-3551347
closesodoo/odoo#146049
X-original-commit: 6e11c34c660cecea7e8a0b56f7f8f3baba70b0c9
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Summary
-------
Currently, adding a CPF tax ID on a Brazilian contact always fails.
Steps to reproduce
------------------
* install `contacts` and `base_vat`
* create a new contact with country Brazil
* enter a valid CPF (ex: 11144477735)
You should be met with an error
Cause
-----
The CPF check is only implemented in `l10n_br`. Without this module, the
default vat check is applied, but it fails for CPF numbers.
Fix
---
Move the CPF/CNPJ check from `l10n_br` to `base_vat`
opw-3421476
closesodoo/odoo#139222
X-original-commit: 5dc5832f438006a9a4b9abeb1f093d7ed520c771
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Before the fix the check function is assigned a boolean, which causes an
error when trying to call the function.
After the fix the result of the check is returned.
closesodoo/odoo#139407
X-original-commit: ea2798c5893373d79f70959e4501d0eef4f964b7
Signed-off-by: William André (wan) <wan@odoo.com>
In Hungary, the tax id can be valid in different distinct ways. Either by
putting a vat number looking like 'HU12345678' (EU VAT) or '12345678-1-12'
(native format) or 8071592153 (Indiviual). To do the different check we added
regex to check if it matches one of the three ways, otherwise a validation error
will be thrown.
closesodoo/odoo#139183
Task: 3522940
X-original-commit: 0504d98165c79499ee5d6c4263a33f66d96f9489
Signed-off-by: William André (wan) <wan@odoo.com>
Currently, when the user enters a value of `VAT` like '/' or
any single character, an error occurs.
Error: "IndexError: string index out of range"
This is because the recently applied PR [1] added a Line [1] that tries to
access the second digit of VAT, but the user added only one character.
This commit fixes the above issue by accessing the second character
when the length of the VAT is more than one character.
PR [1]-https://github.com/odoo/odoo/pull/136146
Line [1]-https://github.com/odoo/odoo/blob/422625615b2f6708667fa44d2a9e83ad3e66e5af/addons/base_vat/models/res_partner.py#L92
sentry-4524865338
closesodoo/odoo#138454
X-original-commit: 57f59f2088c46f4603ff83bbcf2db42d705331fe
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: ANSARI MAHAMADASIF (maan) <maan@odoo.com>
Description of the issue/feature this commit addresses:
As of the first October 2023, some Japanese companies will start using "T" as
country code in their Tax ID. The current vat check only allows the country
code to be used in the Tax ID which means that "T" is refused.
Desired behavior after the commit is merged :
This commit makes it possible for Japanese companies to use "T" as a
country code in their Tax ID.
task-3515786
closesodoo/odoo#137455
X-original-commit: 114e31521beb1d00f85f8a19959006dfe62708a0
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Thomas Becquevort (thbe) <thbe@odoo.com>
This adds the two main identification types we use in Brazil. CNPJ is
used the standard VAT type. The custom check_vat logic was removed
because stdnum supports this out of the box.
Another non-VAT CPF type was added that is checked for validity using
stdnum as well.
task-3475609
closesodoo/odoo#132773
Related: odoo/enterprise#46127
Related: odoo/upgrade#5062
Signed-off-by: Josse Colpaert <jco@odoo.com>
While creating a customer, if the user selects France as the customer's country
and then enters an invalid input into the VAT field, such as (FR), which is not
a valid input required, the user will encounter an error.
steps to produce:
- Install base_vat.
- Invoicing > Settings under Taxes check Verify VAT Numbers.
- Invoicing > Settings > Customers create a new customer, enter name, country
as France, an invalid input in VAT eg. (FR)
Error: `Fault: INVALID_INPUT`
This commit changes the exception to a warning since this issue will be
encountered every time the user enters an invalid input into VAT. Although we
have handled it with a Validation Error and added a note in Odoo, a
traceback is generated everytime. Therefore, to handle this, the exception
is changed to a warning.
sentry-4234933702
closesodoo/odoo#132491
X-original-commit: a5b88f483977c478f26bc224bfea115da1e63819
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Saurabh Mishra (sami) <sami@odoo.com>
Allow sharing records between company
* accounts
* taxes
* fiscal positions
* products
* ...and some related models
These records can be read and used in children companies.
This can be used to
* have different branding for different businesses
* allow more complex security rules
* consolidate branches differently
* manage different tax reports with different tax ids in the same
country
task-3371677
closesodoo/odoo#125642
Related: odoo/enterprise#43215
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
The tooltip for the VIES vat check option on the res_config settings is
no longer relevant or accurate. This commit adds a new tooltip and a
translation term for it in the pot file.
task-3218194
closesodoo/odoo#123928
X-original-commit: 83810d56765f7bc8d8e4ddfce10acc0462a317a4
Signed-off-by: William André (wan) <wan@odoo.com>
- We refactored the VAT validation from a validation error to a warning that is stored in l10n_ec_vat_error
- Remove the "-" and "EC" from the base_vat in the EC validation/example
- Only validate the length in the base_vat
- Add compute field with the warning message in the l10n_ec
closesodoo/odoo#123708
X-original-commit: 19b9384867485ea5fc30bac9192a21a91335f567
Signed-off-by: Josse Colpaert <jco@odoo.com>
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>
At present the user can select an option in the settings to check VAT
numbers against the VIES system. If the VAT number fails this
validation the result is a non-blocking banner message that informs the
user that the VIES validation has failed, but has no further
ramifications (the user can still use an unrecognised VAT number).
This non-blocking functionality is still desirable, however we wish to
determine the validity of certain fiscal positions based on whether the
VIES VAT check is valid.
In order to acheive this, the computed boolean `vies_valid` field is
added, and populated based on the results when comparing the VAT against
the VIES system. It depends on the `vat` and `country_id` of the
partner. If it looks like the VIES check needs to be performed on this
vat and if any company in the db requires a VIES vat check, the check is
performed, and if none do, then check is not performed. The field can be
manually edited, but is also tracked.
Provided we know whether a partner has a valid VIES vat or not, it is
only important sometimes in trying to find the appropriate fiscal
position (because VIES is only confirms validity of a VAT number for
intra-community trade). Because of this, a computed boolean field
called `perform_vies_validation` is added to represent this on the
partner. For example if a partner is from the same country as the
current company, then it doesn't matter that it's VIES valid or not, all
that matters is that there is some string in its vat field for the "VAT
Required" to be satsified, so the `perform_vies_validation` field would
be False. This field is also used to determine whether the `vies_valid`
checkbox should be shown or hidden on the partner form view.
A hook called _get_vat_valid is placed in the method on fiscal position
that retrieves the appropriate fiscal position for a given account move,
and it is overridden by a function in base_vat, which specifies whether
the partner/delivery address matches the 'vat_required' condition when
VIES validity is relevant for the company/partner (see the above
`perform_vies_validation` field).
`sale_stock` and `test_mail` performance tests are updated in order to
account for the additional queries introduced in the _get_vat_required
hook (in fetching the base.europe country ids) and the
_compute_vies_valid respectively.
closesodoo/odoo#116391
Task-id: 3218194
Related: odoo/upgrade#4498
Signed-off-by: William André (wan) <wan@odoo.com>
Odoo Translation Bot