Análisis de autorizaciones. Traza.

La gestión de autorizaciones en Sap es un tema complejo, sobre todo si queremos

restringir el acceso a los usuarios a su ambito de actuación y funciones, evitando
la modificación o consulta de datos en módulos para los que no debería de estar
autorizado.

En esta entrada del blog no voy a entrar en profundidad en el tema de

autorizaciones, lo que requeriria una serie de articulos para poder abordar todos
los aspectos a tener en cuenta de una forma profunda. Simplemente os voy a
mencionar algunas transacciones interesantes para el caso de que
tengamos problemas de autorizaciones y queramos analizar donde
reside el problema.
Objetos de autorización verificados en una transacción.
Con la transacción SU24 podemos ver las autorizaciones asociadas a una
transacción y que se verificaran cuando entremos en ella.

En el ejemplo, en la transacción PA20 (consulta de datos maestros de

empleados), vemos que se verifican los objetos típicos para acceso a datos de
administración de personal (P_ORGIN, P_PCLX, P_PERNR, PLOG).

Ultima verificación de autorizaciones realizada en el usuario

actual.
Cuando intentamos acceder a una transacción o intentamos realizar algún
proceso sobre algún objeto sobre el que no estamos autorizados (aunque si
tengamos acceso a la transacción donde se realiza este), la revisión del objeto de
autorización que ha fallado la podemos realizar a traves de la transacción
SU53.

En la imagen podemos ver el resultado de la transacción, despues de intentar

acceder a una transacción de finanzas (la FB50 de contabilizaciones), para la que
no estamos autorizados.
En la parte superior aparece el objeto de autorización verificado que no
disponemos en nuestro perfil, y en la parte inferior los valores que si tenemos en
nuestro perfil para ese objeto de autorización, pero que no son suficientes para
poder acceder al objeto.

Es conveniente incluir la transacción SU53 en los perfiles de todos los usuarios

para agilizar las tareas de administración (se puede permitir que todos los
usuarios del sistema tengan acceso a las transacciones SU53 y SU56 con el
parametro de sistema auth/tcodes_not_checked). Solo aparece el último
objeto de autorización revisado que ha fallado.
Autorizaciones existentes en el perfil de usuario actual.
Aunque las autorizaciones de las que dispone un usuario pueden ser consultadas
desde la transacción SU01 (en la pestaña de Roles o Perfiles), desde aquí no
veremos el detalle de objetos de autorización asignados al usuario. Para ello,
tenemos la interesante transacción SU56 que nos muestra de forma detallada
los valores de autorizaciones asignadas a un usuario que residen en la memoria
intermedia del sistema.

Traza de autorizaciones.
Cuando tenemos verificaciones de autorizaciones complejas, el uso de la
transacción SU53 puede ser muy incomodo pues el sistema nos avisará de la
autorización que falta, la incluiremos en el perfil del usuario, volverá a fallar otro
objeto, etc. Así hasta que podamos identificar todo lo que nos falta e incluirlo en
los correspondientes roles o perfiles.

Para simplificar esta tarea de identificar las autorizaciones verificadas, podemos

utilizar la traza de contexto (transacción STKONTEXTTRACE) o bien la
clásica traza de sistema (transacción ST01). En ambas transacciones
podemos analizar otros aspectos ademas de las autorizaciones, como las traza
SQL, de memoria intermedia, RFC, etc.
En la traza de contexto indicaremos la transacción a analizar, marcaremos el flag
trace de autorización y realizaremos las tareas en el sistema como si fuesemos el
usuario para el que estamos preparando o revisando los perfiles de autorización.
Una vez completada la traza, la revisaremos desde la transacción ST01, desde
la opción evaluación. El programa nos mostrará todos los objetos de autorización
verificados, con sus correspondientes valores para cada uno de sus campos. Con
el resultado podremos preparar un perfil de autorización que incluya todo lo
necesario para el trabajo del usuario.
La traza también la podremos realizar desde la transacción ST01
directamente, llevando cuidado en marcar el flag Verif. Autorización,
e indicar los correspondientes filtros (por ejemplo, un usuario o una
transacción), ya que sino la traza se realizará sobre todos los usuarios
del sistema, y es un proceso pesado que puede afectar al rendimiento del
sistema.
NOTA: Transacciones para el mantenimiento de las autorizaciones.
PFCG Mantenimiento de Roles de Autorizacion (incluidos los menús de
Rol que se asocian al usuario). El mantenimiento se realizaba antiguamente con
la transacción SU02. El rol incluye los perfiles de autorización, que son una lista
de objetos de autorización con valores asignados en sus campos, que son los que
determinan que acciones podemos realizar en el sistema.
SU21 Mantenimiento de objetos de autorizacion (para visualizar los
estandar o crear nuestros propios objetos de autorizacion para las transacciones
de cliente). También se puede acceder desde la SU03.
SU20 Mantenimiento de campos de autorizacion (un objeto de
autorizacion se compone de varios campos).

PPOCW y PPOMW (y II). →

Truco 49. Autorizaciones desde el Modulo de
Organizacion. Roles de usuario con PFCG(I).
Publicado el 22 marzo, 2013 por Roberto Espinosa

7 Votes

En nuestro dos próximos trucos volvemos al modulo Basis para hablar de una
funcionalidad no demasiado conocida pero que puede ser muy útil si queremos
utilizar el modulo de Organización para construir la estructura de
puestos de trabajo de nuestra organización (desde el punto de vista de
RRHH o también desde el punto de vista de uso o funciones en Sap). Cada
unidad organizativa y/o puesto de trabajo tendrá asociadas las
diferentes autorizaciones en el sistema, de forma que cuando un
empleado/usuario sea asignado en los diferentes puestos/roles en el
arbol organizativo, automáticamente en su perfil de usuario Sap se
asignarán todas las autorizaciones vinculadas para que pueda
desempeñar las funciones previstas.
De esta forma se realiza una gestión de las autorizaciones mucho más ordenada.
Utilizando el arból organizativo de las transacciones del modulo de
organización (PPOMW/PPOSW), podemos ver de forma visual nuestra
estructura y quién esta asignado en cada lugar (asi como los roles de autorización
asignados). Como os digo, puede ser una funcionalidad muy interesante para
poner un poco de “orden” en el laberinto en el que se suele convertir la gestión de
autorizaciones en Sap conforme los proyectos van evolucionando.

Antes de entrar en profundidad en el módulo de organización y ver la forma de

configurarlo para utilizarlo desde la visión de la gestión de autorizaciones (no
desde el punto de vista de RRHH u organigramas, aunque podrian ser
compartidos), vamos a hacer un repaso a los aspectos mas importantes de
las autorizaciones en Sap. El control de autorizaciones es un concepto
transversal en Sap (afecta a todos los módulos) y es fundamental su buena
definición para evitar que los usuarios tengan acceso a funciones o tareas para las
que no deberían de estar autorizadas por sus funciones en la empresa (en especial
a determinados tipo de operaciones o informes).
Objeto de autorización.
Las autorizaciones en Sap se basan en dos unidades básicas de gestión: el campo
de autorización y el objeto de autorización.

Con los campos de autorización definimos tecnicamente la longitud de los

campos de autorización (dominio), así como los valores posibles que se van a
poder indicar en ellos cuando los utilicemos en las definición de nuestras
autorizaciones. Por ejemplo, para el control de acceso a transacciones se utiliza el
campo TCODE, que tiene el dominio tcode que permite utilizar valores en el
campo de longitud 20 (suficiente para cualquiera de las transacciones definidas

en Sap).
En otras autorizaciones debemos de indicar que tipo de actividad esta permitida
o no para el usuario. Para este caso, tendremos por ejemplo el campo de
autorizacion ACTVT que utiliza el dominio ACTIV_AUTH, asociado a una tabla
de valores que indicarán los diferentes actividades que podemos hacer, por
ejemplo, en el mantenimiento de datos maestros de articulos, clientes,
proveedores, etc (Añadir, Modificar, Borrar, Visualizar modificaciones, etc).

Los campos de autorización se definen en la transacción SU20. Sap

dispone de campos de autorización suficientes para crear nuestros propios
objetos de autorización (aunque es posible si fuera necesaria alguna
personalización especifica), crear nuestros propios campos de autorización.
El objeto de autorización es el nivel superior dentro de la gestión de
autorizaciones y el objeto básico con el que trabajaremos.
Básicamente, un objeto de autorizacion en una etiqueta (nombre
técnico) y un conjunto de campos de autorización asociados (de los
vistos anteriormente). Los objetos de autorización se mantienen en la
transacción SU21, estando clasificados de forma estandar por los diferentes
módulos y componentes de Sap. También podremos crear nuestros propios
objetos de autorización insertandolos en una clase Z (las clases se crean desde la
transacción SU03).

La asignación de autorizaciones se realiza utilizando los objetos de

autorización, asignando a cada campo una serie de valores, que
indican las operaciones permitidas dentro del ambito del objeto de
autorización. En el ejemplo de la imagen, podemos ver como el objeto de
autorización esta siendo utilizando en un rol de autorizaciones y como se le
asignan determinados valores que luego serán los que tenga el usuario al que este
rol sea asignado.

Dentro de la programación de las aplicaciones SAP, con la sentencia

“AUTHORITY-CHECK” verificaremos que el usuario dispone de la
autorización correspondiente y le dejaremos continuar o no con la acción a
realizar (en caso de informes podremos estar restringiendo también la
información a mostrar). En el estandar Sap lo hace de forma automática, aunque
este procedimiento lo podremos incluir también en nuestros desarrollos Z.
* Verificacion de autorizacion para crear pedidos de venta
AUTHORITY-CHECK OBJECT ‘V_VBAK_AAT’
ID ‘AUART’ FIELD VBAK-AUART
ID ‘ACTVT’ FIELD ’01’.
IF SY-SUBRC ne 0.
message e008(ZSISTEMAS) with ‘SIN AUTORIZACION PARA C
LASE DOC’.
ENDIF.
Como podeís ver, al final se acaba chequeando cada objeto de autorización
concreto y los valores de este. Si el usuario tiene asignada la autorización
requerida, puede llevar a cabo la acción. En caso contrario, se genera un mensaje
de error o simplemente no tiene acceso a la visualización de los objetos
involucrados.

Hay objetos de autorización para casi todo en Sap, desde el acceso a ejecutar
transacciones que veiamos antes (TCODE), objetos para modificar datos
maestros en los diferentes ambitos (general, centro, sociedad, organización de
ventas, sociedad CO, organización de compras, etc). También hay objetos de
autorización para las funciones básicas del sistema. De esta forma, casi cualquier
operación sobre el sistema, siempre se podrá permitir o no (con la ausencia de la
autorización).

Perfiles de autorización.
En versiones anteriores no existia el concepto de roles y se trabajaba con los
perfiles de autorización. Estos no eran mas que un conjunto de objetos de
autorización con sus correspondientes valores que se asignaban a los usuarios en
la transacción SU01/SU10. En versiones mas recientes se introdujo un concepto
mucho mas potente, el de los roles (aunque realmente por detras siempre siguen
estando los perfiles de autorización). Los roles se gestionan desde la transaccion
PFGC y tiene un generador automatico de perfiles de autorización que veremos a
continuación, que facilitan la utilizacion de los objetos de autorización.
Sino queremos trabajar con los roles, siempre podemos definir los perfiles
de autorización con la transacción SU02 (opción que no os
recomiendo en absoluto).

En los perfiles se indican los diferentes objetos de autorizacion que vamos a

asignar al usuario y con la autorización, que valores incluidos para los campos de
dichos objetos. Finalmente, estos se asignan a los usuarios mediante la
transacción SU01 en la pestaña Perfiles.

Roles de usuario simples.

Con la introducción del concepto de Rol Sap dio un respiro a los administradores
del sistema y les facilito mucho la vida a la hora de realizar la tediosa
configuración de las autorizaciones en Sap.

Los roles se definen con la transacción PFCG y son un nivel superior

dentro de la gestión de autorizaciones con funcionalidades añadidas como:
 Creación de menus de usuario asociados al rol: en el rol se define una
estructura de carpetas y las transacciones que se van a poner a disposicion del
 usuario.

 Ademas de incluir en el menú transacciones ya creadas, podemos crear las nuestras

propias directamente aquí, enlazando a Programas Abap, Querys, Informes de
 Report Writer o de Investigación, etc:

 Transferencia de menus al rol desde los menus de ambito Sap, de otros roles, desde
ficheros de texto.
 Traducción de los textos asociados o modificación de estos en el ámbito del menu
para indicarles textos mas significativos a los usuarios.
Una vez indicadas las transacciones, reports, etc que se asocian al rol, la
transacción PFCG automaticamente nos genera o actualiza el perfil de
autorizaciones asociado al rol con los objetos de autorización
necesarios. Según cada transacción o report indicado, el sistema nos genera una
propuesta de autorizaciones que tendremos que actualizar (habrá que concretar
los objetos referentes a las unidades organizativas de los diferentes módulos,
clases de actividad permitidas, clases de documentos, etc, etc).

Desde la pestaña de autorizaciones podemos acceder a la modificación del perfil

de autorizaciones. Aquí podremos ver todos los objetos de autorización
asignados, asi como los campos relacionados con cada uno de ellos y los valores
asignados. Os recomiendo activar siempre la visualización de los
nombre técnicos a través de la opción de menú Utilidades –> Activar
nombre técnicos.

Además de la propuesta de objetos de autorización que nos realiza Sap según las
transacciones indicadas, podremos incluir manualmente nuestros
propios objetos de autorización o bien copiarlos de otros modelos
(perfil de autorizaciones, modelo, etc). Es interesante conocer que Sap
dispone de un repertorio de Roles y Perfiles de autorización estandar que
posiblemente podamos utilizar como módelo para nuestras propias
autorizaciones.

IMPORTANTE: una vez concluida la definicion de objetos de

autorizacion y sus valores, siempre hay que generar el perfil de
autorización para que este sea activo y sus valores aplicables a los
usuarios.
El último paso sería la asignación del Rol al usuario, bien desde la misma
transacción PFCG en la pestaña Usuario o bien desde el mantenimiento de datos
de usuarios (transacciones SU01 / SU10 en la sección Roles).

Una vez asignado el Rol al usuario, las autorizaciones estarán disponibles para el
usuario en cuestión y si hemos incluido un arbol de transacciones, estas estaran
visibles en el Menu del usuario en Sap.

En el Rol no es obligatorio indicar un menú de transacciones, puede

incluir unicamente el perfil de autorización (es decir, incluir unicamente objetos
de autorización con sus correspondientes valores asignados).

Roles de usuario compuestos.

Los Roles de autorización compuestos también se mantienen desde la
transacción PFCG y consisten en roles que a su vez estan formados
por varios roles simples. Son un mecanismo para “agregar” varios roles y
facilitar su asignación a los usuarios.

Cuando vemos como esta el rol asignado en el maestro de usuarios, aparece el rol
compuesto (es el que podremos asignar o desasignar) y luego en color azul los
roles que forman ese rol compuesto (se hace la explosion al asignarlo en el
usuario).

Es un buen mecanismo para “agrupar” autorizaciones y simplificar la gestión de

la asignación a los usuarios.

Analisis de autorizaciones y traza.

Para concluir este repaso a nociones básicas de autorizaciones en Sap, os
recomiendo una lectura anterior del blog donde hablabamos de como analizar
problemas con autorizaciones y como realizar una traza en el sistema para
obtener que autorizaciones se verifican realmente: ver entrada
aquí. Resumiendo:
 Transacción SU24: objetos de autorización verificados en cada transacción.
 Transacción SU53: ultima verificación de autorizaciones erronea realizada en el
usuario actual.
 Transacción SU56: autorizaciones existentes en memoria para el usuario actual
(las asignadas en su perfil).
 Transacción ST01: traza de autorizaciones verificadas (también la transacción
STKONTEXTTRACE). Nos permite hacer una medición de todas las
 autorizaciones que son verificadas en un determinado usuario, transacción, etc.

Las autorizaciones SU53 y SU56 seria conveniente que estuvieran

asignadas a todos los usuarios por autorizaciones (o bien permitiendo siempre
su ejecución con el parametro de sistema auth/tcodes_not_checked).
Una vez introducidos los conceptos básicos de autorizaciones, en nuestra
próxima entrada veremos la forma de gestionar las autorizaciones
utilizando el módulo de Organización de Sap, y como asignando los
usuarios a las posiciones del Organigrama, podremos derivar la asignación
automatica de autorizaciones. Con una herramienta visual podremos de forma
jerarquica ver nuestra estructura de usuarios y las posiciones funcionales y roles
de autorización que tienen asignados.
Truco 51. Utilizando el sistema de informacion de
usuarios (SUIM).
Publicado el 26 marzo, 2013 por Roberto Espinosa
9 Votes

Continuando con el tema de las autorizaciones de las que hablamos en nuestros

dos anteriores posts del blog, hoy veremos el Sistema de Información de
Usuarios. Para la gestión de autorizaciones es fundamental conocer el Sistema
de Información de usuarios (se accede desde la transacción SUIM). Con
una gran variedad de herramientas, nos permite realizar análisis relacionados
con las autorizaciones asignadas a los usuarios en sus datos maestros, roles,
perfiles de autorización y

objetos.
La ejecución de los reports se realiza seleccionando el icono ejecutar.

Algunos de los informes más interesantes son:

 Usuario –> Según fecha de alta y modificación clave de acceso: resumen

de los usuarios del sistema, ultima entrada al sistema, estado de la clave de acceso,
bloqueo,
 etc.

 Usuario –> Con autorizaciones críticas: para detectar usuarios con

autorizaciones criticas (por ejemplo, usuarios que pueden modificar el maestro de
usuario, jobs, etc). Podremos crear nuestras combinaciones críticas de autorizaciones
para ejecutar el informe con esa variante y el informe nos devuelva los usuarios que
tienen en sus autorizaciones esa combinación de autorizaciones (en forma de
semáforos con colores según la criticidad que otorgamos a cada tipo de
autorización).

 Roles –> Roles por criterios de selección complejos: es la transacción

“principal” para obtener información de los roles. Podemos buscar los roles por
nombre, por usuario a los que están asignados, por transacciones incluidas en el
menú del Rol, por valores en los campos de los objetos de autorización, por perfiles
de autorización asignados al rol, etc. Nos va a permitir localizar por casi cualquier
criterio un
 rol.

Se suele utilizar para localizar roles que incluyen una determinada

autorización. Por ejemplo, si queremos localizar en que roles esta el objeto de
autorización F_KNA1_AEN, lo indicaremos en la parte sección “Selección según
valores de
autorización”.

Además, al indicar el objeto de autorización, a continuación nos aparecen los

campos de autorización que lleva asociados (podremos indicar también valores a
buscar en el contenido de estos campos o con “*” la autorización global a todos
los posibles valores). Al ejecutar el informe, se nos devolverá la lista de roles que
incluyen el objeto (con los valores en los campos que coincidan si los hubiéramos
incluido).

 Transacciones –> Transacciones ejecutables: nos permite analizar las

transacciones que puede ejecutar un usuario con sus autorizaciones actuales, las
transacciones que se pueden ejecutar con un rol determinado, etc. Es un mecanismo
rápido para ver que puede ejecutar un usuario o un role si entrar al mantenimiento
 de
roles.

 Comparaciones –> De usuarios: nos permite comparar los objetos de

autorización asignados a dos usuarios. Muy útil para cuando tenemos un usuario al
que le faltan autorizaciones y queremos, en comparación con otro que si tiene los
accesos, saber donde radican las
diferencias.

Entrando al detalle podemos ver incluso los valores de los campos de autorización
y desde que perfil de autorización se están heredando al usuario (como vemos en
la imagen a continuación). Tener en cuenta que en el detalle se muestra los
perfiles de autorización asociados al Rol (lo que se indica como
autorización).

 Comparaciones –> De roles: similar al anterior, en este caso nos permite

comparar las autorizaciones de dos roles, objeto por objeto. Es una forma sencilla de
comparar que objetos están en un rol y no en el otro. Igualmente, entrando al detalle
podemos ver los valores de los campos de
 autorización.

 Referencia de utilización –> Roles –> En usuarios: nos permite visualizar

los usuarios que están asignados a los
roles.

Pulsando el botón “ROLES” podemos ver de forma detallada toda la asignación

de roles al usuario, con información detallada si el rol es simple o compuesto, si
la asignación es directa (al usuario) o indirecta a través del módulo de
organización de Sap, fechas de validez,
etc.

Pulsando el botón “PERFILES” podemos ver cada uno de los perfiles asociados a
los usuarios que cumplen los criterios de selección del report.

En la proxima entrada del Blog, y para concluir el tema de autorizaciones,

veremos la forma de crear nuestras propias variantes para analisis de
autorizaciones críticas. Nos puede ser útil, en instalaciones muy grandes y con
muchos usuarios, para evitar que nunca se den determinadas combinaciones de
autorizaciones y para facilitar la labor en Auditorias de Seguridad (por mi
experiencia muchas auditorias contables ya incluyen incluso auditorias de
usuarios en Sap).

nuestras transacciones. →
Truco 3. Personalizacion de los menus de Sap.
Publicado el 11 abril, 2011 por Roberto Espinosa

7 Votes

Cuando accedemos al sistema Sap, tenemos disponibles dos menús con las
diferentes transacciones a las que podrá acceder el usuario:

 Menú Sap: es el menú estándar que incluye todas las opciones disponibles en el
sistema (aunque esto se puede cambiar, como veremos más adelante). Normalmente
accedemos al menú de ámbito S000 cuando estamos trabajando con el ERP.

 Menú de usuario: es el menú que se construye con los roles de autorizaciones

asignados al usuario. Los roles se definen mediante la transacción PFCG, y
pueden incluir arboles de transacciones, además de las correspondientes objetos de
autorización para acceder a ellas. Los roles se asignan a los usuarios en el
 mantenimiento de estos (que se realiza con la transacción SU01). A partir de todos
los roles que tiene asignados el usuario, el sistema nos construye el menú
correspondiente incluyendo todos los elementos definidos.

En la imagen siguiente podemos ver un ejemplo de definición de un Rol para

usuarios encargados de la administración de un sistema Sap. Vemos en la
definición del rol como se puede construir un menú personalizado por tareas (del
que dispondrán los usuarios en su menú de usuario). En la definición del rol
también se pueden incluir las autorizaciones apropiadas para que el usuario tenga
acceso a todas las transacciones y objetos organizativos necesarios según el tipo
de trabajo a realizar. El rol definido en el ejemplo es el que se visualiza en el menú
de usuario de la imagen anterior.

Además, tanto en un menú como en otro el usuario tendrá disponible siempre su

propio menú de favoritos, donde podrá crear accesos rápidos a las
transacciones de uso más frecuente (incluyendo una estructura de carpetas para
clasificar los elementos definidos por el usuario de una manera ordenada).
Teniendo en cuenta esto, algunas de las parametrizaciones que podemos realizar
en el sistema para configurar los menús son las siguientes:

 Desactivar el menú Sap: de esta forma, los usuarios solo verán las transacciones
asignadas en sus roles y los favoritos. Esto lo realizaremos a través de la transacción
SM31, incluyendo en la tabla SSM_CUST un registro con nombre
SAP_MENU_OFF y el valor YES. Esto aplica a todos los usuarios del sistema.
 Desactivar los menús de usuario: solo será visible el menú estándar y los
favoritos. Esto lo realizaremos a través de la transacción SM31, incluyendo en la
tabla SSM_CUST un registro con nombre ALL_USER_MENUS_OFF y el valor
YES. Esto aplica a todos los usuarios del sistema.
 Cambiar el menú Sap para todos los usuarios: a través de la transacción
SSM2 podemos cambiar el menú inicial del sistema. Por defecto, el menú es el S000.
Podemos indicar un menú diferente de entrada al sistema, o un menú Z que hayamos
 elaborado a medida.

 Cambiar el menú Sap para un usuario individual: desde el mantenimiento de

los datos de usuario (transacción SU01), podemos indicar un valor de menú inicial
para el usuario, en la pestaña de datos Valores Fijos.

 Configuración de menú permitidos por usuario: aparte de todas las

configuraciones descritas, podemos indicar a nivel de usuario, las autorizaciones de
acceso al menú Sap o al menú de usuario. Esto se configura a través de la transacción
SM31, en la tabla USERS_SSM. En la imagen podemos observar un ejemplo: el
usuario TM02011 solo tiene acceso al menú de usuario, el usuario RESPINOSA a
ambos y el usuario ACIGANDA solo al menú Sap. Esto nos permite personalizar la
configuración usuario por usuario, en lugar de la configuración general que vimos
 antes.

Ademas, en la tabla SSM_CUST podemos indicar otros valores para ajustar los
menús de usuario y evitar determinadas problematicas, como la redundancia de
entradas ( id CONDENSE_MENU), evitar las transacciones duplicadas (
id DELETE_DOUBLE_TCODES) o configurar la ordenación de la entradas
en el menú de usuario (id SORT_USER_MENU). En la nota del OSS 357693
se explica en detalle la forma de configurar estos valores.
Como vemos, tenemos disponibles opciones suficientes para configurar el
sistema según nuestras necesidades y las diferentes problemáticas de usuarios
con las que nos podamos encontrar (usuarios avanzados, usuarios que solo
accede a un número limitado de transacciones, etc).

Además de todo esto, Sap nos permite configurar el menú estándar, ampliándolo
para incluir nuestra propia estructura de carpetas o nuestras transacciones en los
puntos de menú estándar más apropiados para su accesibilidad por parte del
usuario final. La forma de configurar esto la veremos en la próxima entrada del
blog. Veremos que es una configuración general y que, al tratarse de una
ampliación, será respetada por Sap en los procesos de Upgrade cuando
realicemos un cambio de versión.