RFC válido para el SAT no pasa validación

[ala747]

¡Hola! Muchas gracias por esta pequeña y útil librería que funciona muy bien en casi todos los casos.

Me he encontrado con uno (LME060822IH5) en el que no termino de encontrar el problema: para el validador del SAT (https://agsc.siat.sat.gob.mx/PTSC/ValidaRFC/index.jsf) este RFC es "válido y susceptible de recibir facturas" pero al pasarlo por el validateRfc() da inválido por INVALID_VERIFICATION_DIGIT, el cuál he ido cambiando y que da válido en caso de ser 3 y no 5.

¿Se te ocurre dónde puede estar el problema?

¡Gracias y saludos!

[manuelmhtr]

Hola @ala747 muchas gracias por reportar el problema.
Por favor déjame revisarlo el fin de semana y te aviso en cuanto encuentre algo. Saludos!

[manuelmhtr]

@ala747 Nico,
Ya estuve revisando y está muy extraña la situación con este RFC. El último paso para calcular el dígito verificador es obtener un residuo de 11. Por lo tanto para la cadena LME060822IH solamente puede haber 1 sólo dígito correcto y es el 3. De hecho si validas LME060822IH3 en el SAT te dice que es correcto (aunque no está registrado), pero es cierto lo que dices: LME060822IH5 también aparece como correcto, por lo tanto en una inconsistencia del mismo SAT.

Tampoco encontré nada documentado que indique que un RFC pueda tener 2 dígitos verificadores válidos.

Mi hipótesis es que en algún punto el SAT registró o creó incorrectamente este RFC y como ya hubo facturas creadas no pueden simplemente desaparecerlo y tienen que seguirle dando soporte.

Solución
Partiendo de que puede haber más casos similares que no conozco y que esta librería debería funcionar también para ellos. Vamos a tratar este RFC (y los siguientes casos iguales) como un "caso especial" y se regresará como válido.

Lo que no estoy seguro aun es si regresar un type distinto para indicar que este RFC no cumple con las reglas de validación o mantener company pues sigue siendo un RFC de una personal moral.

Dame un par de días para pensarlo y subo la solución.

[ala747]

Muchas gracias por mirarlo, Manu. Yo también había estado haciendo mis cálculos y veía que todo era correcto, excepto el 5 en lugar del 3. Como no sabía si había alguna posibilidad (documentada) que yo no conociera fue que me decidí a plantear el problema.

Nada, pues. Estaré atento a la solución y si me surge alguna otra "excepción" te avisaré por si aporta.

Otra vez, ¡muchas gracias!

[RaschidJFR]

Yo me topé con el mismo problema. El algoritmo implementado es correcto, así que parece que el SAT no está siguiendo sus propias especificaciones. Dada esta situación, el propósito del dígito verificador queda anulado, por lo que para adaptar la librería a esta realidad propongo omitir la validación del dígito verificador por defecto. Algo como:

validateRfc(rfc, strict = false);

Donde el dígito verificador sólo se valida si strict es true. Por otro lado, strict es false, cuál debería ser la respuseta? Debría regresar la respuesta válida + el error del dígito o simplemente la respuesta válida?

Qué opinan?

[manuelmhtr]

Hola @RaschidJFR, te ha pasado seguido? tienes algunos ejemplos que nos puedas compartir?

No estoy seguro de que el parámetro strict sea la mejor solución, pierde mucho sentido la librería porque dejaría de validar la mayoría de casos a cambio de las excepciones que tiene el SAT. En ese caso sería mejor que cada aplicación decida si valida o no el RFC si está presente el error INVALID_VERIFICATION_DIGIT.

La solución que tenía pensada era crear una lista de RFCs válidos por el SAT. Si está presente en la lista entonces se regresa isValid: true. La desventaja sería mantener esa lista para todos los casos que vayan saliendo. Te has topado con muchos de esos casos?

[RaschidJFR]

@manuelmhtr Concuerdo, tal vez forzar la función con strict no sea la mejor solución. Después de todo, como usuario-desarrollador quieres saber si el RFC cumple con el formato o no.

Por otro lado, el asunto de RFCs que no cumplen con el dígito verificador es verdadero e importante. Si queremos que esta librería sea confiable en producción, entonces debe abordarlo. De lo contrario, sólo estará validando un caso "ideal" más no los escenarios reales (en producción).

Yo me topé con este problema mientras un cliente real no podía generar su cuenta en mi plataforma. Hice lo que describes y hago una validación extra después del resultado de la librería. Pero no es la mejor experiencia, ya que sólo lo descubres hasta que el problema le ocurre a algún usuario. StackOverflow tiene muchos posts con este problema:

• https://es.stackoverflow.com/questions/334340/validaci%c3%b3n-rfc-de-m%c3%a9xico-d%c3%adgito-verificador/335468#335468
• https://es.stackoverflow.com/questions/140420/validacion-de-rfc-con-errores
• https://es.stackoverflow.com/questions/31713/c%C3%B3mo-validar-un-rfc-de-m%C3%A9xico-y-su-digito-verificador

Se me ocurren algunas cosas que podrían ahorrarle el problema a los desarrolladores (y usuarios) a futuro:

• Documentar este problema en el Readme a modo de "known issues" o
• Usar el parámetro strict pero en true por default, para no alterar la función predeterminada
• Un poco de ambos

[manuelmhtr]

@RaschidJFR tienes razón, me parece buena idea permitir que el cliente decida si quiere o no revisar el dígito verificador, puede haber aplicaciones que solo requieran validar el formato.

También me parecen buenas tus sugerencias. Entonces de acuerdo a esto te propongo los siguiente cambios en tu pull request (#19):

• Que el default de strict sea true en vez de false.
• Que el segundo parámetro de validateRfc sea un objeto de opciones en vez de enviar strict directamente. Esto por 2 motivos:
  1. Abre la posibilidad a que la función pueda recibir otras parámetros.
  2. Es más claro el objetivo del código al leer validateRfc('LME060822IH3', { strict: false }) sobre validateRfc('LME060822IH3', false).

Hice un nuevo branch v2.0.0 (y cambié la base de tu PR para que apunte a este), para agregar un par de cambios que tengo en mente en la misma versión.

Te agradezco mucho por contribuir a este proyecto. Espero tus cambios y con gusto los mezclo.

[RaschidJFR]

Perfecto. Continúo la conversación en #19

[manuelmhtr]

Se soluciona este problema con 2 alternativas incluidas en la versión 2.0.0

@ala747 @RaschidJFR gracias por su ayuda.