Al emitir una boleta necesitas el nombre del cliente a partir de su DNI. La solución habitual es pagar una API de consulta. Hay una alternativa que funciona en buena parte de los casos y no cuesta nada.
El punto de partida: SUNAT no consulta por DNI
El buscador público de SUNAT solo acepta RUC. No hay endpoint de consulta por documento de identidad, y no lo va a haber, porque el padrón de SUNAT es de contribuyentes, no de ciudadanos.
Pero hay un detalle: el RUC de una persona natural se deriva de su DNI de forma determinista.
Cómo se construye
El RUC de persona natural tiene 11 dígitos y se arma así:
- Empieza con
10 - Siguen los 8 dígitos del DNI
- Cierra con un dígito verificador calculado
El dígito verificador se obtiene con un módulo 11 sobre los primeros 10 dígitos, usando los pesos 5, 4, 3, 2, 7, 6, 5, 4, 3, 2. Se multiplica cada dígito por su peso, se suman los productos, y del resto de dividir entre 11 se deriva el verificador.
Lo verificamos contra RUCs reales: el dígito calculado coincidió en 7 de 7 casos. No es una aproximación, es la regla.
Qué significa en la práctica
Si puedes derivar el RUC, puedes usar la consulta de RUC de SUNAT, que es pública y gratuita. El flujo queda así:
- El usuario escribe el DNI.
- Se calcula el RUC de persona natural.
- Se consulta ese RUC en el padrón de SUNAT.
- Si existe, tienes el nombre completo sin pagar nada.
En nuestras pruebas, de 6 DNIs al azar, 3 se resolvieron directamente por SUNAT. Con esa proporción, un proveedor pago solo ve la mitad de las consultas.
Cuándo no funciona
La derivación es exacta, pero solo sirve si la persona tiene RUC. Alguien que nunca se inscribió como contribuyente no aparece en el padrón, y ahí el cálculo no ayuda: el RUC derivado es correcto pero no existe.
Para esos casos hace falta un proveedor externo. Y aquí conviene ordenar el flujo: SUNAT primero, proveedor pago después. Así el proveedor solo recibe los DNIs que SUNAT no resolvió.
Los límites de tasa son más agresivos de lo que dicen
Si vas a usar un proveedor pago, mide su límite real. Con uno de los más conocidos del mercado peruano medimos esto: una consulta a los 3 segundos de la anterior falla con 429; a los 6 segundos pasa.
Y el detalle que rompe integraciones: el error 429 llega en HTML de nginx, no en JSON. Si tu código asume que toda respuesta es JSON, revienta al parsear en lugar de manejar el límite de tasa.
El caché no es una optimización, es parte del diseño
Con límites así, el caché deja de ser algo opcional. Los datos de identidad cambian poquísimo, así que un caché largo (nosotros usamos 30 días) reduce el tráfico de forma drástica y hace que la segunda consulta del mismo documento sea instantánea.
Medido: la primera consulta resuelta por SUNAT tomó 2,4 segundos; la segunda, desde caché, 0,45 segundos.
Una advertencia sobre el estado del contribuyente
Al consultar un RUC no basta con obtener la razón social. El padrón también dice si el contribuyente está activo y habido. Emitir una factura a un RUC que no está activo y habido puede traerte problemas de crédito fiscal.
Vale más avisar antes de emitir que descubrirlo después.
En ZMRFact el RUC y el DNI se autocompletan solos con esta cadena: SUNAT primero, proveedor externo solo si hace falta, y aviso en pantalla cuando el contribuyente no está activo y habido.