🧨 SAPocalypsis Now Episodio 17

¿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.

Había algo en los formularios de factura que siempre imponía respeto.

No eran simples documentos. Eran la cara visible de todo el sistema. Lo último que ve el cliente después de que ventas, logística y finanzas hayan hecho su trabajo. Si algo salía mal ahí… no era un error técnico. Era un problema visible, incómodo y público.

Y aquel formulario… llevaba meses funcionando.

Era un Adobe Form de facturación de ventas, uno de esos formularios complejos que con el tiempo acumulan capas y capas de lógica: condiciones, cálculos, posiciones, subtotales, descuentos, impuestos… y pequeñas piezas de código que alguien escribió hace años y que ahora nadie recuerda del todo.

Un día llegó la solicitud.

Había que añadir nuevos campos. Nada fuera de lo normal. Algunos datos adicionales que negocio quería mostrar en la factura para mejorar la información al cliente.

El proyecto empezó como empiezan todos: con calma.

Analicé el formulario, localicé las secciones afectadas, identifiqué los nodos de datos, ajusté el layout, añadí la lógica necesaria… y poco a poco las modificaciones fueron tomando forma. Durante semanas trabajé sobre él. Probando, ajustando, revisando.

El formulario iba bien.

Las pruebas iban bien.

Y entonces, cuando el desarrollo ya llevaba casi un par de semanas de trabajo encima, llegó el mensaje.

El proyecto se detenía.

Había aparecido un problema en producción.

Para una casuística concreta (una sociedad específica) el formulario estaba generando algo extraño: una cabecera duplicada. Los datos del cliente aparecían dos veces… superpuestos. Texto encima de texto. Información ilegible.

Un caos visual.

La factura existía… pero no se podía leer.

Y la orden fue clara:

Había que revertir todos los cambios del formulario.

Recuerdo perfectamente la sensación en ese momento.

Esa mezcla entre incredulidad y resignación.

Después de un mes de trabajo… volver atrás.

Por suerte, los Adobe Forms tienen versionado. Así que respiré hondo, recuperé la versión anterior, revertí los cambios y preparé el transporte urgente para solucionar el incidente en producción.

Y así terminó aquella primera parte.

El formulario volvió a su estado anterior.

El problema desapareció.

El incidente quedó cerrado.

Y yo… seguí con otros desarrollos.

Durante un tiempo dejé de pensar en ese formulario.

Hasta que, unas semanas más tarde, alguien volvió a mencionarlo.

El proyecto se retomaba.

Habían pasado ya más de dos meses desde el inicio de aquella modificación. Y ahora tocaba volver a abrir aquel Adobe Form… como si nada hubiera pasado.

Así que retomé el trabajo.

Recuperé mis cambios. Volví a aplicar las modificaciones. Revisé todo de nuevo, probé los escenarios, validé los datos… y finalmente envié el formulario al entorno de pruebas.

Todo parecía correcto.

Hasta que llegó la respuesta del cliente.

Las modificaciones estaban bien.

Los nuevos campos funcionaban.

Pero había un problema.

Un problema que nadie esperaba.

Según el funcional, los valores de los totales estaban mal.

No en los campos nuevos.

No en lo que habíamos desarrollado.

En los totales de las posiciones de factura.

Valores que nadie había pedido modificar.

Valores que (según ellos) ya no coincidían con lo que salía antes.

Recuerdo quedarme mirando el mensaje unos segundos.

“¿Distintos?”

¿Cómo que distintos?

Me enviaron capturas.

Un antes.

Un después.

Y sí… era verdad.

Los números no coincidían.

No era una diferencia enorme. Pero estaban alterados. Y lo suficiente como para que alguien dijera: esto no es correcto.

Así que empecé a revisar.

Primero el layout.

Luego el binding.

Luego el código.

Después las funciones.

Volví a recorrer cada parte del formulario con calma. Buscando algo que hubiera tocado sin darme cuenta.

Nada.

Todo parecía exactamente igual.

Revisé otra vez.

Nada.

Entonces empecé a sentir esa sensación que todo consultor conoce.

Esa pequeña inquietud que empieza en el estómago y que poco a poco va creciendo.

La sensación de que algo no cuadra.

Volví a escribir al funcional.

Le expliqué los cálculos.

Le enseñé cómo se generaban los valores.

Le mostré de dónde venían los importes.

Y aunque los números eran distintos… los cálculos eran correctos.

Incluso empecé a sospechar algo extraño.

Tal vez… los valores anteriores no estaban bien.

Tal vez el formulario antiguo calculaba algo incorrecto.

Pero claro… eso era difícil de afirmar sin pruebas.

Y mientras tanto el tiempo seguía corriendo.

Así que decidí hacer algo más radical.

Recuperé la versión exacta de producción del formulario.

La versión original.

La que llevaba meses funcionando con la ultima versión que pase a producción

La transporté al entorno de pruebas.

Y ejecuté el mismo ejemplo.

Esperando que todo volviera a coincidir.

Pero no.

El valor seguía saliendo diferente.

En ese momento recuerdo quedarme completamente en silencio frente a la pantalla.

Porque aquello ya no tenía sentido.

La versión original… daba el mismo resultado que la modificada.

Pero el funcional insistía en que estaba mal.

Y entonces llegó ese momento que todos hemos vivido alguna vez.

Ese momento en el que piensas:

“Algo se me está escapando… y no sé qué es.”

Ahí fue cuando decidí pedir ayuda.

Llamé a un compañero.

Un compañero muy bueno. Funcional. De esos que entienden el negocio de verdad.

Nos sentamos juntos.

Y empezamos a revisar todo desde cero.

Formulario.

Cálculos.

Funciones.

Condiciones.

Esquema de precios.

Cada línea.

Cada llamada.

Cada dato.

Durante un buen rato todo parecía correcto. Demasiado correcto.

Hasta que, en algún punto del análisis… lo vimos.

El formulario estaba mostrando valores provenientes del esquema de cálculo.

Dentro de ese esquema aparecía una clase de condición 920.

Esa condición llamaba a una función Z920.

Una función que realizaba ciertos cálculos adicionales.

Y al revisar esa función… encontramos algo interesante.

Tenía varias versiones.

Cambios realizados en 2024.

Cambios realizados en 2025.

La lógica había evolucionado.

Había mejoras.

Ajustes.

Correcciones.

Los cálculos actuales eran correctos… según la lógica actual.

Así que decidimos reproducir el proceso completo.

Creamos un pedido.

Los cálculos eran correctos.

Generamos una factura.

También correcto.

Todo funcionaba exactamente como debía.

Y entonces nos dimos cuenta.

Los ejemplos que el funcional estaba utilizando… no eran actuales.

Eran PDF antiguos.

Facturas descargadas hacía tiempo.

Facturas generadas con versiones anteriores del sistema.

Versiones donde la función Z920 tenía una lógica distinta.

Los números no coincidían… porque el sistema había evolucionado.

Los cálculos habían cambiado.

Y el formulario… simplemente estaba mostrando lo que debía mostrar.

Habíamos pasado horas revisando código.

Horas dudando.

Horas pensando que algo estaba roto.

Pero no.

Nada estaba mal.

Solo estábamos comparando el presente… con documentos del pasado.

Recuerdo perfectamente el momento en que lo entendimos.

Primero silencio.

Luego una pequeña sonrisa.

Y finalmente esa sensación extraña de alivio mezclado con agotamiento.

Porque durante un buen rato… de verdad creí que había roto algo importante.

Y cuando vi que incluso la versión restaurada de producción seguía mostrando los mismos valores…

Por un momento pensé:

“Esto se ha roto de verdad.”

Pero no.

Solo faltaba algo tan simple como ejemplos actuales.

Ejemplos reales.

Datos del sistema actual.

Aquella experiencia me dejó una lección muy clara.

En SAP, muchas veces el problema no está en el código.

Ni en el formulario.

Ni en el sistema.

A veces el problema está en las referencias con las que estamos comparando.

Porque cuando trabajamos con ejemplos antiguos…

Podemos acabar persiguiendo errores que en realidad no existen.

Y si algo me llevé de aquella historia fue otra cosa aún más importante.

La tranquilidad de saber que detrás había un equipo.

Porque cuando uno empieza a dudar de todo… tener a alguien al lado que revise contigo, que cuestione lo mismo que tú y que mire el problema desde otro ángulo…

Puede marcar la diferencia entre perder la cabeza… o encontrar la solución.

Así que desde aquí, gracias a ese compañero funcional.

Él sabe quién es.

Y sabe perfectamente que, en medio de aquel pequeño caos… fue clave para que encontráramos la verdad detrás de aquellos números.

Porque al final, incluso en los momentos de mayor confusión…

En SAP también se sobrevive mejor cuando no estás solo.

📚 Moralejas

En SAP no siempre gana quien tiene razón primero… sino quien entiende qué está comparando realmente.

Muchas discusiones técnicas nacen de algo mucho más simple de lo que parece:
ejemplos antiguos, datos distintos o escenarios que ya no existen en el sistema actual.

Antes de entrar en un largo debate por correo o por mensajes, muchas veces la mejor solución es la más sencilla: sentarse juntos, compartir pantalla y revisar el caso con datos actuales.

Porque cuando todos miran el mismo ejemplo, en el mismo sistema y en el mismo momento…
la mayoría de los “errores” desaparecen en minutos.

Y sobre todo, recuerda esto:

Un buen equipo no es el que nunca discute.
Es el que sabe discutir con respeto… hasta encontrar la verdad.