Serie «De la skill al conector» · Artículo 2 de 3.
Venimos del artículo 1, donde vimos por qué una skill no puede manejar un programa. Hoy toca la segunda distinción: dato o proceso.
Y en el artículo 3 veremos cómo se construyó todo, con sus errores y su método.
Daba por hecho que NominaSOL no tenía API. Sí la tiene, es oficial y darse de alta es gratis.
Y daba exactamente igual. Por dos razones: una es comercial y la otra te cambia la forma de mirar cualquier programa que uses.
Índice
1. De dónde venimos
Si has llegado aquí directamente, te pongo al día en cuatro líneas.
Soy graduado social, llevo un despacho de laboral puro y trabajo con NominaSOL, de Software DELSOL.
Quise que la inteligencia artificial trabajara con ese programa y escribí una skill.
No funcionó.
Y no porque estuviera mal escrita, sino porque una skill explica cómo hacer algo y lo que yo necesitaba era algo que lo hiciera.
Eso, en el mundo de la IA, se llama conector.
Esa distinción —skill o conector— es todo el primer artículo de la serie, y te recomiendo leerlo si esto te suena a chino.
Bien.
Ya sabía qué necesitaba.
Ahora tocaba averiguar si se podía construir.
Y me llevé dos sorpresas seguidas.
2. «Investiga si esto se puede conectar»
Con la idea ya clara, volví a la carga.
Pero esta vez no me puse a escribir nada.
Me puse a preguntar.
Y aquí quiero que te fijes en cómo lo planteé, porque es más importante de lo que parece.
No busqué en Google «cómo hacer un MCP».
No me puse a estudiar.
No pedí presupuesto a un informático.
Abrí Claude en el escritorio —la versión que puede tocar archivos y ejecutar cosas en mi ordenador— y le conté el problema en cristiano, tal cual se lo contaría a un compañero en la cafetería:
«Tengo un programa de nóminas instalado en mi servidor. Necesito que puedas leer sus datos y, si es posible, manejarlo. Investiga qué opciones hay.»
Ya está.
Ese fue todo el «briefing técnico».
Y lo primero que hizo no fue ponerse a programar.
Fue averiguar si el fabricante ofrecía una puerta oficial.
Eso me pareció, ya entonces, muy sensato.
Y es el primer consejo que te doy si algún día haces esto: construir sobre una puerta que existe siempre es mejor que forzar una ventana.
3. Sorpresa: la API existe
Yo daba por hecho que no había API.
Me equivocaba.
Software DELSOL tiene API oficial.
Está documentada.
Tiene su portal de desarrolladores y su servidor propio.
El alta del llamado «código de fabricante» es gratuita.
Y hay más, que es lo que me sorprendió: el propio cliente concede los permisos desde dentro del programa, en Archivo > Seguridad > Acceso por API, eligiendo entre acceso completo con lectura y escritura, solo lectura, solo escritura, o parcial tabla a tabla.
Sin coste alguno.
Sobre el papel, eso es una puerta grande y bien hecha.
Y el fabricante lo explica con toda claridad en su documentación: la idea es que puedas conectar tus datos con lo que quieras, o encargárselo a un desarrollador.
Muy bien pensado.
Y aun así, no me servía.
Por dos razones.
La primera es un fastidio comercial.
La segunda es una lección conceptual que me cambió la forma de mirar cualquier software.
4. Razón uno: esa API vive en la nube
La documentación oficial no deja lugar a dudas.
La API está pensada para acceder a los datos de las soluciones en la nube.
Y todo el manual de configuración habla, una y otra vez, de «los datos de tu Alojamiento».
Yo trabajo en local.
Mi servidor está en mi despacho, no en el de nadie.
Así que esa puerta, para mí, está cerrada salvo que contrate el alojamiento en la nube del fabricante.
Y no lo voy a hacer.
Punto.
Quiero los datos de mis clientes donde están, bajo mi custodia y mi responsabilidad.
Esa es una decisión profesional, no técnica, y la tomo yo.
Hasta aquí, un problema comercial.
Molesto pero comprensible: el fabricante prioriza su producto en la nube, que es donde va el mercado.
Ahora viene lo interesante de verdad.
5. Razón dos: cero. Ni una vez
Esto es lo que me voló la cabeza.
Se descargó la colección técnica completa de la API y la analizó entera.
Y apareció el retrato:
No es una API de nóminas.
Es un CRUD genérico sobre tablas.
Un almacén de filas.
Sus operaciones se cuentan con los dedos de las dos manos: autenticar, leer un registro, leer la configuración, cargar una tabla, lanzar una consulta —solo de lectura—, escribir, actualizar, borrar y poco más.
Ni un solo endpoint de negocio.
¿Y sabes cuántas veces aparecen las palabras «nómina», «trabajador», «convenio» o «contrato» en los 482 KB de esa documentación técnica?
Cero.
Ni una.
Ninguna.
Todos sus ejemplos son de FACTUSOL, el programa de facturación de la misma casa: clientes, artículos, albaranes.
Nada de laboral.
El testigo de sesión caduca a los tres minutos.
No hay paginación ni versionado.
Traducido a nuestro idioma: esa API te habría dejado leer y escribir filas en bruto, pero no calcular una nómina, ni generar el fichero de SILTRA, ni imprimir un modelo 111.
Es decir: aunque hubiera contratado el alojamiento, aunque hubiera pagado, aunque hubiera hecho todo lo que el fabricante pide… tampoco habría podido hacer lo que quería.
Y aquí está la pregunta que hay que hacerse.
No «qué mal está esta API», sino:
¿Por qué?
6. Dato o proceso: la distinción que lo explica todo
Esta es la parte que quiero que te lleves puesta, porque no vale solo para mi programa: vale para el tuyo, sea cual sea.
En cualquier programa de gestión conviven dos cosas muy diferentes.
Y no distinguirlas es lo que hace que la gente se lleve chascos con la automatización.
El dato
Es lo que está guardado.
La ficha del trabajador.
Su contrato.
La nómina que ya se calculó el mes pasado.
Las bases de cotización.
Los acumulados.
El dato vive en la base de datos.
Está quieto.
Se puede leer, copiar, exportar.
El proceso
Es lo que ocurre cuando pulsas un botón. Calcular una nómina. Generar el fichero de cotización. Emitir un finiquito. Imprimir un modelo.
El proceso no está guardado en ninguna parte: está programado dentro del ejecutable.
Es la inteligencia del programa.
Es, literalmente, por lo que pagas la licencia.
Nadie te vende un programa de nóminas por su capacidad de almacenar filas: te lo vende porque sabe calcular.
Y ahora la conclusión
Una API que solo sirve filas puede darte todo el dato y ni un gramo de proceso.
Por eso la API de mi programa, aunque la contratara, jamás me calcularía una nómina.
No porque sea mala o esté mal hecha, sino porque no es eso lo que hace.
Le estaría pidiendo a un archivador que hiciera cuentas.
Esta distinción es el mapa entero de cualquier proyecto de automatización:
Si lo que necesitas es DATO, lo puedes sacar leyendo.
Si lo que necesitas es PROCESO, alguien tiene que pulsar el botón.
Guárdate esa frase.
En el epígrafe 9 se convierte en la bifurcación que decide qué te toca construir a ti.
7. Descartar bien también es construir
Y ahora un paréntesis de método, porque esto vale para cualquier proyecto tuyo, sea o no de tecnología.
Cuando la API se cayó de la mesa, mi primera reacción fue de fastidio. «Media hora tirada.»
Error.
Esa media hora de lectura ahorró semanas de trabajo en una dirección equivocada.
Piensa en la alternativa: alguien que da por hecho que la API sirve, se pone a construir sobre ella, y a las tres semanas descubre que no puede calcular una nómina.
Con el proyecto medio hecho y el "presupuesto" medio gastado.
Descartar bien es tan valioso como construir.
En nuestro oficio esto lo tenemos interiorizado y no nos damos cuenta.
Cuando estudias un asunto y concluyes que la acción está caducada, no has perdido la mañana: has evitado una demanda perdida.
Es exactamente lo mismo.
El tiempo que dedicas a saber por dónde no ir nunca es tiempo perdido.
8. La pregunta que le da la vuelta a todo: ¿de quién es el dato?
Con el panorama claro —API cerrada para mí, y encima incapaz de hacer procesos—, llegó el momento de rendirse.
Ahí es donde el 95 % de la gente cierra el portátil y dice «pues nada, no se puede».
Yo también lo pensé.
No te voy a mentir.
Pero entonces apareció la pregunta que le dio la vuelta a todo.
Y no la hice yo: la planteó la propia herramienta mientras investigaba.
¿Y por qué necesitas que el fabricante te dé permiso para leer tus propios datos?
Párate ahí un momento.
Los datos de mis clientes —sus trabajadores, sus nóminas, sus contratos, sus bases de cotización— no están en la nube de nadie. Están en un servidor que hay en mi despacho.
En unos ficheros que puedo abrir, copiar y respaldar cuando me dé la gana.
Son míos.
Están en mi casa.
Los custodio yo, con toda la responsabilidad que eso conlleva.
Que el fabricante no me ofrezca una API que llegue no significa que el dato esté cerrado con llave.
Significa que no ha construido esa puerta concreta.
Nada más.
Y ese cambio de marco lo abre todo:
Si el dato vive en tu equipo, no dependes de que el fabricante innove. Dependes de que alguien —o algo— sepa leerlo.
A partir de ese momento, el asunto dejó de ser un callejón sin salida y pasó a ser un problema de ingeniería.
Que es, casualmente, el tipo de problema que la IA resuelve bien.
9. Las cuatro salidas que había sobre la mesa
Y aquí la conversación se puso seria.
Aparecieron cuatro caminos y se pusieron a comparar en voz alta.
Fíjate en que la bifurcación es exactamente la del epígrafe 6.
Dato o proceso.
Opción A — El robot que usa el programa por ti
Abre el programa y pulsa los botones solo. Tú le dices «calcula las nóminas de julio de estas cinco empresas» y él navega el menú, rellena y ejecuta.
Es la única de las cuatro que hace procesos.
Escribe: sí. Riesgo: alto. Y exige el ordenador encendido con el programa abierto. Si el fabricante rediseña la pantalla en una actualización, hay que retocarlo.
Opción B — El lector de la base de datos
No toca el programa. Va directo a la carpeta de datos y lee: trabajadores, contratos, nóminas ya calculadas, bases de cotización.
Escribe: no. Riesgo: nulo.
Rápido de hacer, fiable y no puede romper nada. Lo malo: solo da dato. Ni un proceso.
Opción C — El recogedor de informes
El programa ya saca PDF y Excel a una carpeta; esto los recoge, los lee y los ordena.
Escribe: no. Riesgo: nulo.
Baratísima y no se rompe nunca, porque no depende del diseño de ninguna ventana. Lo malo: no opera nada, solo recoge lo que tú ya has generado.
Opción D — Irse a la nube y usar la API oficial
Descartada de entrada, por lo que acabamos de ver: no me llevo los datos de mis clientes a ningún sitio, y además tampoco resolvería los procesos.
La decisión
Híbrida: B para leer, A para actuar.
Y con un orden deliberado que resultó ser la clave de todo el proyecto:
Primero lo que no puede romper nada.
C cae por su propio peso mientras haces B.
10. El giro: el manual que el fabricante ya había escrito
Faltaba una pieza.
Y aquí está el momento del artículo.
La jugada que a mí, en la puñetera vida, se me habría ocurrido.
Leer los datos estaba resuelto con la opción B.
Pero yo quería más: quería poder meter datos.
Altas de trabajadores en bloque, contratos, conceptos retributivos, incapacidades.
Todo lo que en un despacho se teclea cincuenta veces seguidas mientras se te va la vida.
¿Y cómo metes datos en un programa cerrado, sin API que llegue, sin romperlo y sin corromper el fichero de un cliente?
Pues explorando la pestaña de Utilidades apareció algo que yo, usando ese programa desde hace años, nunca había mirado con atención:
Importaciones. Ficheros .XLSX, .ODS, Nominaplus.
NominaSOL tiene un canal oficial de entrada masiva de datos.
Una puerta ancha, hecha por el fabricante, documentada, y abierta a todos sus clientes desde siempre.
Y entonces vino la petición que me dejó descolocado:
«Entra con tu usuario en la web de soporte y vamos a descargar la documentación de las tablas de importación.»
¿Perdona?
El razonamiento
Déjame explicártelo despacio, porque es precioso.
El fabricante nunca construyó una API laboral.
Cierto.
Pero sí necesita que sus clientes puedan cargar datos en masa.
Porque cuando una asesoría capta un cliente con ochenta trabajadores, nadie los teclea uno a uno.
Se importan desde una hoja de cálculo.
Y para que eso funcione, tiene que documentar con precisión absoluta qué estructura debe tener esa hoja: qué columna corresponde a qué campo, en qué orden, de qué tipo, con qué longitud máxima, qué valores admite cada casilla.
Esa documentación existe.
Está en su centro de ayuda, con sus artículos de importación en Excel o Calc y sus plantillas de campos.
Nunca la escribieron pensando en la inteligencia artificial.
La escribieron para el usuario que va a rellenar un Excel a mano.
Pero es, sin que nadie lo llamara así, un contrato técnico perfectamente especificado.
Conseguirla costó lo suyo
Y aquí un detalle que me encanta, porque demuestra que esto no fue magia.
El enlace desde dentro del programa no descargaba nada.
Y las direcciones de la web no se dejaban adivinar.
¿Cómo apareció?
Encontrando primero el manual equivalente de FACTUSOL, que reveló el patrón de las rutas.
Con ese patrón, el de NominaSOL salió solo.
Eso es investigación de verdad.
Rodear el obstáculo.
El resultado: 69 páginas, 19 ficheros distintos, 844 columnas.
Todo pasado a formato máquina y con las erratas del PDF corregidas, porque las tenía.
La documentación de importación es la API que el fabricante no sabía que había escrito.
La lección general
No te quedes con «NominaSOL» ni con «hoja de importación».
Quédate con el patrón, que sirve para tu programa sea cual sea:
Cuando un fabricante no te da una API que llegue, casi siempre te ha dado otra cosa: formatos de importación, exportaciones a Excel, plantillas, ficheros de intercambio, documentación de estructura.
Todo eso son especificaciones.
Todo eso son puertas.
Solo que estaban etiquetadas para humanos.
11. Y entonces la skill fracasada resultó ser el plano
Y ahora lo que te prometí al final del primer artículo.
Para construir la opción A —el robot que pulsa botones— hacía falta algo muy concreto: un mapa exacto de por dónde se navega el programa. Qué pestaña, qué grupo, qué icono, en qué orden, para cada tarea del ciclo mensual.
Ese trabajo es lento, aburrido y solo lo puede hacer alguien que use el programa a diario.
Y entonces, mientras investigaba, la propia herramienta me dijo algo que me dejó tonto:
«Tu skill de NominaSOL ya es la especificación funcional. Tiene mapeado pestaña, grupo e icono para todo el ciclo.»
Aquella skill.
La que no funcionó.
La que llevaba meses en una carpeta muerta de risa, y de la que me había reído yo mismo al abrirla.
Resulta que no estaba mal escrita: estaba incompleta. Le faltaban las manos. Pero como documento —como descripción minuciosa de cómo se trabaja realmente con ese programa— era exactamente el plano que hacía falta.
Su mapa de la cinta indicó dónde estaba cada cosa y ahorró horas de exploración a ciegas.
Yo había escrito la especificación técnica sin saber que era una especificación técnica.
Igual que el fabricante había escrito su API sin saber que la había escrito.
Y esa es, si me apuras, la moraleja de esta segunda entrega: el conocimiento profesional que vuelcas por escrito no se pierde aunque el primer intento fracase. Cambia de función. Espera. Y un día aparece la pieza que le faltaba.
Los seis meses no fueron a la basura.
Fueron el plano.
12. Hacia dónde vamos
Lo que quiero que te lleves de este segundo artículo:
Que exista una API no significa que te sirva.
Comprueba dos cosas: a qué datos llega —muchas solo atacan la versión en la nube— y qué tipo de API es.
Dato o proceso.
El dato está guardado y se puede leer. El proceso vive dentro del ejecutable y hay que pulsar el botón. Ninguna API de filas va a calcularte una nómina.
Descartar bien es construir.
El tiempo que dedicas a saber por dónde no ir no es tiempo perdido.
Si el dato vive en tu equipo, es tuyo.
No dependes de que el fabricante abra una puerta: dependes de que alguien sepa leerlo.
Cuando no hay API, busca la documentación de importación.
Es una especificación técnica disfrazada de manual de usuario.
Y no tires nada de lo que escribiste. Puede que sea el plano.
Con todo esto ya teníamos el mapa.
Faltaba lo más difícil: construirlo de verdad.
Y ahí es donde vino lo que no sale en los vídeos de LinkedIn.
Los errores.
El día que el programa me dijo que había importado ochenta trabajadores y no había importado ninguno.
El campo que estaba invertido.
La empresa que cambió sola a otro cliente.
Y el método que quedó al final, que son cinco principios que sirven igual para un conector que para un pasante nuevo.
De eso va la última entrega.
👉 Continúa en el artículo 3: «Así que le construí un conector a NominaSOL»
Ahora te toca a ti
Tres preguntas, y me las contestas abajo:
¿Sabes si el programa que usas tiene API, y a qué llega exactamente?
Lo que necesitas de él, ¿es dato o es proceso?
¿Has mirado alguna vez su documentación de importación?
Si has contestado que no a la tercera, ahí tienes tu tarde del domingo.
Puede que lleves años con una puerta abierta al lado y sin verla.
Quédate con la pregunta que de verdad importa, la que te ahorra dinero y disgustos: lo que quieres automatizar, ¿es un dato o es un proceso? Responderla bien es media batalla ganada.
Si quieres aprender a mirar así cualquier programa de tu despacho —y a decidir qué se puede automatizar y qué no—, te enseño exactamente cómo lo hago yo:
