Índice del boletín

• Dato curioso

• Ultimas noticias

• Información en bolsa

• Innovación IT

• Tip ABAP( Técnico )

• SAP Funcional

• Función de la Semana

• Liderazgo y Gestión

• Frase del Día

• Gracias por leer

🔍 Dato Curioso

Hay algo curioso que se repite en casi todos los proyectos SAP: las tareas que alguien define como “fáciles” suelen ser las que más se retrasan. No porque sean técnicamente complejas, sino porque esconden decisiones, dependencias y pruebas que no se ven a simple vista.

En muchos equipos ocurre lo mismo: lo que parece “solo un mapeo”, “un pequeño ajuste” o “tocar un campo” acaba creciendo cuando se empieza a analizar el impacto real. Aparecen validaciones cruzadas, datos históricos, integraciones, autorizaciones, pruebas en distintos escenarios y, sobre todo, el miedo a romper algo que lleva años funcionando. El sistema no avisa, pero la experiencia sí.

Lo curioso es que cuanto más senior es un consultor, menos utiliza la palabra “fácil”. No porque sepa menos, sino porque sabe más. Ha vivido suficientes proyectos como para entender que lo sencillo casi nunca es trivial y que los verdaderos problemas no están en el código o la parametrización, sino en todo lo que rodea a ese cambio.

Por eso, en SAP, cuando alguien dice “esto son 20 minutos”, normalmente no está midiendo el trabajo… está ignorando todo lo que no se ve. Y eso, paradójicamente, es lo que más tiempo acaba costando.

📰 Ultimas noticias

SAP ha publicado una noticia en su News Center en la que cuenta cómo BSH está reinventando su área financiera apostando de lleno por la nube con soluciones de SAP.

El foco del caso no está solo en una migración técnica, sino en un cambio profundo del modelo financiero. BSH busca pasar de unos procesos financieros tradicionales, fragmentados y muy dependientes de tareas manuales, a un entorno más estandarizado, automatizado y con datos en tiempo real. La nube se convierte aquí en el habilitador para ganar transparencia, velocidad de cierre y una mejor capacidad de análisis para la toma de decisiones.

Según explica SAP, uno de los objetivos clave del proyecto es simplificar y unificar los procesos financieros a escala global, reduciendo complejidad y dependencia de soluciones locales. Esto permite a los equipos de finanzas dedicar menos tiempo a tareas operativas y más a análisis de valor, planificación y apoyo real al negocio.

El caso de BSH refleja una tendencia muy clara en el ecosistema SAP: finanzas está dejando de ser un área puramente operativa para convertirse en un motor estratégico, y eso solo es posible cuando los procesos están bien definidos y soportados por plataformas cloud estables y escalables.

En resumen, la noticia muestra cómo la adopción de SAP en la nube no va solo de modernizar sistemas, sino de cambiar la forma de trabajar, eliminando fricción, mejorando la calidad del dato y reduciendo ese “caos organizado” que durante años ha sostenido muchos cierres financieros. Un ejemplo claro de cómo la transformación digital bien planteada impacta directamente en productividad real, no solo en tecnología.

💹 Información en Bolsa

Las acciones de SAP SE cotizan alrededor de 206 € por unidad en el mercado europeo este día de Reyes.

Esto refleja una fase de consolidación tras niveles más altos que vimos en 2025, cuando la acción alcanzó máximos históricos superiores a los 310 € durante ese año.

Este precio actual se encuentra por debajo de la media de 52 semanas y sugiere que el valor ha ajustado desde esos picos, aunque sigue mostrando movimiento en torno a niveles técnicos relevantes.

Perspectiva de mercado para SAP en 2026
Los analistas mantienen en general una visión positiva a medio plazo, con varios precios objetivo revisados al alza en 2025, incluso cuando los mercados ajustaron expectativas:

• Algunas firmas elevaron el precio objetivo de SAP por sus resultados sólidos y crecimiento de ingresos en la nube, con cifras objetivo cercanas a 300–330 € antes de 2026.

• Otros objetivos también subrayan la confianza de analistas en la transición a modelos cloud y el impulso de soluciones avanzadas.

Esto implica que, aunque el precio actual es inferior a los niveles de finales de 2025, hay expectativas sostenidas de crecimiento si la compañía sigue ejecutando bien su estrategia de transformación digital.

Clima de mercado y riesgos generales para 2026
En el contexto global, los mercados empiezan el año con cierto optimismo, pero también con riesgos presentes:

• Inversionistas advierten sobre riesgos de inflación asociados a fuertes inversiones en tecnología, lo que podría frenar expectativas de crecimiento bursátil si los bancos centrales cambian de estrategia.

• A nivel global hay proyecciones mixtas sobre la continuidad de la subida de los principales índices, con posibles altibajos por valoraciones elevadas, decisiones de política monetaria y percepción de burbuja tecnológica.

Todo ello será un factor a seguir para SAP y otros valores tecnológicos en 2026, ya que los movimientos macroeconómicos pueden influir tanto como los resultados empresariales.

En pocas palabras

SAP comienza 2026 con su acción cotizando en torno a 206 €, tras haber pasado por picos superiores a 310 € en 2025. Los analistas mantienen un sesgo general positivista moderado a medio plazo, respaldado por el crecimiento en soluciones cloud y capacidades tecnológicas. Sin embargo, el mercado global arranca el año con cierta cautela ante posibles rebrotes de inflación y valoraciones elevadas en tecnología, lo que podría traducirse en movimientos volátiles durante 2026.

🚀 Innovación IT

En innovación IT se habla mucho de velocidad, de automatización y de “hacer más en menos tiempo”. Pero hay una frase que sigue apareciendo en demasiadas conversaciones y que, lejos de impulsar la innovación, la frena desde el primer minuto: “esto es fácil, son 20 minutos”.

En SAP ( en IT en general ) esa frase rara vez es inocente. No porque la persona que la diga tenga mala intención, sino porque suele ignorar todo lo que no se ve. Un cambio puede parecer pequeño desde fuera, pero la realidad es que la complejidad no está en el gesto, sino en el contexto. Y la innovación empieza precisamente cuando dejamos de simplificar lo que no entendemos.

Un consultor no cobra por pulsar teclas ni por ejecutar una transacción. Cobra por saber qué tocar, cuándo tocarlo y, sobre todo, cuándo no hacerlo. Ese conocimiento no aparece de la nada. Es el resultado de años de experiencia, de proyectos que se complicaron, de pruebas que fallaron, de sistemas que reaccionaron de formas inesperadas y de decisiones que tuvieron consecuencias semanas o meses después. La innovación IT no consiste en correr más rápido, sino en evitar errores que otros ya cometieron.

Cuando alguien dice “esto es solo un mapeo”, normalmente no está viendo el impacto en integraciones, en datos históricos, en pruebas cruzadas, en autorizaciones, en cierres contables o en procesos que funcionan porque llevan años siendo compensados manualmente. El consultor sí lo ve. Y precisamente por eso sabe que esos “20 minutos” rara vez lo son. Innovar no es hacer cambios rápidos, es hacer cambios seguros, conscientes y sostenibles.

Hay una analogía que nunca falla: un mecánico puede cobrar una cantidad elevada por apretar un tornillo. No por el tornillo en sí, sino porque sabe cuál es, cómo llegar hasta él y qué ocurre si no se aprieta correctamente. En SAP pasa exactamente lo mismo. El valor no está en la acción visible, sino en todo el recorrido invisible que hay detrás.

Desde el punto de vista de la innovación IT, el verdadero riesgo no es tardar más de lo previsto, sino minusvalorar el conocimiento. Cuando se normaliza que todo es fácil, se empieza a tomar decisiones sin análisis, se recortan pruebas, se fuerzan plazos y se convierte la experiencia en algo prescindible. Y ahí es donde los sistemas dejan de evolucionar y empiezan a acumular deuda técnica y funcional.

Innovar en SAP no es hacer más cambios, es hacer mejores cambios. Es aceptar que la simplicidad aparente suele esconder complejidad real. Es respetar el conocimiento técnico y funcional como parte del diseño del sistema. Y es entender que si algo hoy parece fácil, es porque alguien ya recorrió antes un camino largo, resbaladizo y lleno de errores.

Por eso es importante acabar con la frase “esto es fácil”. No porque nada pueda ser sencillo, sino porque nada es trivial sin experiencia detrás. La innovación IT de verdad no nace de subestimar el trabajo, sino de valorar el conocimiento que hace posible que el sistema siga funcionando, evolucionando y aportando valor con el paso del tiempo.

En SAP, como en la vida profesional, lo que parece fácil casi nunca lo fue. Simplemente, alguien aprendió a hacerlo bien.

🧠 Tip ABAP

Un tip ABAP que marca mucha diferencia es usar correctamente TRY…CATCH con excepciones de clase, incluso en código que “nunca falla”.

Durante años se ha abusado de:

• SY-SUBRC

• validaciones defensivas interminables

• asumir que “esto siempre va a venir bien”

El problema es que cuando algo falla, falla mal: dumps inesperados, mensajes poco claros o errores difíciles de reproducir.

Usar excepciones de clase te obliga a pensar el error como parte del diseño, no como algo accidental. Un TRY…CATCH bien planteado no es más código, es mejor código.

Por ejemplo, cuando llamas a:

• métodos estándar

• clases de SAP

• conversiones de datos

• parsing de estructuras

• lógica reutilizable

esas operaciones pueden fallar aunque “normalmente no lo hagan”. Capturar la excepción te permite:

• controlar el flujo

• dar mensajes claros

• registrar el error

• evitar dumps

• y decidir conscientemente qué hacer

Además, el código se vuelve mucho más legible: queda claro qué puede fallar y cómo se gestiona. Eso reduce miedo a tocarlo en el futuro y mejora la mantenibilidad.

La regla práctica es simple: si una operación puede fallar y no depende del usuario, debería estar dentro de un TRY…CATCH.

Supongamos que tienes una conversión de datos o una llamada a un método estándar que en teoría siempre debería funcionar… hasta que un día no lo hace.

TRY.
    DATA(lv_number) = CONV i( lv_text ).
  CATCH cx_sy_conversion_no_number INTO DATA(lx_conv).
    MESSAGE 'El valor no es numérico y no se puede convertir'
            TYPE 'E'.
ENDTRY.

¿Qué está pasando aquí?

Se intenta convertir un texto a número.
Si el contenido no es válido, no hay dump.
El error se captura, se controla y se comunica de forma clara.

Sin TRY…CATCH, este caso acabaría en un dump inesperado que alguien tendría que analizar a posteriori.

Este mismo patrón aplica a:

• conversiones

• acceso a componentes dinámicos

• uso de expresiones modernas

• llamadas a métodos estándar

• lógica reutilizable

🧩 SAP Funcional

En este hilo de SAP Community se explica cómo funcionan y se configuran los Incompletion Procedures (procedimientos de incompletitud) para documentos de ventas, qué tipo de campos se pueden controlar y cómo influyen en el flujo de documentos.

El procedimiento de incompletitud en SD permite definir qué campos son requeridos para que un documento (por ejemplo un pedido de ventas) se considere completo. Esto se hace en IMG → SD → Basic Functions → Log of incomplete items → Define incompletion procedures.

Allí se asignan grupos de estado y se indican los campos que el sistema debe verificar.

El comentario explica que puedes crear logs de incompletitud para diferentes niveles (cabecera del documento, ítem, líneas de programación, datos de socio, etc.) y que cada uno puede configurarse con diferentes grupos de estado. Estos estados determinan si el documento se puede procesar en pasos posteriores como entrega o facturación si faltan datos.

📍 Un ejemplo práctico que surge en el foro es el caso en que alguien quiere que el sistema muestre una advertencia si falta el número de material en el pedido, sin dejar que el documento se guarde incompleto. El usuario explica cómo añadir este campo al procedimiento y asignarlo al tipo de documento de ventas para que el sistema ejecute esa comprobación.

Este tipo de configuraciones es un claro ejemplo de cómo puedes forzar calidad de datos en ventas sin necesidad de código, usando parametrización estándar de SAP SD.

🔎 Función de la Semana

¿Para qué sirve OPEN DATASET?

Se usa cuando necesitas:

• generar ficheros para integraciones

• leer ficheros recibidos por otros sistemas

• procesar interfaces batch

• trabajar sin SAP GUI

• ejecutar procesos automáticos

Es la base de muchísimas interfaces clásicas SAP.

Formas de usar OPEN DATASET

1️⃣ Abrir un fichero para lectura

OPEN DATASET lv_file FOR INPUT IN TEXT MODE ENCODING DEFAULT.

Se usa para leer un fichero ya existente.

Luego se lee línea a línea con:

READ DATASET lv_file INTO lv_line.

2️⃣ Abrir un fichero para escritura

OPEN DATASET lv_file FOR OUTPUT IN TEXT MODE ENCODING DEFAULT.

Crea el fichero o lo sobrescribe si ya existe.

Se escribe con:

TRANSFER lv_line TO lv_file.

3️⃣ Abrir un fichero para añadir contenido

OPEN DATASET lv_file FOR APPENDING IN TEXT MODE ENCODING DEFAULT.

Añade contenido al final del fichero, sin borrar lo existente.

Muy usado para:

• logs

• acumulación de datos

• ficheros diarios

TEXT MODE vs BINARY MODE

• TEXT MODE

  • lectura/escritura línea a línea

  • ficheros planos (TXT, CSV, etc.)

• BINARY MODE

  • lectura/escritura binaria

  • PDFs, imágenes, ZIPs

  • sin interpretación de líneas

Ejemplo:

OPEN DATASET lv_file FOR INPUT IN BINARY MODE.

Codificación (muy importante)

Puedes indicar la codificación explícitamente:

ENCODING DEFAULT
ENCODING UTF-8
ENCODING NON-UNICODE

Esto evita problemas de acentos, caracteres especiales y sistemas externos.

Cierre del fichero (obligatorio)

Siempre debes cerrar el fichero:

CLOSE DATASET lv_file.

No cerrarlo puede provocar:

• bloqueos

• ficheros corruptos

• errores en ejecuciones posteriores

Control de errores

Después de cada operación, revisa SY-SUBRC:

• 0 → correcto

• ≠ 0 → error

Ejemplo:

IF sy-subrc <> 0.
  MESSAGE 'Error accediendo al fichero' TYPE 'E'.
ENDIF.

Errores comunes

❌ Usar rutas no autorizadas en AL11
❌ Olvidar cerrar el fichero
❌ No controlar SY-SUBRC
❌ Usar TEXT MODE para binarios
❌ Pensar que sirve para frontend

Regla práctica

👉 Si el fichero vive en el servidor y el proceso es automático → OPEN DATASET.
👉 Si el fichero es para el usuario → GUI_UPLOAD / GUI_DOWNLOAD.

👑 Liderazgo y Gestión

Un buen líder entiende que la velocidad es importante, pero también sabe que la velocidad mal gestionada es una de las principales fuentes de caos organizado. Exigir rapidez sin entender el contexto técnico y funcional no acelera los resultados; simplemente desplaza los problemas hacia adelante. En SAP, casi nada es lineal. Un pequeño cambio puede tener impacto en datos históricos, integraciones, cierres, autorizaciones o procesos que llevan años funcionando de una forma muy concreta. Ignorar eso no es ser ágil, es ser ingenuo.

Tiene que saber marcar límites. No todo puede hacerse “para ayer” y no todo debe estimarse en base a lo que parece desde fuera. Parte del liderazgo consiste en aceptar que hay una complejidad invisible y trasladarla hacia arriba, aunque no siempre sea cómodo. Cubrir al equipo, explicar riesgos y defender tiempos realistas es una responsabilidad, no una debilidad.

También es clave el mensaje que se transmite al consultor. Cuando un líder deja claro que, si algo se complica, se puede hablar, reajustar timings o replantear el enfoque, está creando un entorno de confianza. Ese entorno es el que permite que los problemas se detecten antes, que se comuniquen sin miedo y que no se tomen atajos peligrosos solo para cumplir una fecha. Un consultor que se siente respaldado trabaja mejor, piensa más y se equivoca menos.

Exigir rapidez sin dar tranquilidad suele provocar el efecto contrario al buscado: el consultor deja de anticipar riesgos, reduce pruebas, calla dudas y entra en modo supervivencia. El sistema puede seguir funcionando, pero el desgaste empieza a acumularse. Y eso es precisamente el caos organizado del que hablamos en este boletín: todo avanza, pero a costa de personas compensando procesos mal gestionados.

Un buen líder no elimina la presión (porque siempre existe), pero sí la gestiona. Sabe cuándo apretar y cuándo aflojar. Sabe que hay momentos para ir rápido y otros para ir bien. Y, sobre todo, entiende que en SAP decidir con criterio y proteger al equipo suele ser mucho más productivo que exigir resultados inmediatos sin margen de maniobra.

Al final, liderar en SAP no es pedir que todo sea fácil, sino asumir que no lo es… y actuar en consecuencia. Ese es el tipo de liderazgo que convierte el caos organizado en productividad real.

💬 Frase del Día

El conocimiento no aparece de la nada. Detrás de cada solución rápida hay años de experiencia, errores, formación y decisiones difíciles. Valorar lo que sabes no es soberbia, es respeto por el camino recorrido.

Cuando alguien minimiza tu trabajo diciendo que “es fácil”, no está viendo todo lo que hay detrás. Tú sí. Y eso es lo que realmente tiene valor.

🙌 Gracias por leer

Y hasta aquí llega el boletín de hoy.

Gracias por haber llegado hasta el final, por dedicar unos minutos a leer, reflexionar y compartir este espacio semana tras semana. Este boletín tiene sentido gracias a vosotros, a los comentarios, a las conversaciones que se generan y a todo lo que se aprende en el camino.

Hoy, además, es un día especial, así que no quería terminar sin desearos de corazón un muy feliz Día de Reyes. Ojalá venga cargado de buenos momentos, calma, ilusión… y algún que otro regalo, aunque sea en forma de tiempo, aprendizaje o buenas noticias.

Nos seguimos leyendo muy pronto.
Un fuerte abrazo y ¡feliz Día de Reyes! 🎁✨