Truco 53. Debug en ventanas popup.

Como ya sabeís, el Debugging es una herramienta que ofrece Sap para navegar por el código Abap en tiempo de ejecución, pudiendo hacer una ejecución paso a paso por la programación. Esta funcionalidad nos permite analizar programas estandar o desarrollos propios, analizar errores, buscar exits, encontrar bugs, etc.

El debug lo podemos activar en cualquier momento en la ejecución de un report o transacción indicando el valor /h en el cuadro de comando que tenemos en la parte superior izquierda de la ventana del Sapgui.

Se requieren autorizaciones especificas para poder realizar un Debug, en concreto, el objeto de autorización S_DEVELOP (ha de incluir en el campo OBJTYPE del valor DEBUG o “*”, y las actividades 01 y 02).

Al lanzar el comando /h, se inicia una ventana donde podremos navegar por el código que se esta ejecutando en la transacción en la que nos encontremos (información de las ultimas funcionalidades del debug aquí).

La opción de activar nos vale para las ventanas normales (en las que tenemos disponibles el cuadro de comando). Pero que ocurre si estamos en una ventana modal, donde no tenemos la opción de indicar comandos de control. En esos casos, hasta ahora habia desistido de hacer Debugging. Pero gracias a los amigos de Orekait, he descubierto que tenemos un par de alternativas para esos casos.

La solución es muy sencilla. Basta con crear un fichero de texto que contenga la siguiente secuencia de sentencias:

[FUNCTION]    Command=/H    Title=Debug    Type=SystemCommand

Guardamos el fichero en un lugar accesible. La próxima vez que necesitemos hacer un debug en una ventana modal (por ejemplo, la transacción XD02 de mantenimiento de clientes), cuando tengamos la ventana abierta:

Bastará con irnos al explorador de Windows, seleccionar el fichero de texto y arrastrarlo hasta la ventana de Sap. Al dejarlo caer sobre ella, la secuencia de comandos que se encuentran dentro del fichero serán leidos por Sap y nos aparecerá nuestra flamante ventana de Debug.

Truco 52. Dos periodos contables abiertos en FI (y 1 limitado por autorizaciones)

Como ya sabeís, los periodos contables abiertos en un sistema Sap se controlan desde la transacción OB52. Basícamente, los periodos se gestionan a traves de una variante de periodo, que es para la que indicamos los periodos contables que están abiertos. La variante de periodo se asigna a las sociedades de Finanzas, de forma que cuando modificamos los periodos abiertos de una variante estamos afectando a todas las sociedades que tiene asignada esa variante de periodos (y por tanto, limitando las fechas en las que vamos a poder contabilizar para dichas sociedades).

Os recomiendo la lectura de la entrada de Oscar en su Blog de Sap donde habla de los diferentes periodos que se pueden gestionar en Sap y toda la parametrización relacionada (tanto a nivel de FI como de MM).

En nuestro truco de hoy vamos a ver una funcionalidad de la gestión de periodos de Finanzas que nos permite lo siguiente:

• Disponer de dos periodos contables abiertos.
• Limitar la contabilización en uno de los periodos por autorizaciones.

De esta forma, en un proceso de cierre contable, limitamos en un periodo anterior la contabilización a la mayoria de usuarios por autorizaciones, permitiendo solo la contabilización en ese periodo “que estamos cerrando o ajustando”  a los usuarios autorizados. Por otro lado, el resto de usuarios seguirán contabilizando en el periodo “actual”, que no estará limitado.

Los pasos para conseguir este comportamiento del sistema son muy sencillos.

• Periodo desde/hasta limitado: corresponde al remarcado en rojo en la imagen siguiente. Este periodo será el que estará restringido por autorizaciones.
• Periodo desde/hasta abierto: corresponde al remarcado en azul en la imagen siguiente. Este periodo será el que estará abierto a todos los usuarios.
• Grupo de autorizaciones: aquí indicaremos un valor. Este valor deberá de estar incluido en las autorizaciones del usuario, con el objeto F_BKPF_BUP, para permitirle contabilizar en el periodo limitado. Si en grupo de autorizaciones no indicamos ningún valor, ambos periodos estará abiertos a todo el mundo. En ese caso, será la forma de ofrecer dos periodos distintos abiertos sin ninguna restricción de autorizaciones.

El ultimo paso consistiría en crear un rol de autorizaciones con el objeto F_BKPF_BUP, asignadole el valor que hubieramos puesto en el campo GrA en la variante de periodo oportuna. Es importante también revisar las autorizaciones existente para evitar que los usuarios restringidos no tengan este objeto de autorización con el valor “*”, pues esta autorización les permitiría contabilizar en cualquier de los dos periodos.

Os dejo el enlace a un manual sobre esta funcionalidad, que incluye ejemplos de utilización en un caso real.

Información adicional: también se puede hacer un control de los periodos abiertos a nivel del modulo de Controlling (CO). Para ello, desde la transacción OKP1 – Modificar bloqueo de periodos, podemos, a nivel de sociedad CO, indicar en un ejercicio que periodos bloqueamos y para que actividades.

Puede ser una forma de útil de bloquear también la realización de operaciones a nivel de CO que nos afecten a periodos cerrados para los que ya se ha presentado información o se han concluido todos los procesos de cierre asociados.

Truco 51. Utilizando el sistema de informacion de usuarios (SUIM).

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

Truco 50. Autorizaciones desde el Modulo de Organizacion. PPOCW y PPOMW (y II).

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 mas 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 si 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. Podrian corresponder a las divisiones de una empresa, direcciones, departamentos, areas funcionales, etc. Las unidades organizativas utilizan la sigla O (las siglas son el código que identifica a cada uno de los tipo 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: podriamos asignar empleados del módulo de RRHH de Sap a las posiciones y despues desde el infotipo 0105 asociarle un usuario al que derivará las autorizaciones. En nuestro ejemplo no lo vamos a utilizar, pero que sepais que también existe esa posibilidad. Los empleados utilizan la sigla P (Persona).
• Usuario: codigos 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 el es la explosión de la autorizaciónes a partir del arbol 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 arbol al maestro de usuarios y finalmente la parametrización necesaria para poder utilizar esta funcionalidad.

Creacion de nuestro organigrama.

Con la transacción PPOCW crearemos la unidad organizativa raiz y las diferentes unidades organizativas y posiciones que forman nuestro organigrama. Este organigrama podra 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 utilizemos un único arbol.

La primera vez que entramos en la transacción, se crea la unidad organizativa raiz, 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 raiz (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 modulo de Controlling o Tareas asignadas a la posicion (el módulo de organización también nos permite la definicion de tareas y su vinculacion 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, areas, 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 posicion con otra asignación de roles de autorizacion, el usuario que ocupe esa posición recibira 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 posicion (mas especializadas o restringidas). Los mismo para autorizaciones generales que pueden indicarse en la posición raiz para que sean heredadas por todos los usuarios (tipo autorizaciones generales de uso de funciones básicas).

Para asignar los roles, seleccionaremos el boton 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 multiple al hacer la asignación, lo que es una gran ventaja).

El ultimo 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 multiple en la asignación).

NOTA IMPORTANTE: cuando estemos realizando tanto la creacion de las unidades organizativas, posiciones, asi 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 si con una fecha de validez inicio/fin, con el objetivo de permitir cambios a futuro en la estructura, que sera 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, llenandola desde un punto de vista de las autorizaciones. De forma gráfica tenemos toda la estructura del sistema dibujada, y podemos saber donde “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 estandar RHAUTUPD_NEW). La explosión la realizaremos en dos pasos:

1) Generaremos los roles en el maestro de usuario derivandolos de la asignación organizativa: para ello, en la transacción PFUD seleccionaremos la opción “Comparacion Gestion Organizacion HR”.

El programa lee la estructura del organigrama, busca los roles que hayamos indicado en los criterios de seleccion (Z* corresponderian a nuestra definición de Roles) dentro del arbol, 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 vias de evaluación, que han de estar correctamente configuradas como veremos más adelante.

Con este primera ejecucion 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 “Comparacion 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, estan 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 automatica. 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 transaccion 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 transaccion OOPV crearemos la variante y la activaremos. En la transaccion OOAP la asignaremos al grupo PLOGI.
• Tabla PRGN_CUST: El flag de Customizing  HR_ORG_ACTIVE se habra de activar con el valor YES: este valor activa la gestion de modulo de organización para la gestion de roles de autorización (se realiza con la transacción SM30 o SM31).
• Via de evaluación US_ACTGR: ajuste de la vias de evaluacion US_ACTGR (table T77AW) a través de la transacción OOAW. La via de evaluación es la parametrizacion que permite la lectura de la asignación de los roles en el arbol organizativo y a partir de ahí derivar los usuarios a los que asignar los roles en su maestro de usuarios. Basicamente, 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 linea 101 de la imagen (no viene en la configuración estandar). Sin ella no funciona la herencia (solo la herencia de primer nivel, de unidad organizativa superior a posicion, y de ahí al usuario).

Links y documentación adicional.

• Ayuda de Sap sobre la funcionalidad: http://help.sap.com/saphelp_nw70ehp2/helpdata/en/92/e7623c28695c63e10000000a11405a/content.htm.
• Manual de usuario: Indirect Role Assignment Using HR-ORG[1]. En este documento de forma detallada la funcionalidad, conceptos adicionales, asi como la distribución entre diferentes sistemas.
• Entrada del SCN donde se explica la configuración necesaria para permitir herencia de roles de unidad organizativa hacia abajo (de unidad organizativa superior a inferior) en las vias de evaluación: https://scn.sap.com/thread/1899175.

Truco 49. Autorizaciones desde el Modulo de Organizacion. Roles de usuario con PFCG(I).

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 CLASE 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 48. Liberación en pedidos de ventas.

Es una consulta bastante habitual: ¿existe una parametrización para definir estrategias de liberación en pedidos de ventas, de forma que las ventas sean autorizadas según determinados criterios, al igual que en los documentos de compras?. La respuesta es NO, aunque disponemos de alternativas para poder configurar algo similar a las estrategias de liberación de compras. Estas son:

• Utilizar el “Bloqueo de entrega” o el “Bloqueo de factura” para impedir que los pedidos se puedan servir o facturar. Este método no es muy efectivo, ya que cualquier usuario que tenga acceso a la transacción VA02 va a poder quitar el bloqueo. Podriamos quitar la autorización a la transacción, pero no es practico pues los vendedores o administrativos seguro que tendran que poder modificar otras cosas de los pedidos.
• Utilización de exits: podriamos establecer una personalización del sistema utilizando los campos de bloqueo en combinación con programación en alguna de las exits disponibles (por ejemplo, include MV45AFZZ, exit USEREXIT_FIELD_MODIFICATION o USEREXIT_SAVE_DOCUMENT), con el proposito de impedir que usuarios no autorizados quiten los bloqueos (y “liberen” los pedidos). Es una solución compleja que requiere programación, aunque podría ser valida. En la programación se podrian incluso incluir tablas Z donde definir valores de clasificación para la liberacion (por importes, por clases de documento, por organización de venta).
• Utilizar el control de crédito: se definen unos limites de credito para los clientes, que produciran que los pedidos se bloqueen para la entrega. Habrá que liberarlos con las transaccion VKM3.
• Utilizar los esquemas de status: con los esquemas de status podemos definir un flujo de estados al pedido (a nivel de cabecera o de posición). En cada uno de estos status se puede permitir o impedir operaciones sobre el documento de venta (por ejemplo, no permitir realizar la entrega de mercancia). Igualmente, mediante autorizaciones se puede asignar a los usuarios que status pueden utilizar, de forma que solo los usuarios autorizados podrán establecer el status final de aprobación que permite continuar con el proceso de la orden de venta. Puede ser la solución a nuestro problema, y solo utilizando customizing.

En nuestro caso, vamos a utilizar esta última opción para establecer nuestra estrategia de liberación en pedidos de venta. Veamos un ejemplo completo definiendo dos pasos de liberación: uno del Supervisor de Zona y otro del Director Regional.

La parametrizacion detallada de la funcionalidad es la siguiente:

Creación del esquema de status.

 A través de la ruta de customizing Comercial –> Ventas –> Documentos de ventas –> Definir y asignar esquema de status podemos acceder a la parametrización (transacción BS01). Los esquemas de status son una funcionalidad utilizada en muchos módulos (CO para las ordenes, PS para los proyectos/peps, PM para las ordenes de mantenimiento, etc).

El esquema de status consiste en una etiqueta con una descripción (Z0000001 - Status Cabecera Pedido Ventas en nuestro caso).

A continuación, en el detalle, se describen cada uno de los estados posibles dentro del esquema, con unos valores de configuración que vamos a explicar a continuación (son los que determinan el comportamiento de estos y el posible flujo para pasar de uno a otro):

• NºClasificación: un numerador que nos identifica a cada uno de los status dentro del esquema (en nuestro ejemplo 10, 20, 30).
• Status: código propio que identifica a cada uno de los status (en nuestro ejemplo Z001, Z002, Z003).
• Texto Breve: descripcion corta del status.
• Texto Explicativo: es un flag que nos indica si se ha introducido un texto largo donde explicamos de forma detallada las características del estado.
• Stat.Ini: indica que el status es inicial. Es decir, cuando creemos un documento que tenga el esquema de status asociado, este será el estado que se le asignará por defecto. Solo puede haber uno.
• Nºclasif.inferior: status inferior minimo desde el que se puede acceder desde el estado actual (vuelta a status anterior).
• Nºclasif.superior: status superior máximo desde el que se puede acceder desde el estado actual (cambio a status superior).
• Clave autorización: podemos indicar aquí una etiqueta. Esta obligará a que el usuario que quiera poner un documento en este status tendrá que tener en su perfil de autorizaciones el objeto B_USERSTAT con el valor indicado aquí. Sino, no podrá liberar el pedido de venta.

En nuestro ejemplo, hemos definido 3 niveles:

• Z001 – Bloqueo Supervisor Zona: status inicial que quedará asignado al pedido al crearlo. Permite pasar al status superior Z002.
• Z002 – Bloqueo Director Regional: permite volver al status Z001 o pasar al status superior Z003. Tiene el objeto de autorización Z001 asignado, de forma que solo usuarios con ese valor asignado en el objeto de autorizaciones B_USERSTAT van a poder cambiarlo.
• Z003 – Liberado – Autorizado: permite volver al status Z002. Tiene el objeto de autorización Z002 asignado, de forma que solo usuarios con ese valor asignado en el objeto de autorizaciones B_USERSTAT van a poder cambiarlo.

En nuestro ejemplo, por la configuración para llegar al status Z003 siempre se tendrá que haber pasado por el Z001 y Z002, por lo que realmente estamos obligando a dos niveles de autorización.

Definición de operaciones permitidas por status.

 En este paso de parametrización definiremos para cada uno de los status que operaciones estan permitidas o restringidas sobre los documentos de ventas. En primer lugar, cuando estemos definiendo los status del esquema, pulsaremos el botón “Tipos de objetos”.

A continuación marcaremos los objetos relevantes para el control de operaciones en el status. En nuestro caso “Cabecera pedido de cliente” y “Posicion de pedido de cliente”. Una vez realizado este paso, ya podremos configurar las operaciones permitidas por cada status dentro del esquema. Haciendo doble click en cada status accedemos al “Control de Operaciones”. En nuestro ejemplo, para los status Z001 y Z002 impedimos cualquier suministro de mercancía o facturación del pedido.

Para el status Z003, no hay ningún tipo de restricción (todas las operaciones están permitidas). Se pueden controlar otro tipo de operaciones sobre los documentos de venta que no vamos a ver aquí.

Las operaciones no indicas en el control de operaciones no estan sometidas a ninguna restriccion en los status de usuario.

Asignación del esquema a nivel de cabecera de documento de ventas o posición.

Para que el esquema sea efectivo, hay que asignarlo a una clase de documento de ventas (transacción VOV8) o bien a un tipo de posición (transacción VOV7). El primer caso indica que la liberación será a nivel de cabecera y el segundo a nivel de posición.

En nuestro ejemplo, hemos seleccionado una liberación por documento. Tendremos que asignar el esquema de status a todas aquellas clases de pedido de venta para los que queramos establecer el control de liberación.

En nuestro ejemplo, hemos elegido la clase de documento TA Pedido estándar. También podriamos haber utilizado esta funcionalidad para autorizaciones especificas de documentos especiales, como abonos/notas de cargo, para obligar a que siempre tengan que ser autorizados de una forma especifica.

Asignación de autorizaciones.

A continuación, tendremos que crear los roles de autorizacion (transacción PFCG) conteniendo el objeto B_USERSTAT para asignarlos a los usuarios autorizados para la liberacion de cada uno de los status.

La Clave de Autorización asignada coincide con el valor que indicamos en la definicion de los status en el campo con el mismo nombre.

Proceso de liberación.

Una vez creado el pedido de venta, por la parametrización automaticamente se le asignara el esquema de status definido. Para ver la información de status, podemos acceder desde la transacción VA02, a los datos de cabecera, pestaña “Status”.

Aquí podemos ver que al pedido de venta al crearlo se le ha asignado automaticamente el status de usuario Z001. Si intentamos crear la entrega para el pedido ( y así hacer la salida de mercancia al cliente) con la transacción VL01N, el sistema produce el siguiente mensaje de error:

Necesitaremos antes “liberar” el pedido cambiando el status al correcto. Para ello, desde la pestaña de status pulsaremos el botón “Status Objeto” y pasaremos al detalle de la información de status, lugar desde el cual realizaremos el cambio (seleccionando el status deseado).

El cambio de status no estará permitido al usuario sino tiene las autorizaciones oportunas. Igualmente, desde este lugar podemos consultar que operaciones estan bloquedas en cada uno de los status. Por ejemplo, en el status Z002 – BLoqueo Directo Regional, aparecen bloqueada la creacion de entrega, suminitro y facturacion.

Si vieramos el status Z003 podriamos ver que ya no hay ningun bloqueo, tal y como hemos parametrizado en el esquema de status creado. Una vez llegado a este estado, el pedido esta “autorizado” y se pueden continuar en el los procesos habituales de preparación del suministro, creación de entrega y facturación.

Para poder localizar los pedidos según su status, tenemos disponible una transacción estandar, la V.26 Documentos ventas según status objeto (solo nos permite indicar el status que queremos buscar y nos localiza los documentos que cumplen las condiciones). Sería la herramienta para trabajar en los procesos de liberacion (no permite liberar de forma masiva).

Una vez indicados los criterios de seleccion, el report nos devuelve la lista de pedidos en el status indicado y nos permite el acceso directo a cada documento para la modificación del status.

Preparación de la liberación masiva de pedidos con un pequeño desarrollo.

Para poner la guinda en el proceso de liberación de ventas podriamos construir una herramienta para que los usuarios pudieran “liberar” de forma masiva los pedidos, ya que puede no ser muy operativo el tener que entrar pedido por pedido, acceder a la sección de status y desde ahí cambiarlos. Como no existe una herramienta estandar para este cometido (por lo menos yo no la conozco),  podriamos hacer un pequeño desarrollo que recuperara la información de los pedidos pendientes, nos mostrase el estado actual y nos permitiese cambiar de estado los registros seleccionados.

Para este desarrollo, podriamos utilizar las tablas:

• VBAK: cabecera pedido de venta. En el campo OBJNR tengo el número de objeto que me va a permitir leer los status de cabecera.
• VBAP: posiciones pedido de venta.
• JEST: status por objeto.
• JCDS: historial de modificaciones en el status.

 También nos podrían ser utiles los modulos de función, especificos para el tratamiento de los status:

• STATUS_READ: nos devuelve el status de un documento de venta o de una determinada posicion.

• STATUS_CHANGE_EXTERN: funcion para cambiar el status de un objeto (tener en cuenta que se le pasa el codigo de status interno que crea Sap cuando creamos los diferentes status en un esquema de status (ver tabla TJ30T para sacar la equivalencia)).

Links de interes y bibliografia utilizada:

http://scn.sap.com/thread/93363

https://scn.sap.com/thread/1475801

Gracias al blog http://www.learnsaptips.com/, Anupa Wijesinghe ha eleborado este manual con los pasos a seguir para la configuración de la parametrización:

 

View this document on Scribd

 

Aprovecho para recomendaros la lectura del blog, con gran cantidad de material y tutoriales elaborados por Anupa de gran calidad.

 

 

Truco 47. Proteccion de modificaciones de campos en maestro de clientes y proveedores.

En algunos de mis proyectos, algún key-user de finanzas me ha consultado si existia la posibilidad de restringir la modificación de determinados campos “CRITICOS” del maestro de clientes o proveedores, con el objeto de evitar errores.

Seria asi como establecer dos niveles de autorización a la hora de modificar los datos maestros de deudores y acreedores. En el primer nivel estan todos los usuarios que tienen acceso a modificar las fichas de datos maestros, excepto a algunos campos (que nosotros seleccionaremos), cuya modificación estará restringida y solo podrá ser realizada por los usuarios que tengan unos determinados objetos de autorización en sus perfiles. En este primer nivel determinados campos apareceran en gris y podran ser visualizados por el usuario, pero no modificados. Esto puede tener sentido si queremos que algunos usuarios puedan modificar datos de dirección o contacto, una cuenta bancaria, direcciones de correo, pero no queremos que toquen campos delicados como la forma de pago, cuenta asociada, via de pago, datos fiscales, grupo de tesoreria u otros datos de clasificación.

En el segundo nivel, los usuarios tendrán acceso a la modificación de datos maestros de una forma completa, sin limitaciones. De ellos dependerá la correcta modificación de estos campos críticos.

La parametrización se realiza desde las rutas de customizing:

• Clientes: Gestion financiera –> Contabilidad de deudores y acreedores –> Cuentas de deudor –> Datos maestros –> Preparar modificacion de datos maestros de deudores.
• Proveedores: Gestion financiera –> Contabilidad de deudores y acreedores –> Cuentas de acreedor –> Datos maestros –> Preparar modificacion de datos maestros de acreedores.

Veamos un ejemplo de parametrización sencillo para proteger determinados campos en las fichas de cliente de la sección de datos generales y datos de sociedad.

Identificación de los campos a proteger.

Localizamos los campos desde la transaccion de modificación de clientes (XD02; para proveedores sería la XK02). Nos posicionamos en cada campo y pulsamos F1, y a continuación el botón de Información Técnica. En datos de campo tenemos la tabla y el nombre de campo en el que estamos interesados.

En nuestro ejemplo, vamos a proteger los campos:

• Datos generales –> Datos de Control –> Autorizacion: campo KNA1-BEGRU.
• Datos generales –> Datos de Control –> Sociedad GL: campo KNA1-VBUND.
• Datos generales –> Datos de Control –> Nº. ident.fis 1: campo KNA1-STCD1.
• Datos generales –> Datos de Control –> N.I.F. comunitario: campo KNA1-STCEG.
• Datos de sociedad –> Gestion de Cuenta –> Cuenta Asociada: campo KNB1-AKONT.
• Datos de sociedad –> Pagos –> Condiciones de pago: campo KNB1-ZTERM.
• Datos de sociedad –> Pagos –> Vias de pago: campo KNB1-ZWELS.

Creacion del grupo de campos.

Siguiendo la ruta de customizing indicada antes, entramos en la opción “Definir grupos campos para datos maestros deudores”. Aquí creamos una etiqueta númerica de dos digitos para identificar al grupo, una descripción y siempre dejaremos el flag “Sin autorizac.” desmarcado para indicar que queremos proteger los campos del grupo por autorizaciones.

Sino queremos que se haga la verificacion de autorizaciones, entonces marcaremos el flag “Sin autorizac”. En ese caso, el grupo de autorizaciones se utilizara con fines de reporting. El grupo de campos nos permitira analizar que modificaciones se han realizado en el maestro de clientes o proveedores en los campos que forman el grupo. Asi se facilita el analisis de las modificaciones (utilizaremos el report RFDABL00 para clientes y el report RFKABL00 para proveedores). Es una opción muy útil para hacer análisis de modificación de determinados campos.

Inclusion de los campos a proteger en el grupo de campos.

El siguiente paso consiste en detallar los campos que conforman cada grupo. Para ello, entramos en la opción “Agrupar campos de registros maestros de deudor” y para el identificador de nuestro grupo, detallamos los campos que indicamos antes.

Tenemos disponible una ayuda de búsqueda con todos los campos del maestro de clientes o proveedores disponible (incluyendo la parte general, de sociedad o de ventas/compras).

Asignación de autorizaciones a los usuarios.

Con la transacción PFCG creamos un rol de autorizaciones que incluira los objetos de autorización necesarios para modificar los campos incluidos en los grupos parametrizados anteriormente. Estos objetos son:

• F_KNA1_AEN: para clientes.
• F_LFA1_AEN: para proveedores.

En el objeto de autorización indicamos para que grupos de campos el usuario que posea este rol va a poder modificar los campos. Esto significa que podemos tener diferentes autorizaciones de forma que un usuario podrá solo modificar un determinado grupo de campos (aparte de los que no estan protegidos), otro usuario otro grupo e incluso un tercer usuario ambos grupos (asignandole los correspondientes roles). Esto nos da juego para en organizaciones grandes donde cada departamento puede gestionar determinados datos maestros, sea el propio departamento el único autorizado a modificar los datos que le afectan.

Para terminar, asignaremos al usuario con las transacciones SU01 o SU10 los roles definidos y ya podremos comprobar entrando al sistema la efectividad de la nueva parametrización realizada (en combinación con las autorizaciones creadas y asignadas).

Para el usuario sin el objeto de autorización F_KNA1_AEN, los campos previstos estan “en gris”, no modificables.

Para el usuario con el objeto de autorización F_KNA1_AEN, todos los campos están visibles.

Espero que os sea de utilidad la información.