El propósito de este artículo es proporcionar una visión general de cómo la restricción de autorización de centros de coste y beneficio puede ser gestionada eficientemente en un entorno SAP.
Introducción
En primer lugar, es importante entender los conceptos principales que son la base de la restricción de autorización de Centros de Coste y Beneficio en SAP.
Configuración del Valor Organizacional:
A la hora de definir los accesos en un sistema SAP, además de qué actividades puede realizar un usuario (modificar, visualizar, etc.), es importante restringir en qué unidad organizativa puede realizar dicha actividad (en qué empresa, organización de ventas, etc.).
Teniendo esto en cuenta, los roles SAP se pueden gestionar de acuerdo con un modelo derivado del maestro en el que los roles comparten la misma autorización entre ellos, excepto por la restricción organizativa.
Al gestionar los roles de autorización, SAP ya proporciona por defecto ciertas restricciones organizativas que pueden utilizarse para restringir en qué unidad organizativa puede realizar sus actividades un usuario.
Sin embargo, los clientes, debido a sus necesidades específicas, también pueden convertir los valores de autorización normales en valores organizativos. Para ello, SAP ofrece la transacción estándar SUPO (Maintain Org Levels – Prof. Generator).
Por lo tanto, para definir y configurar completamente una restricción sólida dentro de los Centros de beneficio y de coste, y si no está ya en el sistema SAP, se recomienda convertir los siguientes valores de autorización en valores organizativos:
1) $PRCTR = Centro de beneficio
2) $KOSTL = Centro de costes
3) $RESPAREA = Área de responsabilidad
Importancia del Área de Responsabilidad:
Para implementar una restricción sólida para el Centro de Beneficio y Coste, y como se mencionó anteriormente, se recomienda considerar también el Área de Responsabilidad (RESPAREA).
La relevancia de este valor organizacional radica en el hecho de que ciertas transacciones relacionadas con el módulo CO, no sólo están validando contra qué Centro de Beneficio o Coste está trabajando el usuario, sino también el Área de Responsabilidad. Sin embargo, en ciertas transacciones, también es posible que sólo se valide el Área de Responsabilidad.
Esta es la razón por la que, para lograr una restricción sólida, el Área de Responsabilidad debe ser considerada también.
Configuración que debe ser aplicada para una restricción adecuada
Uno de los puntos clave para este tipo de proyectos sería involucrar al negocio en las revisiones y definición de la restricción, básicamente para los dos puntos siguientes:
1) Entender los diferentes procesos de negocio que involucran esos valores organizacionales y por lo tanto, configurar los accesos (roles SAP) para cumplir con las características especiales de las actividades de negocio (tales como procesos intercompañía u otras necesidades específicas de negocio).
2) Implicar a todas las partes interesadas para que comprendan las ventajas de una segregación adecuada, como una mayor eficacia y, además, evitar fallos en la rendición de cuentas.
Después de una breve introducción de las restricciones a implementar, también se mostrarán los siguientes puntos:
– Cómo rellenar los valores en roles para cada restricción de autorización previamente explicada.
– Objetos de autorización más comunes/relevantes en el módulo CO para Centro de Beneficio y Centro de Coste.
Centro de Coste
En primer lugar, la forma de identificar los Centros de Coste que están disponibles en el sistema y su relación con otros valores organizativos como Empresas sería revisar la información almacenada en la tabla CSKS (Cost Center Master Record).
Otras formas de identificar esta estructura y definir el modelo de rol de acuerdo con ella podría ser revisar las transacciones específicas que proporcionan dicha información. Las más interesantes podrían ser las siguientes
– KS03 >> Visualizar Centro de Coste
– KS05 >> Centro de Coste: Visualizar Modificaciones
– KS13 >> Centros de Coste: Informe de datos maestros
Por último, a continuación se muestran los objetos de autorización más relevantes que tienen restricción del Centro de Coste y que deben tenerse en cuenta:
– I_KOSTL >> PM: Centros de Coste
– K_CSKS >> CO-CCA: Maestro de Centros de Coste
– K_CSKS_PLA >> CO-CCA: Planificación de centros de coste
– K_REPO_CCA >> CO-CCA: Informes sobre centros de coste/clases de coste
Centro de beneficio
Por otro lado, en cuanto a la identificación de los Centros de Beneficio que están disponibles en el sistema, la información se almacena en la tabla CEPC (Tabla de Datos Maestros de Centros de Beneficio) para información básica.
Otras formas de identificar esta estructura y definir el modelo de rol de acuerdo podría ser investigar las siguientes tablas:
– SETNODE: filtrando por SETCLASS=0106, hay información relativa a la estructura (relación Centro de Beneficio Grupo-Subgrupo).
– SETLEAF: filtrando por SETCLASS=0106, hay información sobre la relación Grupo-Subgrupo de Centros de Beneficio y Centros de Beneficio concretos.
Otra forma de revisar estos datos sería llegar a las transacciones específicas que proporcionan dicha información. Las más interesantes podrían ser las siguientes
– KE53 >> Visualizar Centro de Beneficio
– KE5X >> Centro de Beneficio: Índice de Datos Maestros
– KE5Z >> Centro de beneficio: Partidas reales
Finalmente, a continuación se muestran los objetos de autorización más relevantes que tienen restricción de Centro de Beneficio:
– C_PROJ_PRC >> PS: Centro de beneficio para la definición del proyecto
– C_PRPS_PRC >> PS: Autorización de centro de beneficio para elementos PEP
– K_PCAR_REP >> EC-PCA: Informes de resumen y de partidas individuales.
– K_WIP_PC >> CO-PC-OBJ: Cálculo WIP y análisis de resultados
Restricción de roles en centros de costes y beneficios
En esta sección, se va a mostrar la forma de restringir estos valores organizacionales en el modelo de roles. La revisión se hará tanto para Centros de Coste como para Centros de Beneficio conjuntamente, ya que el procedimiento es muy similar para ambos.
En primer lugar, una vez definida la información de las relaciones entre otros datos maestros de valores de la organización y los centros de coste y beneficio, es el momento de establecer los valores que se aplicarán en cada rol.
Este mapeo dependerá de la relación entre los valores de la organización en cada sistema y la forma en que los roles se están derivando (por qué valor de la organización), por lo que la estrategia para la definición será diferente en cada cliente.
Lo que debería ser similar para todos los clientes sería la estructura jerárquica, es decir, cómo se mantienen los Centros de Coste y Beneficio en SAP.
Los Centros de Coste y Beneficio en SAP se almacenan en una jerarquía, donde los clientes pueden crear diferentes grupos y subgrupos que permiten almacenar los Centros de Coste y Beneficio que deben estar en el mismo nivel y tener características similares.
Existen diferentes formas de crear esta jerarquía, ya que es personalizable. Por ejemplo, algunos clientes prefieren crear grupos por Unidades de Negocio, otros prefieren agruparlos por Áreas Funcionales, o similares.
A continuación se muestra un ejemplo de la jerarquía estándar que SAP proporciona por defecto, donde se muestra la información de la estructura de centros de coste/beneficio en el sistema y cómo sería la inclusión de uno nuevo (TEST_COST).
Un punto importante que se debe tener en cuenta al crear la estructura es que, para rellenar los valores de Centros de Coste y Beneficio en los roles, es obligatorio dar acceso a los Centros de Coste/Beneficio específicos o establecer comodines (usando *).
El punto clave aquí es que no es posible seleccionar toda una estructura para dar acceso a esos valores organizacionales, ya que el sistema sólo permite seleccionar un valor específico.
Debido a eso, la recomendación al crear la estructura es seguir una convención de nomenclatura para el Centro de Coste y Beneficio y los Grupos de Centros de Coste y Beneficio, que permita utilizar comodines en caso de que los usuarios deban tener acceso a todo el grupo en la jerarquía.
Por ejemplo, en el ejemplo anterior, si los usuarios deben tener acceso a todo el grupo de administración, los roles podrían tener el valor «0001-1*», en lugar de seleccionar los Centros de Coste uno a uno. Este consejo también es útil cuando se crea un nuevo Centro de Coste o Beneficio dentro de la estructura, puesto que ya está definido que los roles deben proporcionar acceso a los grupos completos utilizando esos comodines.
RESPAREA
Por último, la configuración del área de responsabilidad sería diferente al resto de valores organizativos, ya que algunos valores de ésta están bloqueados por defecto en la gestión de roles, y es necesario realizar una configuración previa antes de empezar a rellenar los valores organizativos en SAP Roles.
El primer paso sería configurar la tabla KBEROBJ (Opciones para objetos de autorización en Contabilidad de Centros de Coste), para especificar los campos que se requieren restringir dentro del valor organizativo RESPAREA.
Básicamente, dentro de este valor organizativo, existen diferentes restricciones que se pueden realizar, en base a los siguientes campos:
– KS: Centro de coste
– HI: Jerarquía de autorización (nodos de jerarquía de centros de coste)
– KN: Grupo de centros de coste
– PC: Centro de beneficio
– PH: Grupo de centros de beneficio
– BP: Proceso empresarial
– BH: Nodos del proceso empresarial
– OR: Pedidos
Es importante destacar que no todos estos campos se validan una vez ejecutada una transacción en SAP. Los más relevantes serían las 5 primeras restricciones. De hecho, la estructura del Proceso de Negocio puede no estar definida en algunos sistemas.
Los pasos técnicos para realizar esta configuración se explican en la nota SAP 698401 (RESPAREA como campo de nivel organizativo).
En resumen, es necesario registrar en la tabla KBEROBJ los valores organizativos que se necesitan restringir dentro del RESPAREA en el modelo de roles. Para ello, como se menciona en la nota, el campo clave OBJETO debe permanecer vacío y el campo CURRENTOBJ debe estar relleno, ya que en caso contrario, no se podrá determinar la pantalla inicial (el valor incluido en este campo no es relevante para la gestión del rol, por lo que no se tomará como configurado si no se incluye en los siguientes campos).
Una vez finalizada esta configuración, el siguiente paso sería rellenar los valores organizativos necesarios en el modelo de rol, utilizando el campo RESPAREA (Área de Responsabilidad CO-OM).
Restricción de roles en RESPAREA
Como se ha mencionado anteriormente, este valor organizativo almacena múltiples restricciones. Para rellenar los valores, primero es necesario seleccionar en primer lugar la opción «cambiar» en la definición de valores organizativos, y entonces aparece una nueva ventana, con las diferentes pestañas que se configuraron previamente en la tabla KBEROBJ.
A continuación, los roles pueden restringirse con diferentes variables.
Cada una de estas variables debe definirse utilizando la pestaña correspondiente y todas excepto la Orden deben estar relacionadas con una Zona de Control específica.
Por último, a continuación se muestran los objetos de autorización más relevantes que tienen este tipo de restricción:
– K_CCA>> CO-CCA: Objeto de autorización general para la contabilidad de centros de coste
– K_PCA>> EC-PCA: Área de responsabilidad, Centro de beneficio
PUNTOS CLAVE:
– Los valores organizativos en los sistemas SAP son la forma que SAP proporciona para restringir roles en el sistema siguiendo un comportamiento organizativo.
– Para lograr la restricción más completa dentro de las autorizaciones de los Centros de Beneficio y Coste, es muy importante definir y configurar adecuadamente la restricción del Área de Responsabilidad.
– Uno de los puntos clave para que estos proyectos tengan éxito sería involucrar al negocio en las revisiones y definición de las restricciones.
– La estructura jerárquica que almacena cómo se mantienen los Centros de Coste y Beneficio en SAP es similar en la mayoría de los casos, pero la relación entre los valores organizativos en cada sistema y la forma en que se derivan los roles será diferente en cada sistema.
– La configuración del valor organizativo RESPAREA requiere algunos pasos previos, como configurar la tabla KBEROBJ para abrir los campos para la gestión de roles. SAP proporciona un procedimiento paso a paso para este asunto dentro de la nota 698401 (RESPAREA como campo de nivel organizativo).