Mensaje de cierre de año: crecimiento, logros y visión estratégica de Aplirh
30 de diciembre de 2025
PFCGMASSVAL en SAP: lo que realmente aporta (y lo que no)
22 de enero de 2026
Guía técnica y práctica para el diagnóstico de autorizaciones en SAP.
Cargo: Consultora senior
Fecha: Enero 2026
Diagnosticar problemas de autorizaciones en SAP no pasa por interpretar al pie de la letra lo que aparece en pantalla, sino por entender qué está intentando hacer el sistema y en qué momento del proceso deja de poder hacerlo.
El mensaje “No tienes autorización…” es solo el resultado final de una serie de validaciones internas. Antes de llegar ahí, SAP evalúa distintos objetos, valores y contextos. Si nos quedamos solo con ese mensaje, estamos viendo el final del proceso sin haber entendido realmente todo lo que ocurrió antes.
Por eso, muchas incidencias de autorizaciones terminan resolviéndose de una forma poco sólida. Se corrigen “a prueba y error”, se agregan permisos de más, el problema desaparece por un tiempo… y tarde o temprano vuelve a aparecer. En el peor de los casos, estas soluciones rápidas acaban generando riesgos de cumplimiento o complicaciones en auditoría.
Por qué tantas incidencias se diagnostican mal
Tomar SU53 como una verdad absoluta
SU53 es una herramienta útil, sin duda, pero es limitada por diseño. Solo muestra el último chequeo de autorización que falló en la sesión del usuario.
Diagnosticar problemas de autorizaciones en SAP no pasa por interpretar al pie de la letra lo que aparece en pantalla, sino por entender qué está intentando hacer el sistema y en qué momento del proceso deja de poder hacerlo.
El mensaje “No tienes autorización…” es solo el resultado final de una serie de validaciones internas. Antes de llegar ahí, SAP evalúa distintos objetos, valores y contextos. Si nos quedamos solo con ese mensaje, estamos viendo el final del proceso sin haber entendido realmente todo lo que ocurrió antes.
No trazar correctamente el comportamiento real del sistema
El segundo gran error es no observar cómo SAP evalúa realmente las autorizaciones.
Muchos análisis se quedan en:
- “El objeto está en el rol”
- “En SUIM aparece”
- “Antes funcionaba”
Del síntoma a la causa raíz: un enfoque ordenado
El objetivo de un buen diagnóstico no es simplemente que “ya funcione”. La idea es que funcione por el motivo correcto, con los permisos justos y sin generar problemas más adelante.
Seguir este enfoque evita soluciones rápidas que hoy funcionan, pero mañana vuelven a generar incidencias o riesgos innecesarios.
Qué te aporta esta guía
Sepas cuándo SU53 es suficiente y cuándo no
Entiendas por qué STAUTHTRACE es clave en escenarios reales
Uses SUIM para diseñar soluciones correctas, no rápidas
Evites errores habituales que generan retrabajo y riesgos
SU53: el primer reflejo tras el error (y sus límites)
Lo que SU53 realmente está mostrando
Cuando el usuario ejecuta la SU53, SAP no está contando toda la historia. Lo único que hace es mostrar el último punto en el que el sistema decidió decir “no”. Antes de llegar ahí, SAP ya ha pasado por varios pasos: ha evaluado distintos objetos de autorización, ha probado diferentes valores y ha intentado más de un camino para permitir la acción. Nada de eso queda reflejado en la SU53. Solo vemos el final del proceso, no todo el recorrido.
Por eso la SU53 es tan útil para capturar el síntoma, pero tan peligrosa si se usa para sacar conclusiones definitivas. En algunos casos, lo que muestra es claro: un objeto funcional concreto, valores coherentes y un error fácil de entender. Ahí, la corrección suele ser directa.
El problema aparece cuando la SU53 devuelve información que no encaja del todo, como valores PFCG, referencias a DEBUG o menciones a S_NOTE. En esos escenarios, muchos diagnósticos se desvían. Estos valores no indican que falte una autorización funcional, sino que SAP ya está en una fase más técnica, intentando validar perfiles, contexto o lógica interna después de no haber encontrado una vía válida para completar la acción.
Es como ver el último eslabón de una cadena rota y asumir que ese es el problema, cuando en realidad la rotura ocurrió mucho antes.
El error más común en estos casos es intentar “arreglar” directamente lo que muestra la SU53, sin más análisis ni criterio. Y casi siempre, eso termina resolviendo el síntoma, pero no la causa real del problema.
La traza: cuando toca dejar de “interpretar” y empezar a “ver” (STAUTHTRACE)
Llega un momento en el diagnóstico en el que la SU53 simplemente ya no aporta más información. No porque sea una mala herramienta, sino porque ya cumplió su función y no puede ir más allá.
En ese punto, STAUTHTRACE se vuelve clave. Es la herramienta que permite ver con claridad qué autorizaciones está evaluando SAP, en qué orden lo hace y con qué valores reales, no con los valores “teóricos” que uno espera ver en los roles. Aquí ya no se trata de suposiciones, sino de observar exactamente cómo se está comportando el sistema.
Además, en entornos con balanceo de carga, STAUTHTRACE tiene una ventaja importante: permite capturar la ejecución incluso cuando el usuario va cambiando de instancia. Esto es especialmente útil en escenarios donde el error aparece de forma intermitente y “a veces pasa y a veces no”.
ST01 sigue siendo útil cuando se necesita trazar algo más que autorizaciones (RFCs, kernel, problemas técnicos), pero para diagnóstico puro de autorizaciones, STAUTHTRACE es hoy la opción más clara y segura.
Guía paso a paso: cómo ejecutar una traza a un usuario con STAUTHTRACE
0
Preparación (30 segundos que ahorran 30 minutos)
Antes de activar nada, asegúrate de tener el usuario afectado (ID exacto), el escenario claro: qué transacción, qué botón, qué acción exacta y una ventana corta de tiempo para reproducirlo (ideal: 1 intento)
Y dile al usuario: “Cuando te diga, entras y haces SOLO ese paso. No navegues, no pruebes otras cosas.”
1
Entra en STAUTHTRACE
- Ejecuta la transacción STAUTHTRACE
- Verifica que estás en el sistema/mandante correcto (esto evita trazas “vacías”)
2
Activa la traza para el usuario concreto
Busca la opción de activar/encender traza. Configura:
- Usuario: el afectado (uno solo)
- Tipo de traza: Authorization checks (autorizaciones)
- Si existe opción de filtros / granularidad, usa lo más acotado posible
3
Pide al usuario que reproduzca el problema (una sola vez)
4
Desactiva la traza inmediatamente
5
Visualiza la traza y filtra
Entra en la opción de Display/Show Trace. Aplica los filtros:
- Por usuario
- Por rango de tiempo (si la opción existe, acótalo a los minutos del test)
6
Como interpretar el resultado
Antes de entrar en el detalle de cada código, es importante tener claro cómo debe leerse una traza de autorizaciones. El resultado de una traza no se interpreta como una lista de errores independientes, sino como una secuencia de decisiones que SAP va tomando mientras intenta ejecutar una acción. Cada verificación devuelve un código RC que indica si el sistema puede continuar por ese camino o si debe descartarlo y probar otra alternativa.
Por eso, el valor de un RC solo tiene sentido dentro de su contexto y en relación con los checks anteriores. Entender qué significa cada código te permite distinguir entre la causa real del problema y los efectos secundarios de un flujo que ya se ha desviado, evitando correcciones innecesarias o incorrectas.
Códigos RC en STAUTHTRACE: Significado y Cómo Interpretarlos
SUIM: del diagnóstico a la corrección correcta
Después de analizar el síntoma con SU53 y entender el comportamiento real del sistema con una traza, llega una pregunta clave:
“Vale, ya sé qué autorización falta… ¿y ahora dónde la corrijo?”
Aquí es donde entra SUIM. No como herramienta de diagnóstico en tiempo real, sino como puente entre el análisis técnico y el diseño correcto del modelo de autorizaciones.
SUIM (User Information System) es la transacción que permite consultar y analizar el modelo de autorizaciones de forma estructurada. A diferencia de SU53 o STAUTHTRACE, SUIM no observa la ejecución, sino el diseño: qué roles existen, qué autorizaciones contienen y qué usuarios las tienen asignadas. Es, en esencia, el mapa del sistema de autorizaciones.
Cuando se llega a SUIM después de haber entendido el problema, la pregunta ya no es “¿dónde añado esto?”, sino “¿dónde tiene sentido que exista?”. Y esa diferencia, aunque parezca sutil, cambia por completo el resultado. Añadir una autorización en cualquier rol que tenga el usuario puede resolver el caso puntual, pero también puede introducir ruido, incoherencia o riesgo en el modelo. Elegir el rol adecuado, en cambio, obliga a entender para qué fue creado, a quién representa y qué procesos debería cubrir. Obliga, en definitiva, a pensar.
Ese es el punto en el que el trabajo deja de ser reactivo. Ya no se trata solo de responder a un fallo, sino de proteger la lógica del sistema frente al desgaste del día a día. Porque los modelos de autorizaciones no se rompen de golpe; se deterioran poco a poco, incidencia tras incidencia, cuando se prioriza la rapidez sobre el sentido.
Un diagnóstico bien hecho no solo permite que el usuario continúe, sino que deja el sistema un poco más limpio, un poco más claro, un poco más defendible. Y cuando eso ocurre de forma constante, las incidencias futuras son más fáciles de entender, las auditorías menos tensas y el propio modelo empieza a jugar a favor, no en contra.
Al final, resolver autorizaciones en SAP no va de saber qué transacción usar, sino de saber cuándo parar, cuándo observar y cuándo decidir. Porque el error siempre es visible. El criterio, en cambio, se construye con el tiempo… y se nota en el sistema que queda después.
