Generadores de datos de prueba de España

Un mismo módulo 23 para personas, y otra cosa para empresas

España usa dos algoritmos distintos y confundirlos es el origen de la mitad de los errores de validación en formularios españoles.

Para personas —DNI y NIE— la letra final es el resto de dividir el número entre 23, buscado en la tabla TRWAGMYFPDXBNJZSQVHLCKE. En el NIE hay un paso previo: la letra inicial se sustituye por una cifra (X→0, Y→1, Z→2).

Para empresas el CIF usa una suma tipo Luhn sobre siete dígitos, y el control se expresa como número o como letra según el tipo de entidad. Los tipos N, P, Q, R, S y W llevan siempre letra: si tu validación solo acepta dígitos, rechazarás el identificador de cualquier ayuntamiento o fundación.

Tienes el detalle completo, con los ejemplos verificados, en las fichas del generador de NIE y del generador de CIF.

Los diecisiete tipos de entidad del CIF

La primera letra no es decorativa: determina qué es la entidad y, sobre todo, si el carácter de control es un número o una letra. Esta es la tabla completa, y es la referencia que necesitas para escribir una validación que no rechace a media España:

Las letras I, O, T, X, Y y Z no son tipos de entidad válidos —las tres últimas están reservadas para el NIE—, y ese es justo el caso negativo que debe rechazar tu validación.

Validar NIE, DNI y CIF en una sola función

Los tres documentos entran por el mismo campo en la mayoría de formularios españoles, así que merece la pena resolverlo de una vez:

const TABLA = "TRWAGMYFPDXBNJZSQVHLCKE";
const CIF_LETRAS = "JABCDEFGHI";

function documentoEspanol(doc) {
  const d = doc.toUpperCase().replace(/[^0-9A-Z]/g, "");

  // DNI: 8 dígitos + letra
  if (/^\d{8}[A-Z]$/.test(d))
    return TABLA[+d.slice(0, 8) % 23] === d[8] ? "dni" : null;

  // NIE: X, Y o Z + 7 dígitos + letra
  if (/^[XYZ]\d{7}[A-Z]$/.test(d)) {
    const n = "XYZ".indexOf(d[0]) + d.slice(1, 8);
    return TABLA[+n % 23] === d[8] ? "nie" : null;
  }

  // CIF: letra de tipo + 7 dígitos + control
  if (/^[ABCDEFGHJNPQRSUVW]\d{7}[0-9A-J]$/.test(d)) {
    let impares = 0, pares = 0;
    for (let i = 1; i <= 7; i++) {
      const c = +d[i];
      if (i % 2) { const x = c * 2; impares += x > 9 ? x - 9 : x; }
      else pares += c;
    }
    const ctrl = (10 - ((impares + pares) % 10)) % 10;
    return d[8] === String(ctrl) || d[8] === CIF_LETRAS[ctrl] ? "cif" : null;
  }
  return null;
}

Devuelve el tipo de documento en lugar de un booleano, que suele ser más útil: te permite aplicar reglas distintas a una persona y a una empresa sin pedirle al usuario que elija el tipo en un desplegable antes de escribir.

Errores que descubren estos datos

• El NIE tratado como si la letra inicial no contara. Si no sustituyes X, Y y Z por 0, 1 y 2, todos los NIE te salen inválidos. Es el fallo más común.
• El CIF con control alfabético rechazado. Genera uno de tipo P o Q y compruébalo: si tu formulario no lo acepta, ningún ayuntamiento podrá darse de alta.
• La letra en minúscula. El usuario escribirá 12345678z. Normaliza antes de comparar, no rechaces.
• Los separadores. Y-1234567-X es como muchos lo escriben. La herramienta genera las tres variantes de formato para que las pruebes.

Los dos dígitos de control de una cuenta española

El Código Cuenta Cliente son veinte dígitos, y el error de bulto es tratar sus dos dígitos de control como si fueran uno solo de dos cifras. No lo son: cada uno valida un trozo distinto de la cuenta.

Los dos se calculan con los mismos pesos, 1-2-4-8-5-10-9-7-3-6, sobre diez dígitos. Para el primero, la entidad y la oficina se rellenan con dos ceros por delante hasta llegar a diez. Y hay dos casos especiales que casi nadie contempla: cuando el resto da 10 el dígito es 1, y cuando da 11 es 0.

const PESOS = [1, 2, 4, 8, 5, 10, 9, 7, 3, 6];

function dc(diez) {
  const suma = [...diez].reduce((a, c, i) => a + Number(c) * PESOS[i], 0);
  const r = 11 - suma % 11;
  return r === 11 ? 0 : (r === 10 ? 1 : r);   // ← los dos casos especiales
}

dc("00" + "2100" + "0418")   // 4
dc("0200051332")             // 5   →  control "45"

El IBAN español se deriva del CCC: se le añade ES y los dos dígitos del módulo 97. Por eso los dos van siempre juntos, y por eso este generador te da los dos a la vez. Verificado con ES91 2100 0418 45 0200051332 y otros dos IBAN publicados: el IBAN reconstruido a partir del CCC coincide carácter por carácter.

El caso borde del número de la Seguridad Social

Son doce dígitos: dos de provincia, ocho de número de serie y dos de control, que salen del resto de dividir entre 97. Hasta ahí, sencillo. La trampa está en cómo se juntan la provincia y la serie antes de dividir:

• Si la serie empieza por cero, la provincia se desplaza siete posiciones.
• Si no, se desplaza ocho, que es lo que uno esperaría siempre.

Una implementación que concatene sin más las dos cadenas acierta en el 90 % de los casos y falla justo en las series con cero inicial. Es un fallo que tarda meses en aparecer y que, cuando aparece, nadie relaciona con el algoritmo. El generador tiene una opción específica para producir ese caso.

Matrículas: veinte consonantes y dos sistemas

La matrícula española no tiene dígito de control. Lo que hay que validar es el formato, y tiene su miga. Desde septiembre de 2000 son cuatro cifras y tres letras, pero no de cualquier letra: se usa un alfabeto de veinte consonantes.

Se excluyen las cinco vocales, para que la combinación no forme palabras, y además la Ñ y la Q, porque se confunden con la N y con el cero. Quedan BCDFGHJKLMNPRSTVWXYZ. Aceptar vocales es el fallo de validación número uno.

El número dos es olvidarse del sistema provincial anterior: una o dos letras de provincia, cuatro cifras y una o dos letras, como M-1234-AB. Esos vehículos siguen circulando y siguen dándose de alta en seguros y talleres. Una validación que fije la longitud a la del formato actual los rechaza a todos.

Teléfonos y direcciones que se corresponden

En España todos los números tienen nueve dígitos y el primero dice de qué son: 6 y 7 para móvil, 8 y 9 para fijo. Los dos errores clásicos en los formularios son rechazar los móviles que empiezan por 7, asignados desde hace años, y guardar el teléfono como número, con lo que se pierde cualquier cero inicial y se rompe el prefijo internacional. Un teléfono es una cadena, no un entero.

En las direcciones, lo que importa para probar de verdad es la coherencia: el código postal empieza por los dos dígitos de la provincia y el municipio existe en esa provincia. Un dato con Madrid y código postal 08015 no sirve, porque cualquier validación cruzada lo tumba antes de que llegues a ejercitar el resto del flujo. Aquí los cincuenta y dos prefijos provinciales y los prefijos telefónicos son los reales.

Qué probar con datos españoles sintéticos

• Serie de la Seguridad Social con cero inicial. El caso borde que separa una implementación correcta de una a medias.
• Cuenta con el segundo control cambiado. La entidad y la oficina son impecables; solo lo detecta quien valida los dos dígitos por separado.
• IBAN y CCC del mismo titular. Comprueba que tu sistema los reconoce como la misma cuenta y no la duplica.
• Matrícula del sistema antiguo. M-1234-AB en un campo que espera 1234 BCD.
• Matrícula con vocal. Genera una válida y cámbiale una letra por una A: tu validación debería rechazarla.
• Móvil que empieza por 7. Sigue habiendo formularios que lo rechazan.
• Prefijo de dos y de tres cifras. Madrid es 91 y Cuenca 969: la longitud del prefijo cambia, la del número no.
• Código postal con cero inicial. Álava empieza por 01: guardado como número se convierte en cuatro cifras y deja de ser válido.