-
Notifications
You must be signed in to change notification settings - Fork 9.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove leading Countrycode from EU-VAT-Numbers #17385
Conversation
EU-VAT-Numbers has always leading Countrycodes. To validate VAT-Number we have to remove it before sending the request. After we've checked if country is in eu we will remove the Countrycode and send the request.
Hi @Drischie. Thank you for your contribution
For more details, please, review the Magento Contributor Assistant documentation |
@@ -184,9 +184,9 @@ public function checkVatNumber($countryCode, $vatNumber, $requesterCountryCode = | |||
|
|||
$requestParams = []; | |||
$requestParams['countryCode'] = $countryCode; | |||
$requestParams['vatNumber'] = str_replace([' ', '-'], ['', ''], $vatNumber); | |||
$this->isCountryInEU($countryCode) ? $requestParams['vatNumber'] = str_replace([' ', '-', $countryCode], ['', '', ''], $vatNumber) : $requestParams['vatNumber'] = str_replace([' ', '-'], ['', ''], $vatNumber); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Always put variable like $requestParams['vatNumber']
out of ternary operator.
Moved variable $requestParams[] out of ternary operator. To do this, the new variables $vatNumberSanitized and $requesterVatNumberSanitized are introduced.
Changed one-line ternary to multiline ternary to not exceed line-size-limit of 120 Characters.
Small remark here, the VAT number sanitisation is only done for validating against the VIES service, right? So this means that when customers enter their VAT number with a country prefix or without a country prefix, both will be seen as valid (very good, I'm all for it!). But both will be stored in the database in a different format. I'm just not sure if shop owners would appreciate inconsistently formatted VAT numbers? |
Changed newly introduced variable VatNumberSanitized to reqVatNumSanitized to meet coding standards.
@hostep You're right but VAT-Numbers will always be different in the Database cause they are different =D |
Indeed, but if VAT numbers can be entered with or without the country code, shouldn't it make sense that we try to save them consistently in the database as well. So they either all have the country code or none have the country code. And maybe also with spaces and dashes removed, so they all are formatted in the same way in the database? I'm not saying it should happen, this is only a remark to see what other people think about this. (Additionally, I just remembered this very old ticket I once created a long time ago, and the solution in this PR kind of solves point number 3 mentioned in there 😉) |
Hi @Drischie. Thank you for your contribution. Please, consider to port this solution to 2.3 release line. |
We did also develop a complete module to fix this behavior, including handling of countries like Greek and many more. |
Description
EU-VAT-Numbers has always leading Countrycodes. To validate VAT-Number we have to remove it before sending the request.
After we've checked if country is in eu we will remove the Countrycode and send the request.
Fixed Issues (if relevant)
EU-VAT-Numbers always invalid cause of leading Countrycodes.
Manual testing scenarios
EU-VAT-Numbers looks like DEXXXXXXXXX for a german one.
Before change:
Giving DE 293 778 674 in Configuration->General->Store Information or in creating an Account will resullt in "Invalid VAT".
After change:
Giving DE 293 778 674 in Configuration->General->Store Information or in creating an Account will resullt in "VAT-Number is valid".
Contribution checklist