Generadores de documentos de Latinoamérica

Cada país, su propio dígito verificador

No hay un algoritmo latinoamericano común: cada país eligió el suyo, y por eso una validación que funciona en Chile falla en Brasil. Estos son los que implementamos, con el caso real contra el que quedó comprobado cada uno:

Los detalles que rompen validaciones

• El dígito K del RUT chileno. Cuando el resto da 10, el verificador es la letra K. Hay una opción para forzarlo: es el caso que tumba cualquier validación que solo acepte cifras.
• La región fiscal del CPF. El noveno dígito indica dónde se emitió; puedes elegirla si tu aplicación la interpreta.
• El prefijo del CUIT. 20 para hombre, 27 para mujer, 30 y 33 para empresas. Los ocho dígitos centrales son el DNI del titular, así que CUIL y DNI deben ser coherentes en tus datos.
• La homoclave del RFC mexicano. El SAT no publica su algoritmo. Aquí es aleatoria: el formato es correcto, pero no es calculable. Lo decimos abiertamente.

Los tres algoritmos, en código

Casi toda Latinoamérica usa una variante de módulo 11, pero con pesos distintos y reglas distintas para los casos borde. Estas son las tres familias que cubren los ocho países:

Chile: pesos cíclicos de 2 a 7

function dvRut(num) {
  let suma = 0, mul = 2;
  for (let i = num.length - 1; i >= 0; i--) {
    suma += Number(num[i]) * mul;
    mul = mul === 7 ? 2 : mul + 1;
  }
  const r = 11 - (suma % 11);
  return r === 11 ? "0" : r === 10 ? "K" : String(r);
}

El caso que rompe todo está en la última línea: cuando el resto da 10, el verificador es la letra K. Aproximadamente uno de cada once RUT termina en K, así que si tu campo solo acepta dígitos vas a rechazar al 9 % de los chilenos. La herramienta tiene una opción para forzar RUT terminados en K precisamente para esta prueba.

Brasil: dos dígitos, pesos descendentes

function dvCpf(base) {                  // base = 9 o 10 dígitos
  const pesos = base.length + 1;
  let suma = 0;
  for (let i = 0; i < base.length; i++) suma += Number(base[i]) * (pesos - i);
  const r = suma % 11;
  return String(r < 2 ? 0 : 11 - r);
}
const cpf = base9 => {
  const d1 = dvCpf(base9);
  return base9 + d1 + dvCpf(base9 + d1);
};

El CPF lleva dos dígitos verificadores, y el segundo se calcula incluyendo el primero. Un error habitual es calcularlos por separado sobre la misma base: el resultado pasa la mitad de las validaciones y falla la otra mitad.

Colombia: pesos primos

const PESOS = [3, 7, 13, 17, 19, 23, 29, 37, 41, 43, 47, 53, 59, 67, 71];
function dvNit(num) {
  let suma = 0;
  for (let i = num.length - 1, j = 0; i >= 0; i--, j++)
    suma += Number(num[i]) * PESOS[j];
  const r = suma % 11;
  return String(r > 1 ? 11 - r : r);
}

Lo que codifica cada documento

Varios de estos números no son aleatorios: llevan información dentro, y eso los hace útiles para probar lógica que depende de ella.

Esto tiene una consecuencia práctica: si tu aplicación guarda por separado el CUIL y el DNI de un argentino, tienen que ser coherentes entre sí. Genera un CUIL, extrae los ocho dígitos centrales y úsalos como DNI: así tus datos de prueba aguantan una revisión humana. La herramienta ya te devuelve ese campo desglosado en el CSV.

Una excepción que declaramos

La homoclave del RFC mexicano —los tres últimos caracteres— la asigna el SAT con un algoritmo que no publica. Las cuatro letras iniciales y la fecha sí siguen la regla oficial, pero la homoclave que genera esta herramienta es aleatoria: el formato es correcto y pasa una validación de estructura, pero no es calculable ni verificable. Preferimos decirlo a que lo descubras en producción.

La letra del RIF venezolano entra en el cálculo

El Registro de Información Fiscal de Venezuela empieza por una letra que clasifica al contribuyente: V venezolano, E extranjero, J jurídico —una empresa—, P pasaporte y G gubernamental.

Y aquí está lo que distingue una implementación correcta: esa letra no es una etiqueta, es parte del cálculo. Tiene un valor propio, del 1 al 5, que se multiplica por cuatro y se suma antes de aplicar los pesos a los ocho dígitos. La consecuencia práctica es contundente: cambiar solo la letra invalida el número entero.

const VALOR = { V: 1, E: 2, J: 3, P: 4, G: 5 };
const PESOS = [3, 2, 7, 6, 5, 4, 3, 2];

function controlRif(letra, d8) {
  let suma = VALOR[letra] * 4;
  for (let i = 0; i < 8; i++) suma += Number(d8[i]) * PESOS[i];
  const r = 11 - suma % 11;
  return r >= 10 ? 0 : r;        // ← 10 y 11 se convierten en 0
}

controlRif("J", "00012255")   // 5  →  J-00012255-5

Verificado con dos RIF publicados, J-00012255-5 y J-30816256-6. Dos aciertos independientes con un control de base once son una posibilidad entre ciento veintiuna por azar, así que el algoritmo es el correcto.

La prueba negativa que más rinde aquí es evidente: coge un RIF válido de empresa y cámbiale la J por una V. Si tu sistema lo sigue dando por bueno, no está metiendo la letra en el cálculo.

Cinco países donde no hay nada que validar

Costa Rica, Panamá, Bolivia, Paraguay y Honduras tienen algo en común que conviene saber antes de escribir una validación: sus documentos de identidad no llevan dígito de control. No hay fórmula que comprobar.

Lo que sí se puede validar es la estructura, y ahí cada país tiene la suya:

El caso de Honduras es el más aprovechable para pruebas: los cuatro dígitos centrales son el año de nacimiento, así que si tu aplicación calcula la edad a partir del documento, ahí tienes un dato que ejercitar. Y en Costa Rica, que la cédula jurídica empiece siempre por 3 permite distinguir empresa de persona sin preguntar.

Qué falta aquí, y por qué

No están Guatemala, El Salvador, Nicaragua ni República Dominicana. No es un olvido: esos cuatro sí llevan dígito de control, y no hemos conseguido reproducirlo contra un número publicado. Podríamos generar algo con el formato correcto, pero sería entregar cifras que parecen válidas y no lo son, que es justo lo contrario de lo que sirve para probar. Preferimos que falten a que engañen.