Creación y uso de una variante de datos de propuesta SU24N de transacción (Parte 2)

Mi primera publicación de blog sobre la nueva transacción SU24N, que está disponible para el sistema SAP ERP a partir de SAP_BASIS ABAP versión 7.54, fue principalmente sobre una descripción general y la presentación de los cambios o mejoras innovadoras en SU24 tcode que apuntan al enlace de verificación de autorización entre Objetos de SAP que se pueden asignar a un rol técnico y los objetos de autorización, campos y valores de campo indicados en el código ABAP. Ahora, como ya se anunció en la parte 1, este blog se centrará en el hito más importante en el contexto de los valores de las propuestas de autorización y su control. Esta es la creación de variantes de datos de propuesta.

Considere los problemas típicos donde los departamentos comerciales o los controles internos requieren diferentes variantes de autorización para la ejecución de una transacción o servicio individual. Las autorizaciones faltantes se encuentran durante las evaluaciones de seguimiento o cuando el probador identifica un error de autorización durante la ejecución de una transacción en particular. Por ejemplo, el control de la transacción del cockpit BP en Visualización y Anexo/Modificación o en Autorizaciones de proveedor y cliente. La transacción FS00 también suele estar sujeta a restricciones de visualización y mantenimiento. Desafortunadamente, esto no se puede resolver rápida y fácilmente con la construcción de roles de mejores prácticas con la transacción SU24 existente y las actualizaciones de las tablas USOBT_C y USOBX_C. En el pasado, los administradores tenían que ajustar los valores predeterminados para los respectivos códigos de transacción (por lo general, eliminando los valores de los campos de autorización para dejar el campo en blanco) y luego mantener las autorizaciones requeridas para los diferentes escenarios de acceso de acuerdo con las especificaciones de los diferentes roles respectivos. Esto siempre condujo a un gran esfuerzo de mantenimiento, que aumentó exponencialmente con los cambios de proceso o las actualizaciones de transacciones SU25. Ahora, gracias a la transacción SU24N y sus variantes de datos de propuesta, esto ha terminado, ahorrando este mantenimiento de transacciones que consume mucho tiempo, ya sea para transacciones estándar de SAP o transacciones personalizadas (por ejemplo, transacción de parámetros). Las restricciones predefinidas en los valores predeterminados se pueden mantener utilizando las variantes de datos de la propuesta y luego implementarse en los roles de la función de trabajo. En el contexto de SAP S/4HANA y la simplificación y consolidación de funciones y aplicaciones asociadas, esta diferenciación granular es más esencial que nunca.

Este blog ahora mostrará cómo crear una variante SU24N y qué considerar durante la implementación, brindando las herramientas para desarrollar conceptos de autorización de mejores prácticas individuales y personalizados de acuerdo con el uso de los valores predeterminados y con un esfuerzo inicial único. .

Creación de una variante de datos de propuesta

Primero, ejecute la transacción SU24N. Luego seleccione una transacción para actualizar para crear una variante de datos de propuesta. Para poder presentar una descripción práctica del indicador de verificación, la separación de visualización y actualización en el contexto de la transacción FS00 (actualización del maestro de cuentas de mayor – central) se analiza aquí con más detalle. Esto es muy importante, porque en muchas organizaciones el mantenimiento de la cuenta de mayor a menudo está limitado para una cierta cantidad de usuarios finales, pero una gran parte de los usuarios debe poder ver esta información. Para identificar las declaraciones de verificación de autoridad adecuadas, seleccione la transacción FS00 y ejecute la selección (Figura 1).

En la ventana de mantenimiento, seleccione el botón para crear variantes en la barra de navegación del menú superior. Luego asigne un nombre de variante y una breve descripción. Asegúrese de que el nombre de la variante comience con un espacio de nombres de cliente (p. ej., Z o Y). En este caso, la variante de pantalla del FS00 se llama Z_FS00_ANZ. Cuando se guarda la variante de datos de la propuesta, se abre una ventana para almacenar la variante en el repositorio mediante una entrada de catálogo de objetos (Figura 2).

Esto no solo permite la asignación exacta de esta variante de datos de propuesta dentro del repositorio y el paquete de desarrollador correspondiente, sino también el transporte con el pedido de banco de trabajo posterior (Figura 3).

En este punto, los valores de visualización se mantienen en los respectivos campos de objeto de autorización de la variante de datos de propuesta creada, como se muestra en la Figura 4, 03 (visualización), 08 (visualización de documentos) o F4 (Ayuda F4).

Se puede hacer lo mismo para la variante de datos de propuesta de creación/cambio (Z_FS00_ANL_AEN) del tcode FS00 donde ahora se muestran dos variantes debajo de la transacción estándar FS00 después de completar la actividad (Figura 5).

Integración de la variante de datos de propuesta en un rol

Ahora, se han creado las dos primeras variantes de datos de propuesta. La variante ahora se puede incorporar a los roles respectivos como un objeto de autorización estándar (preferiblemente roles de función de trabajo como rol de referencia). Prácticamente no hay implementación técnica para que la variante de datos de la propuesta correspondiente entre en vigor. Como resultado, sus características respectivas pueden integrarse automáticamente en el perfil en los siguientes pasos de mantenimiento del rol técnico mediante la función de procesamiento de modo experto del perfil de autorización, sin esfuerzo adicional gracias a las variantes de valores predeterminados.

Para hacer esto, ejecute la transacción PFCG. Para los roles de función de trabajo existentes, por ejemplo, en el área de contabilidad financiera (usuarios clave), el FS00 generalmente ya está incluido, al menos en el contexto de la creación de roles de mejores prácticas. De lo contrario, agregue el objeto de código de transacción a través del menú de funciones. Para elegir la variante de datos de propuesta SU24N adecuada, haga clic en la nueva pestaña, «Solicitud», que contiene todas las variantes de datos de propuesta posibles en función de las transacciones almacenadas. Elija la nueva variante crear/mantener y desmarque la opción de la transacción FS00 sin una variante listada. (Figura 6).

Representación del perfil de autorización

Continúe con la pestaña Autorizaciones del rol que accede al modo experto para la generación de perfiles y seleccione «Leer estado anterior y fusionar con datos nuevos» en la ventana emergente Definir tipo de mantenimiento. Como resultado, el sistema compara los datos de perfil actuales con los datos de propuesta según la transacción SU24N y reconoce que se ha actualizado debido a la variante de datos de propuesta. Esto también se puede validar mediante la lista de utilización de los respectivos objetos de autorización. Un ejemplo de tal cambio durante la variante Z_FS00_ANL_AEN es el objeto de autorización F_SKA1_KTP (Figura 7).

En la lista de uso, la nueva variante de datos de propuesta identifica este objeto de autorización, incluido el campo y los valores, y ya no los valores de la transacción inicial FS00 (Figura 8). Ahora está disponible una columna adicional, «Variante de la aplicación», que incluye la variante recién creada, Z_FS00_ANL_AEN.

Resultado

Este blog ayuda a comprender cómo crear variantes de datos de propuestas de autorización individuales y personalizadas. Esto permite un control personalizado de los valores predeterminados de autorización y las autorizaciones dentro de las funciones de trabajo individuales, no solo reduciendo considerablemente el esfuerzo de mantenimiento de roles, sino también garantizando el uso estándar de autorizaciones, así como la capacidad de expansión de variantes y roles durante las actualizaciones de SAP.

Para obtener más información sobre el enfoque de conceptos de seguridad de mejores prácticas de Xiting para la creación de roles o para recibir asesoramiento completo durante una migración de autorización de SAP S/4HANA o un rediseño de autorización, Xiting está aquí para ayudar. Además, Xiting ofrece una variedad de diferentes servicios y productos para apoyar en el mantenimiento de autorizaciones en todos los sistemas SAP. Vea nuestro seminario web en vivo de Xiting sobre autorizaciones de SAP con XAMS.

Consultor de Seguridad SAP | Autorizaciones SAP a Xiting GmbH

El entusiasmo de Alexander Sambill por la seguridad y las autorizaciones de SAP lo convierte en un escritor apasionado de artículos técnicos y científicos, documentos técnicos, encuestas y más sobre la seguridad y las autorizaciones de SAP. También es el principal responsable de todas las publicaciones sobre autorizaciones de SAP en Xiting AG. Antes de comenzar a trabajar como consultor certificado de seguridad de SAP para Xiting, Alexander recibió su Maestría en Ciencias (MSc.) en economía energética y administración de empresas de la Universidad Técnica de Bergakademie Freiberg, Alemania. Durante sus años de trabajo dentro de SAP Security, se especializó para autorizaciones SAP en SAP ERP y SAP S/4HANA con SAP Fiori. Alexander lidera proyectos de rediseño y migración de autorizaciones, educa a los clientes como formador oficial de SAP y resuelve proyectos y casos de uso personalizados individuales. También es instructor certificado por el gobierno federal (IHK) en comercio e industria. En su tiempo libre, encontrarás a Alexander principalmente en los bosques o las montañas.

Últimos mensajes de Alexander Sambill (ver todo)