Add support for Panama TIN

[unho]

Note this only adds support for the legal person's TIN number.

Adding support for Natural persons should be fairly easy based on the algorithm descriptions in https://studylib.es/doc/545131/algoritmo-para-el-calculo-del-digito-verificador-de-la-ru and the Python script at https://github.com/apple314159/panama-dv The reason why I didn't add support for those is that it would complicate the compact method, and will require performing plenty of tweaks when calculating the check digit, and this doesn't seems straightforward when we don't have plenty of examples for some of these variants.

Closes #102

[unho]

@arthurdejong I am not sure what is wrong with the CI. It says there are some lines of code not covered by tests, but I am pretty sure I have added specific tests for those. Any idea?

[unho]

@arthurdejong I have managed to figure out what was wrong. PR ready to review.

[arthurdejong]

The output of this function seems to be something that does not resemble any of the formats that are used. From an initial glance it seems that the - separators are not optional but rather part of the number. The idea of the compact() and validate() return values is that they are still considered valid numbers. It appears they are considered valid identifiers in this code but it is unclear if this a normal way to represent a RUC in Panama.

[unho]

I thought that that was the purpose of the format function, and that compact was meant to reduce the number to the minimal representation so it could be used by the rest of the functions.

The - are usually present because people omits the leading zeroes on each of the parts of the number. By ensuring those zeroes are present (using zfill) we are able to return the whole number, still being valid, without the - separators. Or at least that is my understanding of the situation.

[unho]

• If you go to the online website to verify the DV (https://etax2.mef.gob.pa/etax2web/Login.aspx then go to Registro, and then to Dígito Verificador, then select Juridica in the form)
• Then enter the values to verify 253-92-57027 it indeed returns a DV 76 and it identifies a company.
• If then you try again adding leading zeroes it still returns the same DV, but it gives some error.

IMHO this error might happen because in their database probably the RUC are stored without the zeroes, and then the website doesn't find a match.

I have quickly checked and I didn't find any example with those leading zeroes, but we also have to keep in mind that in order for the algorithm to work it requires all those zeroes.

In other words, I don't know whether the version with the zeroes and no separators is invalid or not. What do you think?

[arthurdejong]

It is important that the output of the compact() (and validate()) functions result in a number in a format that is generally accepted to be valid. In this case it seems that the - separators are actually a significant part of the number and not just cosmetic like they are in most formats.

Perhaps this behaviour is nicer:

>>> ruc.compact('253-92-57027 DV 76')
'253-92-57027DV76'
>>> ruc.compact('155587169-2-2014    D.V. 9')
'155587169-2-2014DV9'
>>> ruc.compact('32812-2-249262      D.V. 63')
'32812-2-249262DV63'
>>> ruc.compact('155625946-2-2016 DV00')
'155625946-2-2016DV0''
>>> ruc.compact('00253-0092-0057027 DV 76')
'253-92-57027DV76'