Generadores de datos de prueba del Perú

Qué valida de verdad cada documento peruano

Los tres documentos de identidad del Perú se comportan de forma muy distinta ante una validación, y conviene tenerlo claro antes de escribir las pruebas:

• DNI: ocho dígitos sin dígito verificador oficial en el número impreso. Lo único que puede validar tu aplicación es la longitud y que sean cifras; si alguien te dice que «calcula el verificador del DNI», está pensando en el carácter de verificación que RENIEC imprime aparte.
• RUC: once dígitos con dígito verificador de módulo 11. Aquí sí hay algo que comprobar, y es la prueba negativa más rentable: un RUC con el último dígito cambiado.
• Carné de extranjería: nueve o doce dígitos según la serie, sin verificador. El error habitual es fijar la longitud a nueve y rechazar los carnés nuevos.

Los datos bancarios

El CCI son veinte dígitos donde los tres primeros identifican la entidad financiera. Generamos códigos con los prefijos reales de los bancos peruanos, así que si tu aplicación deduce el banco a partir del CCI, la deducción funcionará. La cuenta bancaria sigue la máscara propia de cada banco, que no es la misma en todos.

Direcciones y placas

Las direcciones combinan vías reales con distritos y provincias que existen, emparejados correctamente: no verás un distrito de Lima colgando de Arequipa. Las placas cubren el formato antiguo de tres letras y tres dígitos y el alfanumérico nuevo.

Cómo validar un RUC en tu código

Es el único documento peruano con dígito verificador comprobable, así que es el que merece una validación de verdad. El algoritmo son cinco líneas: se multiplican los diez primeros dígitos por los pesos 5-4-3-2-7-6-5-4-3-2, se suma, y el verificador es 11 − (suma mod 11), tomando 0 cuando sale 11 y 1 cuando sale 10.

function rucValido(ruc) {
  if (!/^(10|15|17|20)\d{9}$/.test(ruc)) return false;
  const pesos = [5, 4, 3, 2, 7, 6, 5, 4, 3, 2];
  let suma = 0;
  for (let i = 0; i < 10; i++) suma += Number(ruc[i]) * pesos[i];
  let dv = 11 - (suma % 11);
  if (dv === 11) dv = 0;
  if (dv === 10) dv = 1;
  return dv === Number(ruc[10]);
}

Fíjate en la expresión regular: los prefijos válidos son 10 y 15 y 17 para persona natural, y 20 para persona jurídica. Un RUC que empiece por 30 o por 99 es inválido por mucho que el dígito verificador cuadre, y es un caso de prueba que casi nadie cubre.

Los seis errores más frecuentes con documentos peruanos

Qué documento usar en cada tipo de prueba

• Altas de cliente: DNI más nombres y apellidos peruanos, para que el registro sea coherente. Un DNI con un nombre en inglés delata inmediatamente que los datos son de mentira cuando alguien revisa la base.
• Facturación: RUC de tipo 20 con razón social. Si tu sistema emite comprobantes, el tipo de contribuyente cambia el flujo.
• Pruebas negativas: genera con «dígito verificador incorrecto». El número parece perfecto y solo lo detecta una validación real.
• Selectores en cascada: direcciones con departamento, provincia y distrito. Están emparejados correctamente, así que sirven para comprobar que tus listas dependientes filtran bien.
• Carga masiva: exporta 100 en CSV. El archivo llega en UTF-8 con marca BOM, así que Excel abre las tildes sin que tengas que reimportar nada.

Sobre RENIEC y SUNAT

Conviene decirlo claro: un RUC generado aquí pasa la validación matemática pero no está inscrito en SUNAT, y un DNI no está en RENIEC. Si tu aplicación consulta el padrón real o el servicio en línea de RENIEC, estos datos serán rechazados — y eso también es un caso de prueba legítimo: comprobar que tu sistema maneja bien la respuesta «no existe». Para eso tienes los mocks de respuestas HTTP.