Serie «De la skill al conector» · Artículo 3 de 3. Venimos del artículo 1, donde vimos la diferencia entre skill y conector, y del artículo 2, donde descubrimos que la API oficial existía y aun así no servía.
NominaSOL lo usan miles de despachos y no tiene integración real con inteligencia artificial. No hay app, no hay puerta, y no parece que interese abrirla. Así que me senté con Claude en el escritorio y se la abrí yo.
Y por el camino entendí algo que al empezar no sabía: que hoy, si sabes decir con precisión qué necesitas, has dejado de depender de que nadie te lo construya. Pero a eso llego al final.
Hoy toca lo que no sale en los vídeos: la construcción, los errores y el método que quedó. Incluido el día que el programa me dijo que había importado ochenta trabajadores y no había importado ninguno.
Índice
1. De dónde venimos
Recapitulo en cinco líneas, por si has caído aquí directamente.
Soy graduado social y quería que la inteligencia artificial trabajara con mi programa de nóminas.
Escribí una skill y no funcionó, porque una skill explica cómo hacer algo y yo necesitaba algo que lo hiciera: un conector.
Esa es toda la lección del artículo 1.
Después descubrí que el fabricante sí tenía API, pero era solo para su nube y además era un almacén de filas sin una sola operación de negocio.
De ahí salió la segunda distinción, dato o proceso, y las cuatro salidas posibles.
Todo eso está en el artículo 2.
La decisión fue híbrida: leer la base de datos para el dato, y automatizar el programa para el proceso.
Con un orden deliberado: primero lo que no puede romper nada.
Hoy te cuento cómo se hizo.
Y te lo cuento con los errores incluidos, porque un artículo que solo enseña lo que salió bien es publicidad, no un relato.
2. Mirar antes de opinar: lo que había en la carpeta
El momento que cambió el proyecto es de una sencillez que asusta.
En lugar de suponer cómo guardaba los datos NominaSOL —que es lo que hacen los foros, y por eso los foros se equivocan—, fue a mirar.
Y lo que apareció fue esto:
Una carpeta con casi mil ficheros de Access, uno por cada empresa y cada ejercicio, con el código de empresa y el año en el nombre.
Se abren sin contraseña.
Setenta y una tablas cada uno.
Y un fichero general con ciento cincuenta y tres tablas más: las 215 empresas, los 40 convenios que tengo cargados, 208 categorías profesionales, las tablas de cotización y las de IRPF.
Pero el dato que decidió la arquitectura fue otro:
Se leen con NominaSOL abierto, sin bloquear nada, en menos de un segundo.
Es decir: podía consultar mientras trabajaba.
Sin interferir, sin riesgo, sin esperar.
Una hora explorando el terreno real vale más que un día de diseño sobre el papel.
La opción de leer directamente pasó de «quizá» a «hoy mismo» en cuanto vi esa carpeta.
Y esto, otra vez, es puro oficio de despacho.
¿Cuántas veces has planteado una estrategia con lo que te contó el cliente por teléfono y ha cambiado entera al abrir el expediente?
Pues eso.
3. El diccionario: entender antes de codificar
Poder leer las tablas no es suficiente. Hay que saber qué significa cada campo.
Y aquí te encuentras con la realidad de un programa con muchos años a la espalda: los campos se llaman CODTRA, FBATRA, TDENOM, ITCCPNO.
Nadie te da el diccionario. No existe.
Así que hubo que construirlo: volcar registros reales y deducir el significado, tabla por tabla, campo por campo. Un diccionario de datos empírico.
Y de ahí salieron cosas que ningún manual dice y que, si no las sabes, te llevan a firmar una barbaridad:
Una fecha vacía no se guarda como vacía: se guarda como 01/01/1900.
Si no lo sabes, tienes trabajadores que empezaron a trabajar hace ciento veintiséis años.
El campo de situación del trabajador está invertido.
No marca el alta: marca la baja.
Si lo lees al derecho, te da la plantilla justo al revés.
Los acumulados no se actualizan solos.
Van por detrás hasta que ejecutas el proceso correspondiente.
Si te fías, cuadras un 111 con datos viejos.
El mes 13 no es un mes.
En los acumulados, el mes 13 son los atrasos.
Las líneas de nómina solo contienen devengos.
Las deducciones no están ahí: se calculan desde las bases.
Cada uno de esos cinco puntos es, en potencia, un error en un escrito, en un modelo o en una reclamación de cantidad.
Y ninguno estaba documentado en ningún sitio.
Se averiguaron mirando.
4. 183 nóminas, una a una: verificar contra el dato
El conector de lectura no se dio por bueno porque «pareciera correcto».
Se comprobó contra 183 nóminas reales, una por una, con tres pruebas:
Que devengos menos deducciones da exactamente el líquido. Cuadró en las 183.
Que las líneas de nómina suman el total devengado. 183 de 183.
Que ningún trabajador quedaba huérfano, sin su empresa o sin su contrato.
Eso se convirtió en la regla de la casa. Y bien que hizo, porque poco después salvó el proyecto de un error grave.
Te lo cuento porque es la mejor historia de todo esto.
El día que el programa mintió
Primera importación real de trabajadores.
El conector ejecuta el proceso. La pantalla muestra lo que tiene que mostrar. Todo parece perfecto. El conector iba a informar de que la importación se había completado.
Y no se había importado nada.
¿Qué había pasado?
Un aviso del programa se había abierto encima, tapando la ventana, y el clic no llegó al botón. Visualmente todo estaba bien. Funcionalmente no había ocurrido nada.
¿Y cómo se detectó?
Porque fue a leer la base de datos y el trabajador no estaba.
Piensa en lo que habría pasado sin esa comprobación: yo dando por hecho que ochenta altas están metidas, cerrando el mes, y descubriéndolo tres semanas después.
O en la Inspección.
Verificar contra el dato, nunca contra la pantalla. Una interfaz puede mentirte; una tabla no.
Y esto, otra vez, es exactamente nuestro oficio.
Es la diferencia entre que el cliente te diga «sí, sí, eso lo presenté» y que tú abras el justificante.
5. Radiografiar la interfaz: campos con nombre y botones mudos
Para la parte que actúa hubo que hacerle una radiografía al programa.
Y el resultado fue desigual: mitad buena noticia, mitad mala.
Lo bueno: los campos y las rejillas tienen nombre propio.
Eso significa que se puede escribir en el campo exacto y saber si una pantalla ha terminado de cargar.
Nada de hacer clic por coordenadas, que es lo frágil.
Lo malo: la cinta de opciones es opaca.
Los botones no llevan texto: solo códigos internos del tipo s41703. Desde fuera, la cinta es una fila de iconos mudos.
La solución fue artesanal y me pareció brillante: fotografiar cada pestaña y emparejar cada imagen con las coordenadas de cada botón, una por una.
Resultado: 104 opciones identificadas y 86 desplegables capturados.
Y una ventaja inesperada: al ser códigos internos y no texto visible, son más estables.
El fabricante puede cambiar el rótulo de un botón en la próxima versión; el código de dentro es mucho menos probable que lo toque.
Lo que parecía el punto débil resultó ser el más duradero.
6. Por fases, de menos a más peligroso
El orden de construcción no fue casual.
Fue, probablemente, la decisión más importante del proyecto.
Primero, el lector. No puede romper nada. Valor inmediato desde el día uno.
Segundo, los informes. Tampoco escribe. Sirve para rodar toda la mecánica de navegación del programa con riesgo cero: si algo falla, lo peor que pasa es que no sale un PDF.
Tercero, la importación. Aquí ya se escribe. Con confirmación expresa, copia de seguridad y validación previa.
Cuarto, la actualización de registros, el cambio de empresa y la revisión del mes. Sobre lo anterior, ya probado.
Y lo último, el cálculo de nóminas y SILTRA. Cuando todo lo demás lleva tiempo funcionando.
¿Ves la lógica?
Cada fase entrena la mecánica de la siguiente en un terreno donde equivocarse no cuesta nada.
Cuando llegas a escribir en la base de datos de un cliente, ya has hecho doscientas veces los mismos movimientos leyendo.
Si algún día montas lo tuyo, cópiame esto.
Es lo que separa un proyecto que sobrevive de uno que te da un susto y lo abandonas.
7. Lo que enseñaron los errores
Y ahora la parte más honesta de todo el proceso, y la que más te va a servir.
Hubo errores. Unos cuantos. Y cada uno dejó una salvaguarda permanente dentro del código:
Dijo «importado» y no se había importado → ahora lee los avisos del programa y solo confirma con el dato.
Puso el estado del trabajador al revés → ahora lo pone solo: 0 si está de alta, 1 si hay fecha de baja.
Puso jornada anual en un contrato semanal → ahora asume semanal si hay horas, y lo advierte.
La empresa abierta cambió sola a otro cliente → ahora comprueba la empresa antes de escribir y se niega si no coincide.
Un aviso modal bloqueó los clics → ahora detecta, lee y cierra los avisos encadenados.
Fíjate en la cuarta, porque es la más importante de todas y la que me quitó el sueño.
La empresa abierta en el programa cambió sola a otro cliente.
Sin esa salvaguarda, un descuido habría escrito datos en el cliente equivocado.
Y ahí ya no estamos hablando de un fallo informático: estamos hablando de un problema profesional serio, con datos personales de terceros de por medio.
Ahora el conector comprueba, antes de escribir una sola fila, que la empresa que hay abierta es exactamente la que se le ha pedido.
Y si no coincide, se planta.
Ahí tienes, hecha carne, una de las ideas del primer artículo: una instrucción no protege, una comprobación sí.
8. Dos conectores, no uno: una decisión de seguridad
Con todo el mapa en la mano, la propuesta final me sorprendió otra vez.
Yo pedía un conector.
Y la propuesta fueron dos.
Pieza uno: el lector
Entra directamente en los ficheros de datos y solo lee. No escribe. No modifica. No borra.
Y no es que esté programado para portarse bien: es que no puede, aunque quisiera. Está construido para no poder.
Cuando le preguntas por su estado, lo primero que declara es su modo: SOLO LECTURA.
Pieza dos: el operador
Maneja el programa como lo haría una persona sentada delante: lo abre, cambia de empresa y ejercicio, abre la ventana del informe, ajusta los parámetros, lo genera y lo exporta.
Y sí, también mete datos. Pero con cinturón, airbag y dos llaves.
¿Y por qué separarlos?
Porque el 90 % de lo que hago en el día a día es consultar.
Y consultar no debería tener jamás la posibilidad técnica de romper nada.
Piénsalo: si todo estuviera en un único conector, cada vez que pregunto una tontería como «cuántos trabajadores tiene esta empresa» le estaría dando, técnicamente, capacidad para modificar la base de datos de un cliente.
Separarlos significa que la mayor parte de mi trabajo con la IA transcurre en una sala donde es imposible causar daño.
Para lo demás hay que entrar por otra puerta, deliberadamente.
Esto no es una sutileza de informáticos.
Es el mismo criterio por el que no metes el dinero de las fianzas en la cuenta de gastos corrientes.
Tiene nombre: principio de mínimo privilegio.
Hasta hace unos meses yo no sabía ni que existía.
Hoy lo tengo montado en mi despacho.
Y esa decisión fue mía, y fue profesional, no técnica.
Porque yo sé lo que supone tocar por error el fichero de un cliente.
Eso no lo sabe la máquina.
9. Lo que hace hoy el lector
No te voy a soltar el catálogo entero, que esto es un artículo y no un folleto. Son veinticinco herramientas; te enseño tres que uso todos los días y ves por dónde respira esto.
Buscar a una persona en las 215 empresas a la vez. Por nombre, DNI o número de afiliación. Antes: alguien llama, no recuerdas de qué empresa era, y las abres una a una rezando. Ahora: tres segundos.
El recibo completo, mes a mes. Cada devengo, las deducciones desglosadas, las bases de cotización y un aviso automático si algo no cuadra. Es la vista exacta que necesitas para auditar o calcular atrasos.
La revisión del mes. Y esta es la joya que no me dio ningún fabricante: quién está de alta sin nómina, qué nóminas no cuadran, qué contratos vencen, qué bajas médicas siguen sin alta, quién no tiene el IRPF configurado, si los acumulados van desfasados. Se lo pedí yo. Hablando.
Y así hasta veinticinco: empresas, trabajadores, contratos, cotización, fiscal, incidencias, convenios. Todas entran en la base de datos, ninguna escribe, y responden en menos de un segundo.
10. Lo que hace hoy el operador
Este ya maneja el programa, así que necesita NominaSOL abierto. Diecinueve herramientas, y subiendo. Otra vez, lo esencial:
Saca informes. Más de treinta en catálogo, a PDF o Excel: costes de empresa, pagos a realizar, nóminas y cuotas, RLC y RNT, contratos y vencimientos, finiquitos, modelos 111, 190 y 145. Con control fino del periodo, el desglose por meses dentro del trimestre y el rango de trabajadores.
Importa datos en bloque. Diecinueve tipos de fichero —trabajadores, contratos, conceptos, incapacidades, finiquitos, acumulados—. Genera la hoja con el formato exacto (el que salió del manual del artículo 2), avisa de los campos que se pasan de largo, deja que el propio NominaSOL la valide, y solo entonces —con confirmación expresa y copia de seguridad previa— escribe.
La actualización masiva de registros la deja preparada y cargada en el programa; el último paso lo doy yo a mano, por lo que te cuento en los límites.
11. Lo que falta por construir
Y te cuento también lo que todavía no está.
El lote trimestral. Leer mi Excel de clientes y generar, para cada uno, el informe de costes del trimestre desglosado por meses y el de acumulados de retenciones, en Excel, guardados en la carpeta de cada cliente.
Con un resumen final de lo generado y de quién no tenía datos.
Eso, hoy, son dos mañanas de mi vida cada tres meses.
El ciclo mensual completo. Incidencias, cálculo de nóminas, acumulados y cálculo de IRPF. Con verificación contra la base de datos después de cada paso, no al final.
SILTRA y comunicaciones. Fichero de bases, afiliación, partes de IT, Contrat@ y Certific@2.
Y aquí una línea roja que no pienso cruzar, y que te recomiendo que adoptes:
Prepara los ficheros. El envío siempre es mío.
A la Seguridad Social y a Hacienda voy yo.
Con mi certificado, con mi responsabilidad y mirando lo que mando.
Eso no se automatiza.
12. Los límites, que también se cuentan
El epígrafe que no vas a encontrar en ningún vídeo de LinkedIn sobre IA, porque no vende.
Esto no es magia y no todo funciona.
Hay una ventana que no se puede automatizar. La de actualización masiva de registros.
El conector la abre y la deja preparada, pero el último paso —emparejar cada columna con su campo en la rejilla y pulsar Aceptar— hay que hacerlo a mano, porque ese desplegable lo dibuja el propio programa y la automatización no puede abrirlo.
Se intentó. No se pudo. Y está escrito así, negro sobre blanco, en la documentación del conector.
Hay tablas que mienten por omisión. Los acumulados van desfasados hasta que ejecutas el proceso. El conector te lo avisa y te dice de dónde sacar el dato bueno.
Y hay tablas que casi nadie rellena. La de ausencias, por ejemplo. Si tú no la usas, ahí no hay nada.
El operador tiene una dependencia física: necesita el ordenador encendido y el programa abierto. No es un servicio en la nube. Es un robot sentado en tu silla.
Y es frágil ante actualizaciones. Si el fabricante rediseña la cinta, hay que retocar. Se mitiga usando códigos internos en vez de texto, pero no desaparece.
¿Por qué te cuento esto pudiendo no contarlo?
Por dos razones.
La primera: un conector que te oculta sus límites es más peligroso que no tener conector. Si la herramienta no te avisa de que un dato puede estar desfasado, tú lo darás por bueno. Y firmarás con él.
La segunda: quiero que sepas dónde te metes. Esto no es «le digo a la IA que me haga las nóminas y me voy a la playa».
Es construir, poco a poco, una herramienta que hace muy bien un conjunto de cosas concretas y que en el resto te dice honestamente «hasta aquí llego».
Que es, por cierto, exactamente lo que le pedimos a un buen colaborador.
13. Cómo se construye esto sin saber programar
Y llegamos a la pregunta que llevas haciéndote desde el primer artículo.
«JMAI, tú de esto no sabes. ¿Cómo has hecho eso?»
Correcto.
Yo de esto no sé.
No he escrito una línea de código.
No sé qué lenguaje usa.
No sabría explicarte cómo funciona por dentro ni aunque me pusieras una pistola en la sien.
Lo que hice fue hablar.
Y el proceso, ordenado, fue este:
Describir el problema como se lo contaría a un compañero. Sin tecnicismos, sin intentar parecer lo que no soy.
Dejar investigar. Que se descargue la documentación técnica del fabricante y la analice entera. Que descubra que la API existe pero es de nube. Que cuente cuántas veces aparece la palabra «nómina» en ella. Que vaya a mirar la carpeta de datos en vez de suponer. Que deduzca el significado de FBATRA volcando registros. Que encuentre el manual de FACTUSOL para sacar el patrón de las rutas.
Todo eso es suyo.
Es donde aporta lo que yo no tengo.
Decidir yo lo que es una decisión profesional. Separar lectura y escritura. No irme a la nube. Preparar pero no enviar. Que el envío a la Seguridad Social sea siempre mío. Esas no son decisiones técnicas: son decisiones de responsabilidad, y las tomo yo. Siempre.
Probar y quejarme. «Esto no me sirve». «¿Y si además me avisa de los contratos que vencen?». Cada queja mía fue una versión mejor.
Saber cuándo está bien. Esta es la parte que no se puede delegar jamás. Yo sé si un recibo de salarios está bien desglosado. Yo sé si falta un tramo de cotización. Yo sé si un cálculo de atrasos tiene sentido. Cuando cuadraron las 183 nóminas, el que dijo «esto está bien» fui yo.
Ese es mi papel. No soy el que teclea. Soy el que dirige.
Y catorce años de despacho, que parecían no servir absolutamente para nada en un asunto de informática, resultan ser justo lo que hacía falta.
Tan es así que —como conté en el artículo 2— mi propia experiencia escrita acabó siendo el plano.
14. Los cinco principios que gobiernan todo esto
Si tuviera que resumir en una tarjeta todo lo que he aprendido en esta serie, sería esto. Y sirve igual para un conector que para llevar un despacho.
Uno. Verificar contra el dato, nunca contra la pantalla.
Una interfaz puede mentirte. Una tabla no. Si no has abierto el documento, no ha pasado.
Dos. Nada se escribe sin confirmación y sin copia de seguridad.
Ni una fila. Ni en una prueba. Nunca.
Tres. Comprobar siempre sobre qué empresa se está actuando.
Antes de tocar nada. Y si no coincide, plantarse.
Cuatro. Preparar, nunca enviar.
A la Seguridad Social y a Hacienda vas tú, con tu certificado y tu responsabilidad.
Cinco. Descubrir en vez de suponer.
Lo que no está documentado se averigua probando. Y lo aprendido se convierte en código, no en una nota que alguien tiene que acordarse de leer.
Léelos otra vez cambiando «conector» por «pasante nuevo».
Funcionan igual, ¿verdad?
No es casualidad.
Son los principios de cualquier trabajo bien hecho con responsabilidad sobre asuntos de terceros.
Lo único que ha cambiado es que ahora se los aplicamos a una máquina.
Y para que no te quedes solo con la teoría de cómo se construye, mira lo que hace uno ya montado: buscarme el código exacto de un alta sin retribución en Sistema RED, en la fuente oficial, en vez de llamar a la TGSS y esperar.
