manuelmhtr/validate-rfc

RFCs registrados, pero con dígito verificador (aparentemente) incorrectos

Closed this issue · 3 comments

gwurman commented

Hola Manuel:

Cuento con 3 casos con dígito verificador inválidos, pero que si han sido registrados en el Registro Federal de Contribuyentes del SAT:

[
  'AUGJ651117623', // expected 4
  'CCA980429MD4', // expected 2
  'AAJ0809274AA' // expected 0
]

¿Sabes algo de estos casos especiales?

Saludos cordiales

manuelmhtr commented

Hola @gwurman!
La verdad es que no hay información oficial al respecto, creo que son RFCs viejos que por algún motivo quedaron así. Hay 2 soluciones posibles:

  1. Usar la opción omitVerificationDigit para ignorar el verificador.
  2. Puedo incluir AUGJ651117623 y CCA980429MD4 en la lista de RFCs conocidos, pero estoy revisando el AAJ0809274AA y me aparece que no es un RFC registrado. Está escrito correctamente?

En la sección de "Problemas conocidos" hay más información disponible sobre el tema.

  • 👍1
gwurman commented

Muchísimas gracias @manuelmhtr por la pronta respuesta 🙌

AlexITC commented

Oh, many years ago I had to deal with this, while comparing our data with the one provided by SAT, turns out that most online validators/generators are wrong for some corner cases, these cases are defined ambiguously by the spec and the only way to get it right was to try with many known RFCs and adapt the conditions.

Still, there was one case that we weren't able to deduct, it seems that the SAT generation rules changed from a given point in the time, unfortunately, this isn't documented anywhere.

My conclusion after fighting with this:

  • For the happy path, generate the RFC.
  • For corner cases that aren't well documented, get this from another service (SAT is the best one, for example, a last name can have a single character).
  • 👍1