-
Notifications
You must be signed in to change notification settings - Fork 59
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
Validating Belgium VAT numbers without leading zero #76
Comments
See https://github.com/DragonBe/vies/blob/master/src/Vies/Validator/ValidatorBE.php#L37 IMO a validator should validate. Perhaps a ValidatorException would work. Or, the keep it easy, return false :) |
Well, a Belgium VAT number without a leading zero isn't valid. So actually the ValidatorBE should not add the leading zero. But if it does, then that should also be used when the VAT number is send to the VIES service. So in my opinion, add it, or not. But if it is added, also in the VIES service. Otherwise the Validator says it is ok, and the VIES always will reply false. |
I've looked at our solution and I'm agreeing with both of you. Yes, we're adding a leading 0 if the amount of numbers equals to 9 which should not occur. I also agree that older VAT ID's in Belgium with only 9 numbers (and not having a leading 0) are valid and should be validated by the backend VIES service provided by the European Commission. So I searched for some public Belgian VAT ID's with only 9 numbers and validated them against the online VIES service and guess what?!? The service itself returns it as INVALID! My test values are:
But when I add a leading "0" (zero) to the validation service, the validation passes and I get good results. Which allows me to conclude that our action to add a leading 0 in front of the entered VAT ID was a good move, but we should be consistent and pushing that modified number also to VIES so we get a valid result back. Of course, in the response we should indicate that the validation only occurred when we added the leading 0, just like VIES does in their own response (see screenshot above). So I ask both of you (@timo002 & @cottton): should we or should we not make the modification for the user so we pass the online validation and remove our modification in the offline validation? Bear in mind that the regulation for businesses is to add a leading zero in all their publications. This was handed to me on a paper back in the day when I registered our own company (which I no longer poses). |
I think that you should not add the leading zero in the validator. If someone forgets the leading zero, it is a wrong VAT code. Even if a user forgets it by mistake, it is still a wrong VAT code. I see it this way, if the user can omit the zero and the validator puts it in front of it. Then the user could also omit the last checksum, the validator could also calculate it. In my case, I will prefix the leading zero if a user forgets it. I do this before I even call the VIES class. |
First: how do we get updated vatNumber to the user:
BTW: vatNumber gets changed anyway at: Changes in short:
Note: added notes like #DISABLED - ... and ## todo ... which should be deleted before release. ... Validators now CAN manipulate the value, but caller (in this case Vies it self) must call the Works on my side. I put a PR but this contains notes ect. Please check on your side and unit tests. Delete those notes before merge(?). PR: #77 |
@cottton, thank you for your PR and I really appreciate the work you have put into the sanitisation of the VAT number. But after giving this some really good thought and talking to several people who deal with VAT a lot more than I do, I have to lean towards the remark @timo002 made: keep the input as it is, if the user omits the leading 0 the validation of this library should fail. Even though the VAT number used to be valid, in this day and age the Belgian VAT ID should contain 10 digits and the first digit is a "0" (ref. https://financien.belgium.be/nl/ondernemingen/btw/aangifte/aanvang_wijziging_einde_activiteit#q1 [DUTCH]). |
Guess my pre-commit hook to run phpcs wasn't working properly, my bad
No problem =)
Actually the input gets filtered ( It just changes the format - like a datetime string. |
The goal of this application is to validate the input so this internal change should not happen IMO. Like I mentioned in #76 (comment) when I use the VIES service directly, it rejects Belgian VAT ID's without a leading 0 so should this library also reject it, even if it's easy to correct it. |
Thats what i mean too. I agree =) Like a Datetime string. Same value, different format. All fine. |
When validating a Belgium VAT number, they should start with a zero (after the country code). The ValidatorBE class fixes this nicely when it validates the number. If the number is 9 chararacters long, it will be prefixed with a zero.
The function validateVatSum then returns true and the VAT number is processed to the VIES service through a SOAP call. But the VAT number send to VIES is without the leading zero and thus it is validated false.
So it has no point of adding the leading zero if this is not also send to VIES. I would advise to also send the VAT number with leading zero to VIES. Or otherwise validate a VAT number without the leading zero as invalid directly in de ValidatorBE class.
The text was updated successfully, but these errors were encountered: