🧨 SAPocalypsis Now Episodio 16

¿Quieres descubrir cómo la IA puede transformar la forma en que las empresas prospectan?

En el MWC 2026, expondremos junto a Enginy nuestra solución para obtener leads de calidad listos para contactar mediante campañas multicanal totalmente automatizadas. Una gran oportunidad para impulsar la eficiencia de tu equipo comercial.

El proyecto de TicketBAI llevaba meses absorbiendo la vida del equipo. No era un desarrollo cualquiera. No era un ajuste de precios ni una mejora de formulario. Era cruzar una frontera invisible entre SAP y Hacienda, entre lo interno y lo legal, entre un error técnico y una consecuencia fiscal real.

Para quien no lo tenga fresco, TicketBAI es el sistema obligatorio implantado por las Haciendas Forales del País Vasco que obliga a que cada factura emitida quede registrada electrónicamente casi en tiempo real. Cada documento debe generar un XML estructurado, incluir un hash encadenado con la factura anterior, firmarse digitalmente con un certificado válido y enviarse a través de una API oficial. Hacienda responde validando o rechazando. Si algo falla en la cadena, la siguiente factura no es válida. No es solo tecnología. Es normativa. Es trazabilidad fiscal. Es responsabilidad.

Elena sabía todo eso mejor que nadie.

Era una consultora completa, de esas que no necesitan levantar la voz para que el equipo la siga. Programadora brillante, experta en SD, con años de experiencia encima y la serenidad que dan los proyectos difíciles superados. Cuando le asignaron la responsabilidad técnica del TicketBAI, lo asumió con esa mezcla de respeto y ambición que tienen los buenos profesionales.

Durante meses trabajaron como si el resto de la empresa estuviera en pausa. Tres programadores, dos responsables (entre ellos Elena) y tres funcionales de SD y FI. Proyecto presencial. Oficina compartida. Cafés interminables hablando de APIs REST, de certificados digitales, de tokens, de respuestas 200 y errores 400. El hash no cuadraba, lo ajustaban. El XML no validaba, lo corregían. El encadenamiento rompía, lo revisaban. Poco a poco, el flujo empezó a funcionar.

Habían diseñado un mini monitor para visualizar el estado de las facturas enviadas y un programa masivo para ejecutar envíos por rango de fechas. Y, por razones que en su momento parecieron lógicas y que luego nadie cuestionó, existían dos tablas de parametrización casi idénticas: ZPARAM1_HARD y ZPARAM1_HARD2. En ambas se definían los endpoints de la API, los tokens, los certificados, los flags de entorno. Una alimentaba el monitor. La otra el programa de ejecución. Al principio tenía sentido. Después, simplemente se quedó así.

Las UAT fueron largas, exigentes y satisfactorias. Hacienda aceptaba las facturas en entorno de pruebas. El hash encadenaba correctamente. El equipo respiraba ilusión. Habían construido algo complejo y funcionaba. Se fijó la fecha de puesta en producción para un martes a las ocho de la mañana. Para celebrarlo, reservaron mesa en un restaurante bueno, no el bar habitual. Era una pequeña recompensa tras meses de trabajo intenso.

El lunes por la tarde, Elena se quedó revisando todo antes del gran día. Entró en productivo, abrió la tabla ZPARAM1_HARD y actualizó el endpoint al oficial, cambió el token, validó el certificado, revisó dos veces los campos críticos. Guardó. Sintió esa tranquilidad que aparece cuando marcas mentalmente una tarea como completada. Cerró sesión. Se fue a casa convencida de que todo estaba listo.

No abrió ZPARAM1_HARD2.

No porque no supiera que existía. No porque no la considerara importante. Sino porque las dos tablas se parecían tanto que su mente dio por hecho que ya había revisado ambas. El cerebro humano es extraordinario rellenando huecos cuando cree reconocer patrones.

El martes llegó con ese silencio eléctrico que precede a los momentos importantes. A las siete y cincuenta estaban todos en la sala, con café en la mano y bromas contenidas. A las ocho en punto, Elena lanzó el programa masivo para enviar las facturas pendientes dentro del rango seleccionado. Había unas treinta previstas, pero solo seis existían realmente en ese periodo.

El monitor comenzó a mostrar actividad. Enviado. Aceptado. Enviado. Aceptado. Las primeras validaciones llegaron sin problemas. Alguien sonrió. Otro comentó que parecía que todo había salido perfecto. Eran las ocho y veinte y el ambiente ya se estaba relajando.

Lo que ellos no sabían es que, en otra planta del edificio, el director financiero había recibido una notificación automática del sistema foral. Un aviso de incidencia en el encadenamiento TBAI. La séptima factura emitida manualmente tras la batería inicial había sido rechazada. El hash no coincidía con la secuencia esperada. En el portal oficial de Hacienda ya aparecían seis facturas registradas. Oficiales. Con número válido.

La puerta de la sala se abrió a las ocho y media. No entró un programador. Entró el director financiero con el portátil bajo el brazo y una expresión que no encajaba con el ambiente distendido que había dentro.

—¿Habéis terminado? —preguntó.

Elena asintió, aún con la sonrisa leve en el rostro.

—Todo correcto. Las seis aceptadas.

El director giró el portátil hacia ellos. En la pantalla se veía el portal de Hacienda. Las seis facturas estaban registradas. La siguiente, rechazada. El sistema interno había intentado continuar la secuencia con un hash distinto al que Hacienda esperaba.

Elena sintió cómo el pulso se aceleraba. Abrió rápidamente la tabla ZPARAM1_HARD2. Ahí estaba. El endpoint seguía apuntando a la configuración anterior, que en ese momento estaba enlazada con validación oficial. Las seis facturas se habían enviado desde esa tabla. El monitor leía de la otra, la correcta. El programa de ejecución, no.

Habían comunicado seis facturas reales desde una configuración que no habían sincronizado correctamente con el encadenamiento interno. Hacienda había aceptado las seis. Pero la séptima ya no encajaba.

La facturación quedó bloqueada. Legalmente no podían emitir nuevas facturas hasta resolver el encadenamiento. Comercial empezó a llamar. Producción preguntaba por qué no se generaban los QR. El restaurante empezó a parecer una broma lejana.

Durante las siguientes horas, la sala dejó de ser un lugar de celebración y se convirtió en un centro de crisis. Había que identificar exactamente qué había ocurrido, analizar el hash, abrir un ticket urgente con soporte foral, solicitar anulación administrativa de las seis facturas y justificar el error como incidencia técnica de entorno. Cada minuto era dinero parado. Cada silencio pesaba.

El director no gritó. Pero el hecho de que se hubiera enterado antes que el equipo dolió más que cualquier reproche. Elena asumió la responsabilidad sin rodeos. Explicó el error. Explicó la tabla. Explicó el despiste.

A las doce y cuarenta y siete llegó la respuesta preliminar de Hacienda. Incidencia registrada. Proceder a verificación manual de números para anulación. Elena se encargó personalmente de revisar uno a uno los documentos. Confirmó importes, números, fechas. Enviaron la validación. A las trece y treinta y dos llegó la confirmación de anulación administrativa. El encadenamiento quedó limpio. La siguiente factura pasó. El sistema volvió a respirar.

Cuando finalmente levantaron la vista, el restaurante seguía esperando. Elena miró al equipo y dijo la verdad completa. Que el error había sido suyo. Que había dado por revisada una tabla que no lo estaba. Que no había querido preocuparles hasta tener claro el alcance.

Nadie la señaló. Pero todos entendieron lo que había pasado.

Ese día aprendieron algo que ningún manual técnico enseña: en proyectos fiscales en tiempo real no existe el “parece que está”. No existe el “seguro que lo revisé”. Existen listas de verificación, revisiones cruzadas y doble validación antes de pulsar ejecutar.

Porque cuando trabajas con Hacienda, el error no se queda dentro de SAP.

Sale fuera.

Y si Dirección se entera antes que tú… el susto ya es oficial.

Al final llegaron al restaurante. Tarde. Con la adrenalina aún en el cuerpo. Brindaron igual. Pero esa comida ya no celebraba solo un proyecto terminado. Celebraba que habían salido de algo que pudo ser mucho peor.

Porque en sistemas críticos, el verdadero SAPOCALYPSIS no empieza con un error gigante.

Empieza con una tabla que se parece demasiado a otra.

Y con la peligrosa frase: “Esto ya lo revisé.”

📚 Moralejas

En proyectos críticos no basta con saber mucho.
No basta con haber probado todo.
No basta con que el equipo sea brillante.

Cuando el sistema se conecta con Hacienda, con bancos o con cualquier organismo oficial, ya no hablamos solo de tecnología… hablamos de responsabilidad real.

Los errores más peligrosos no nacen de la ignorancia.
Nacen de la confianza excesiva.
De asumir que algo “ya está hecho”.
De no revisar lo que creemos recordar haber revisado.

TicketBAI no falló.
SAP no falló.
Falló algo mucho más humano: la certeza equivocada.

Y la lección no es trabajar con miedo.

Es trabajar con método.

Checklist.
Revisión cruzada.
Entornos claros.
Responsabilidad compartida.

Porque cuando el exterior se conecta a tu sistema,
cada pequeño detalle deja de ser técnico
y se convierte en legal.

Y en esos momentos, lo que realmente protege a un equipo no es no equivocarse…
es asumir el error, afrontarlo y aprender antes de que el susto sea irreversible.