Truco 49. Autorizaciones desde el Modulo de Organizacion.

Roles de usuario
con PFCG(I).

En nuestro dos próximos trucos volvemos al módulo Basis para hablar de una
funcionalidad no demasiado conocida pero que puede ser muy útil si queremos
utilizar el módulo 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 árbol organizativo de las transacciones del módulo de organización
(PPOMW/PPOSW), podemos ver de forma visual nuestra estructura y quién está
asignado en cada lugar (así 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 podrían ser compartidos), vamos
a hacer un repaso a los aspectos más 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 técnicamente 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 está permitida o no

para el usuario. Para este caso, tendremos por ejemplo el campo de autorización
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 artículos, 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 específica),
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 autorización 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
estándar por los diferentes módulos y componentes de Sap. También podremos crear
nuestros propios objetos de autorización insertándolos 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 ámbito del objeto de autorización. En el ejemplo
de la imagen, podemos ver como el objeto de autorización está 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 estándar Sap lo hace de forma
automática, aunque este procedimiento lo podremos incluir también en nuestros
desarrollos Z.

* Verificación de autorización 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 CLASE DOC’.
ENDIF.

Como podéis 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 veíamos antes (TCODE), objetos para modificar datos maestros en
los diferentes ámbitos (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 existía el concepto de roles y se trabajaba con los perfiles

de autorización. Estos no eran más 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 más recientes se introdujo un concepto mucho más
potente, el de los roles (aunque realmente por detrás siempre siguen estando los
perfiles de autorización). Los roles se gestionan desde la transacción PFGC y tiene
un generador automático de perfiles de autorización que veremos a continuación, que
facilitan la utilización de los objetos de autorización.

Si no 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 autorización 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 simples de usuario.

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 menús de usuario asociados al rol: en el rol se define una

estructura de carpetas y las transacciones que se van a poner a disposición del
usuario.
 Además 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 menús al rol desde los menús de ámbito Sap, de otros roles,
desde ficheros de texto.
 Traducción de los textos asociados o modificación de estos en el ámbito del
menú para indicarles textos más significativos a los usuarios.

Una vez indicadas las transacciones, reports, etc. que se asocian al rol, la
transacción PFCG automáticamente 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, así
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 estándar que posiblemente podamos
utilizar como modelo para nuestras propias autorizaciones.

IMPORTANTE: una vez concluida la definición de objetos de autorización 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 árbol de transacciones, estas estarán
visibles en el Menú del usuario en Sap.

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

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

Roles compuestos de usuario.

Los Roles de autorización compuestos también se mantienen desde la transacción

PFCG y consisten en roles que a su vez están formados por varios roles simples.
Son un mecanismo para “agregar” varios roles y facilitar su asignación a los usuarios.
Cuando vemos como está 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 explosión al asignarlo en el usuario).

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

asignación a los usuarios.
Análisis de autorizaciones y traza.

Para concluir este repaso a nociones básicas de autorizaciones en Sap, os

recomiendo una lectura anterior del blog donde hablábamos 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 errónea 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 sería conveniente que estuvieran asignadas a

todos los usuarios por autorizaciones (o bien permitiendo siempre su ejecución con
el parámetro 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 automática de autorizaciones. Con una
herramienta visual podremos de forma jerárquica ver nuestra estructura de usuarios y
las posiciones funcionales y roles de autorización que tienen asignados.

Una vez creados todos los roles de autorización necesarios para la gestión de los
procesos de usuario en Sap (puede ser uno de los temas que más tiempo nos pueda
llevar por su complejidad), procederemos a crear la estructura del organigrama
dentro del módulo de organización. Básicamente, el organigrama es una estructura
jerárquica con diferentes tipos de componentes vinculados entre sí en forma de árbol.
Los elementos que vamos a usar para poblar este árbol con nuestra estructura
organizativa y de autorizaciones son los siguientes (los que a nosotros nos afectan
para la gestión de autorizaciones):

 Unidad Organizativa: corresponde con la estructura de departamentos dentro

de la empresa u organización. En nuestro ejemplo, las hemos marcado en Rojo.
Podrían corresponder a las divisiones de una empresa, direcciones,
departamentos, áreas funcionales, etc. Las unidades organizativas utilizan la
sigla O (las siglas son el código que identifica a cada uno de los tipos de
objeto que vamos a poder utilizar en la definición de la estructura).
 Posición: corresponde a los diferentes puestos de trabajo dentro de nuestra
organización (puede corresponder a posiciones funcionales, por tipo de trabajo
o tareas). En nuestro ejemplo, las hemos marcado en Azul. Las posiciones
utilizan la sigla S.
 Empleado: podríamos asignar empleados del módulo de RRHH de Sap a las
posiciones y después desde el infotipo 0105 asociarle un usuario al que
derivará las autorizaciones. En nuestro ejemplo no lo vamos a utilizar, pero que
 sepáis que también existe esa posibilidad. Los empleados utilizan la sigla P
(Persona).
 Usuario: códigos de usuario de los creados en el sistema (transacción SU01).
En nuestro ejemplo, en color Naranja. Se usa la sigla US.
 Rol: códigos de los roles de autorización que hemos creado en el sistema
(transacción PFCG). En nuestro ejemplo, en color Verde. Se usa la sigla AG.

El paso final, una vez creado el organigrama y asignados los diferentes elementos
necesarios en él es la explosión de la autorizaciones a partir del árbol y las
relaciones de vinculación establecidas entre los diferentes objetos que lo
forman. Esta tarea se realiza a través de la transacción PFUD (report
RHAUTUPD_NEW). Este proceso se puede lanzar manualmente o bien automatizar a
través de un job que hará el trabajo por nosotros.

A continuación vamos a ver de forma detallada el proceso de creación del

organigrama, la explosión de las autorizaciones desde el árbol al maestro de usuarios
y finalmente la parametrización necesaria para poder utilizar esta funcionalidad.

Creación de nuestro organigrama.

Con la transacción PPOCW crearemos la unidad organizativa raíz y las diferentes

unidades organizativas y posiciones que forman nuestro organigrama. Este
organigrama podrá estar construido desde el punto de vista de la Recursos Humanos
(si vamos a utilizar la asignación de empleados) o desde el punto de vista de uso
funcional de Sap (si vamos a utilizar la asignación de usuarios). Puede darse el caso
de que ambas “vistas” coincidan y utilicemos un único árbol.

La primera vez que entramos en la transacción, se crea la unidad organizativa raíz,

que es la base desde la que colgarán el resto de elementos.

A continuación, podremos ir creando el resto de elementos que cuelgan de la raíz

(igualmente desde la transacción PPOCW o desde la PPOMW). Para crear nuevas
unidades organizativas o posiciones, seleccionaremos el lugar del que queremos que
dependan y seleccionaremos el botón Crear. El sistema nos preguntará el tipo de
elemento a crear: Unidad organizativa o Posición. Le indicaremos una sigla
(nombre corto), una descripción, pudiendo indicar también otros aspectos como un
Texto largo, información de imputación del módulo de Controlling o Tareas asignadas
a la posición (el módulo de organización también nos permite la definición de tareas y
su vinculación a los objetos, pero no vamos a entrar en esta funcionalidad).

Siguiendo el mismo procedimiento completaremos todo el organigrama con la

información de los diferentes departamentos, áreas, direcciones, así como los
diferentes puestos de trabajo que los conforman. Una vez completada la estructura,
procederemos a la asignación de los roles de autorización en las diferentes
unidades organizativas y posiciones. Es importante saber que podemos asignar
los roles en cualquier unidad organizativa o posición, y que las autorizaciones
se heredan hacia abajo. Si, como en nuestro ejemplo, indicamos unas autorizaciones
en el nivel del Departamento de Cuentas a Cobrar y de este departamento cuelga una
posición con otra asignación de roles de autorización, el usuario que ocupe esa
posición recibirá tanto los roles de la unidad organizativa como de la posición. Esto
nos permite definir autorizaciones genéricas para el departamento y otras especificas
por posición (más especializadas o restringidas). El mismo para autorizaciones
generales que pueden indicarse en la posición raíz para que sean heredadas por todos
los usuarios (tipo autorizaciones generales de uso de funciones básicas).

Para asignar los roles, seleccionaremos el botón Asignar y a continuación

seleccionaremos el tipo de objeto Rol (sigla AG). Sap nos permitirá buscar entre
los diferentes Roles simples o compuestos que tengamos definidos en nuestro
sistema y asignarlos a la Unidad organizativa o posición en la que nos encontremos
posicionados (permite selección múltiple al hacer la asignación, lo que es una gran
ventaja).
El último paso sería, siguiendo el mismo procedimiento de asignación, llenar las
diferentes posiciones con los usuarios que van a desarrollar cada una de las
funciones descritas. Para ello, siguiendo el mismo procedimiento, pulsaremos el
botón Asignar, seleccionaremos el tipo de objeto US (Usuario en este caso) e
indicaremos los códigos de usuario Sap incluidos en la posición (varios usuarios podrá
ocupar una misma posición, y Sap permite la selección múltiple en la asignación).

NOTA IMPORTANTE: cuando estemos realizando tanto la creación de las unidades

organizativas, posiciones, así como la asignación de roles y usuarios, es importante
haber indicado una fecha de inicio para las vinculaciones (todos los objetos se
relacionan entre sí con una fecha de validez inicio/fin, con el objetivo de permitir
cambios a futuro en la estructura, que será variable). Para ello, pulsaremos tal y como
vemos en la imagen el botón “Fecha y periodo previsión” e indicaremos la fecha inicial
para la validez de las vinculaciones que vayamos realizando en la estructura.
De una forma visual hemos construido la estructura de nuestra empresa, llenándola
desde un punto de vista de las autorizaciones. De forma gráfica tenemos toda la
estructura del sistema dibujada, y podemos saber dónde “cuelga” cada usuario y que
autorizaciones tiene concedidas, de una forma más legible que viendo su ficha de
usuario con la SU01. Además, tenemos disponibles funciones de búsqueda potentes
que nos permiten localizar los diferentes elementos dentro del árbol.

Explosión del organigrama hacia los datos maestros de usuario.

La explosión del organigrama (roles) hacia el maestro de usuarios se realiza a través

de la transacción PFUD (que utiliza el report estándar RHAUTUPD_NEW). La
explosión la realizaremos en dos pasos:

1) Generaremos los roles en el maestro de usuario derivándolos de la

asignación organizativa: para ello, en la transacción PFUD seleccionaremos
la opción “Comparación Gestión Organización HR”.
El programa lee la estructura del organigrama, busca los roles que hayamos indicado
en los criterios de selección (Z* corresponderían a nuestra definición de Roles) dentro
del árbol, los relaciona con los usuarios asignados a las unidades organizativas o
posiciones, y los asigna dentro del maestro de usuarios. Para hacer este proceso se
utilizan las vías de evaluación, que han de estar correctamente configuradas como
veremos más adelante.

Con este primera ejecución de la transacción hemos pasado de tener el usuario sin
roles en sus datos maestros a estar asignados los roles correspondientes, aunque, es
importante, sin activar (tal y como observamos en la imagen).

2) Para completar la activación de los roles asignados, volveremos a ejecutar la

transacción PFUD, pero seleccionando en esta ocasión las opciones
“Comparación de perfil” y “Comparación de roles compuestos”.
Esta segunda ejecución recorre los roles (ya sin ser relevantes los datos del
organigrama), busca los usuarios que lo tienen asignado y activa los roles en los datos
maestros del usuario. Tras esta segunda ejecución, los roles ya aparecen activos en
el usuario, están disponibles para que el usuario pueda trabajar en el sistema con las
funciones descritas.

La ejecución de estos dos procesos se puede planificar en forma de job (2/3

veces al día) para que el ajuste se haga de forma automática. De esta forma, la
asignación de los usuarios en el organigrama estará activa pasadas unas pocas horas
de forma automática (aunque siempre tendremos la opción de forzar la actualización
con una ejecución a demanda de la transacción PFUD). La misma transacción PFUD
permite la generación de los Jobs.

Parametrización necesaria para activar la funcionalidad.

 Definir una Variante de Plan Activa: en la transacción OOPV crearemos la

variante y la activaremos. En la transacción OOAP la asignaremos al grupo
PLOGI.

 Tabla PRGN_CUST: El flag de Customizing HR_ORG_ACTIVE se habrá de

activar con el valor YES: este valor activa la gestión de módulo de
organización para la gestión de roles de autorización (se realiza con la
transacción SM30 o SM31).

 Vía de evaluación US_ACTGR: ajuste de la vías de evaluación US_ACTGR

(table T77AW) a través de la transacción OOAW. La vía de evaluación es la
parametrización que permite la lectura de la asignación de los roles en el árbol
organizativo y a partir de ahí derivar los usuarios a los que asignar los roles en
su maestro de usuarios. Básicamente, determinamos la forma en que el
programa de evaluación, partiendo de las posiciones o unidades organizativas
que tienen asignados los roles, recorre hacia arriba el árbol hasta encontrar los
códigos de los usuarios a los que asignar los roles.
Nota importante: para que funcione la herencia de roles de unas unidades
organizativas a otras que dependan de ellas ha de estar creada la línea 101 de
la imagen (no viene en la configuración estándar). Sin ella no funciona la herencia
(solo la herencia de primer nivel, de unidad organizativa superior a posición, y de ahí
al usuario).