Skip to content
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

Merged
merged 6 commits into from
Sep 4, 2018

Conversation

Drischie
Copy link
Contributor

@Drischie Drischie commented Aug 6, 2018

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

  • [x ] Pull request has a meaningful description of its purpose
  • [x ] All commits are accompanied by meaningful commit messages
  • [x ] All new or changed code is covered with unit/integration tests (if applicable)
  • [x ] All automated tests passed successfully (all builds on Travis CI are green)

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.
@magento-cicd2
Copy link
Contributor

magento-cicd2 commented Aug 6, 2018

CLA assistant check
All committers have signed the CLA.

@magento-engcom-team
Copy link
Contributor

Hi @Drischie. Thank you for your contribution
Here is some useful tips how you can test your changes using Magento test environment.
Add the comment under your pull request to deploy test or vanilla Magento instance:

  • @magento-engcom-team give me test instance - deploy test instance based on PR changes
  • @magento-engcom-team give me {$VERSION} instance - deploy vanilla Magento instance

For more details, please, review the Magento Contributor Assistant documentation

@magento-engcom-team
Copy link
Contributor

@Drischie thank you for contributing. Please accept Community Contributors team invitation here to gain extended permissions for this repository.

@@ -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);
Copy link
Contributor

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.
@hostep
Copy link
Contributor

hostep commented Aug 7, 2018

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?
This is just a remark, hoping to spark some discussion.

Changed newly introduced variable VatNumberSanitized to reqVatNumSanitized to meet coding standards.
@Drischie
Copy link
Contributor Author

Drischie commented Aug 10, 2018

@hostep You're right but VAT-Numbers will always be different in the Database cause they are different =D
EU-Vat have always leading Countrycodes, others don't. So i have to save EU-Vat in Database including Countrycode to show me the right one but i have to remove Countrycode to check against VIES.

@hostep
Copy link
Contributor

hostep commented Aug 10, 2018

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 😉)

@magento-engcom-team magento-engcom-team merged commit 4d50006 into magento:2.2-develop Sep 4, 2018
@magento-engcom-team
Copy link
Contributor

Hi @Drischie. Thank you for your contribution.
We will aim to release these changes as part of 2.2.7.
Please check the release notes for final confirmation.

Please, consider to port this solution to 2.3 release line.
You may use Porting tool to port commits automatically.

@roman204
Copy link

We did also develop a complete module to fix this behavior, including handling of countries like Greek and many more.
https://github.com/CopeX/CopeX_VatFix

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants