Cuando trabajamos con los documentos de compras (pedidos, solicitudes de pedido, pedidos abiertos, etc), trabajamos con varios elementos que determinan el comportamiento del sistema:

• Clase de documento: puede determinar desde el rango de números a utilizar, tipos de posición permitidas, configuración de campos, estrategias de liberación (si se han configurado por clase de documento), verificaciones en exits, etc, etc. Podemos crear nuestras propias clases de documento.
• Tipo de posición: determina como se controla el aprovisionamiento para una posición. Los valores disponibles los determina el estándar Sap. Por ejemplo, podemos tener tipos de posición Normal, P Limite, C Consignación, L Subcontratación, F Servicio, etc.
• Tipo de imputación: determina, entre otras cosas, que datos de imputación son necesarios para la posición del pedido de compras. Se pueden parametrizar nuevos códigos además de los facilitados por Sap.

Si entramos a la parametrización de los Tipos de imputación, desde la vista V_T163K (transacción SM31) o bien en la ruta de customizing Gestión de materiales –> Compras –> Imputación –> Actualizar tipos de imputación, podemos observar que realmente se determinan muchas mas cosas que el tipo de imputación que vamos a realizar.

En el ejemplo vemos la configuración del tipo de Imputación K Centro de coste. Podemos observar dos secciones en la configuración:

• Campos (parte inferior): aquí se configuran los campos que van a aparecer en cada tipo de imputación, su obligatoriedad o no, si son o no modificables, etc. Por ejemplo, para este tipo de imputación vemos que es obligatorio el Centro de coste y la Cuenta de Mayor. Cada tipo de imputación tendrá su propia lógica de campos según el objeto de imputación que se este utilizando.
• Info detallada (parte superior): aquí se indican diferentes parámetros que determinan el comportamiento del sistema al realizar operaciones de entrada de mercancía o registro de factura sobre la posición del documento (por ejemplo, un pedido de compras). Por ejemplo:
  • Imput. modificable o imp.modificable RF: determina si en un pedido vamos a poder modificar la imputación una vez realizada una entrada de mercancía o una recepción de factura.
  • Ind.pantalla imp.:  determina si tenemos una imputación simple o multiple por defecto.
  • Stock especial: si queremos que un tipo de imputación siempre proponga un stock especial, lo podemos indicar aquí.
  • Distribución: para las imputaciones múltiples en una una posición de documento. Indica si la distribución se hace por cantidades o porcentajes.
  • Derivar de imputación: determinar a partir de la cuenta contable obtenida la imputación (si se ha configurado en el sistema la derivación de imputaciones a partir de las clases de coste).
  • Entrada de mercancías: indica si la posición esta vinculada a una entrada de mercancía.
  • EM no valorada: si la valoración de las mercancías se ha de hacer al recibir la factura, y no en la entrada de mercancía.
  • Recepción facturas: indicar si se ha de recibir una factura de la posición (desmarcado indica que sera una entrada gratuita, sin factura).
  • Ind.EM obligatorio, No val.EM oblig, Ind.RF obligatorio: para forzar a que el valor de los tres flags anteriores que hayamos indicado se quede preestablecido y ademas no se pueda modificar.

Si nos vamos al pedido de compras, podemos ver como esta afectando toda esta parametrización a nivel de posición. Por ejemplo:

• Campos: el tipo de imputación determina que campos aparece en la pestaña imputación. Si son obligatorios u opcionales, si son modificables o no.

• Ind.pantalla imp.: el tipo de distribucion por defecto al entrar en la pestaña imputacion. Por ejemplo, si cambio en el tipo de imputación K este indicador, al entrar a nivel de posición en la pestaña imputación me aparece por defecto la imputación multiple.

• Entrada de mercancías o EM no valorada:  determinan que el correspondiente flag aparezca marcado o no en la pestaña Entrega a nivel de posición del pedido.

• Recepción facturas: determina que el correspondiente flag aparezca marcado o no en la pestaña Factura a nivel de posición de pedido.

• Ind.EM obligatorio, No val.EM oblig, Ind.RF obligatorio: los tres flags anteriores aparecerán siempre marcados con la opción indicada en los puntos anteriores (y el usuario no los podrá modificar).

Y ahora os preguntareis, ¿para que nos puede valer crear nuestros propios tipos de imputación o realizar ajustes en los existentes?. Aquí os dejo algunos ejemplos que se me ocurren, y que principalmente pueden redundar en mejorar la productividad del usuario, forzar determinados campos, evitar errores u obtener un comportamiento determinado del sistema:

1. Crear un tipo de imputación para combinar un objeto de imputación normal (Centro de coste o Pep), con un objeto estadístico (Orden estadística) y que ambos sean obligatorios: esto lo podremos hacer configurando en la sección de Campos los dos campos afectados como obligatorios (por ejemplo Centro de Coste y Orden).
2. No permitir la modificación de la cuenta de mayor que deriva la determinación de cuentas automática: igualmente en la sección de Campos, poniendo a la Cta. Mayor como campo solo visualización.
3. Obligar a que un determinado tipo de imputación siempre tenga Recepción de mercancía: marcaremos en la sección Info detallada los flags “Entrada mercancias” y “Ind.EM obligatorio“. Asi todos los pedidos que utilizen ese tipo de imputación siempre tendrán los flags marcados.
4. En caso contrario al anterior, en una empresa no queremos hacer entrada de mercancía (son servicios, por ejemplo), y queremos que solo se registren facturas y en el momento del registro de esta, genera el movimiento del gasto sin haber pasado por la cuenta de facturas pendientes de recibir. En este caso desmarcaremos los flags  “Entrada mercancias” y “Ind.EM obligatorio“.
5. Si queremos que siempre se haga la entrada de mercancia no valorada y posteriormente se registre la factura: marcaremos los flags “EM no valorada” y el flag “Recepción facturas” (marcando ademas los “No val.EM oblig” y “Ind.RF obligatorio” sino queremos que el usuario pueda modificar los valores).
6. Proponer por defecto en un tipo de imputación la información de imputación múltiple para indicar varios centros coste, ordenes, peps, etc: esto lo haremos en el campo “Ind.pantalla imp”, poniendo el valor “1 – Imputación multiple”.
7. Modificar la imputación de una posición de pedido tras una entrada de mercancía o una recepción de factura: con los flags “Imput.modificable” e “Imput.modificable RF” podemos permitir esta modificación.
8. Si hemos parametrizado la determinación de imputaciones a partir  de la clase de coste (transacción OKB9), hacer que la imputación se derive automáticamente de la cuenta de mayor introducida u obtenida de la parametrización de cuentas automática: marcando el flag “Derivar de imput“.
9. Cuando haya costes indirectos de adquisición, que contabilicen en una cuenta por separado: marcando el flag “CargClAsep“.
10. Proponer que nunca se pueda hacer entrada de mercancía (y que no se pueda modificar) y que siempre haya que registrar factura: dejaremos sin marcar el flag “Entrada mercancias” y marcaremos “Ind.EM obligatorio”, “Recepción facturas” y “Ind.RF obligatorio”.

En este caso, en la entrada de pedido el sistema se comportara tal y como vemos en la imagen. La entrada de mercancía estará desmarcada y deshabilitada su modificación (pestaña Entrega) y la recepción de factura estará marcada e igualmente deshabilitada su modificación.

Estos son solo algunos ejemplos, pero como podéis ver, pueden solucionar muchas problemáticas que se presenten en cualquier empresa en los aspectos relacionados con la gestión de compras y sus imputaciones, la recepción de mercancía y registro de facturas.

Nota: si creamos tipos de imputación nuevos, habrá que autorizar para que tipos de posición esta permitido su uso. Tener en cuenta la limitación de 1 carácter para los códigos de los tipos de imputación (esto es una limitación).

En un entorno Sap multisociedad, donde los usuarios trabajan con diferentes compañias, puede ser útil proporcionarles un mecanismo que les permita fácilmente distinguir si se encuentran trabajando con una empresa u otra.

En el registro de facturas de compras desde logística (la transacción MIRO), existe una opción de parametrización que nos permite configurar este aspecto.

En la ruta de customizing Gestión de materiales –> Verificación de facturas logística –> Factura recibida –> Definir logo de inicio  (o con la vista V_169P_LOGO, transacción SM31) podemos indicar las sociedades para los que queremos que se muestre un logo en el registro de facturas, con la correspondiente ruta (url) donde se encuentra la imagen. La opción se puede activar/desactivar con el flag correspondiente.

Una vez configurada la imagen, al entrar en la MIRO y seleccionar la sociedad indicada, en la parte derecha de la pantalla aparecerá el logotipo de la empresa (que estará siendo leído de la ruta que hayamos indicado).

NOTA: aunque el logotipo aparece al entrar en la transacción y seleccionar la sociedad con la que estamos trabajando, cuando se indican los datos del proveedor (o se recuperan de un pedido de compras), la imagen se sustituye por la información habitual del proveedor (Nombre, dirección, población, teléfonos, acceso al listado de partidas abiertas, etc).

Como veis, una opción útil en instalaciones Sap con muchas sociedades, o simplemente algo estético para aquellos clientes más rebuscados.

En mis años de experiencia con Sap, he recibido la misma pregunta por parte de muchos usuarios: ¿no hay una ayuda estándar de Sap que nos pueda ser útil para empezar con Sap o para profundizar en él?.

La respuesta es que sí, aunque con algunos peros. El principal inconveniente es que al tratarse de un sistema que se parametriza y cuyo comportamiento se puede personalizar, esta ayuda nos dará una visión global del sistema, sin entrar en las peculiaridades que hayamos configurado en nuestro sistema. Otro inconveniente es el idioma, ya que desde la versión 4.70, no esta disponible  en Español.

La ayuda Online de Sap se proporciona en una CD´s junto con el software de instalación de Sap. Los ficheros que la componen se depositan en una ruta de un servidor de la red y se configura la transaccion SR13 para indicarle al sistema en que lugar esta depositada para cuando los usuarios intenten hacer uso de ella desde el Sapgui. Desde hace unos años, la ayuda también esta disponible completa online en el portal de Sap http://help.sap.com. La ayuda varia según la versión de Sap con la que estemos trabajando. Por ejemplo:

• ERP: si estamos trabajando con un ERP, podemos acceder a la ayuda de las diferentes versiones en la ruta http://help.sap.com/erp.
• ERP Version 4.70: la ultima que tiene la ayuda en castellano, podéis acceder a ella desde este link.
• ECC Version 6.0: disponible en ingles y en otros idiomas (Francés, Alemán, Ruso, Japones y Chino  ), podéis acceder a ella desde este link. Tenemos disponibles diferentes ayudas según el EHP que tengamos instalado.
• Otros componentes: hay una ayuda para los diferentes productos de Sap, desde Sap Netweawer, Addons, CRM, SRM, PLM, SLM, etc.

Como podéis ver en el ejemplo siguiente (corresponde a la ayuda en castellano para la version 4.7), la información se muestra en forma de árbol, donde podemos ir navegando por los componentes hasta llegar a aquél en el que estemos interesados.

En este contexto, puede ser un poco complicado llegar hasta la información que necesitamos. Otra alternativa es configurar el acceso a la ayuda en Sap (con la transacción SR13, como os he indicado antes). En cualquier transacción de Sap en la que nos encontramos, siempre tenemos disponible el menú de Ayuda, con varias opciones: Ayuda aplicación, Biblioteca Sap, Glosario.

Las opcion Biblioteca nos lleva al menú principal de la ayuda y el Glosario a un resumen alfabetico de terminos. Pero lo más interesante, es que la opción Ayuda p.aplicación es contextual, y nos lleva a la sección de la ayuda relacionada con la transacción en la que nos encontremos. Por ejemplo, dentro de la transacción MIRO de registro de facturas, en una version ECC 6.0, al seleccionar la ayuda para aplicación, nos lleva al siguiente link:

Como veis, en este caso hemos ido “al grano”, justo al tema de la ayuda relacionado con la funcionalidad Sap con la que estamos trabajando. Esto es lo que realmente puede ser útil a los usuarios o a los consultores.

Para terminar, vamos a ver un poco como configurar la transacción SR13, que es la que permite que esta funcionalidad este disponible. Os recomiendo la lectura de esta entrada del SCN donde se habla de los pasos necesarios para la instalacion de la ayuda.

Básicamente, tenemos varios formatos disponibles (los que nos proporciona Sap), pudiendo instalarla a nivel de carpetas de Red o en un servidor HTTP. La ayuda se configura en la SR13 para las diferentes plataformas de Windows. En mi ejemplo, he depositado los ficheros de ayuda en una carpeta de red de mi servidor, y en la configuración hago referencia a la ruta donde se encuentran. Una vez hecha esta configuración, la ayuda contextual estará disponible para los usuarios.

Quien no ha hecho o ha consultado alguna vez la típica lista de transacciones de Sap o de las tablas mas frecuentes que se utilizan en los diferentes módulos.

Lo ideal sería, en estos tiempos en los que todo es móvil o tablet, tener un aplicación donde llevar esa información siempre con nosotros. Gracias a Gregor Brett, que ha desarrollado varias aplicaciones en Android, tenemos disponibles algunas apps que hacen este trabajo para nosotros.

Respecto a las transacciones, tenemos la aplicación SAP Searcher, que nos organiza por módulos cerca de 16 mil transacciones, incluyendo la posibilidad de realizar búsquedas por nombre, descripción por módulo. Igualmente, nos permite construir nuestras listas de favoritos e incluso añadir nuestras propias transacciones.

Otra aplicación interesante es Sap Tables, que nos permite acceder a las tablas mas usadas, organizadas igualmente por módulos. Esta aplicación es más sencilla que la anterior y con menos funcionalidades.

El mismo desarrollador tiene otra aplicación llamada Sap ABAP Cookbook para gestionar desde el móvil nuestro código abap, permitiendo exportar el codigo en ficheros de texto y enviarlo por email.

Para terminar, otra aplicación relacionada con Sap, en este caso de John Moy, llamada myHelp for SAP Professionals. Esta aplicacion nos permite realizar búsquedas desde nuestro móvil o tablet en la ayuda online de Sap (help.sap.com), de la que hablamos en nuestra anterior entrada del blog.

Con el desarrollo de los smartphones y las tablets, este tipo de aplicaciones seguro que van a crecer mucho en los próximos meses, y tendremos muchas más utilidades similares a estas.

Archivado en: Productividad, Sap Basis

Para empezar el 2013 vamos a ver un truco muy sencillo, pero muy util para la mayoria de usuarios de un sistema Sap. Se trata de un truco de ergonomia que nos permite personalizar la disposición de los campos en los “Table Control”. Estos son un elemento de la programación Abap que se utilizan para mostrar listas de datos en forma de tabla. Por ejemplo, el resumen de posiciones en un pedido de compras o de ventas es el tipico Table Control. Podemos verificar que estamos en un elemento de este tipo por el icono que aparece en la parte superior derecha del control, que nos permite acceder a la configuración personalizada.

La personalización se puede realizar a dos niveles:

• Nivel de Usuario: se ha de realizar usuario a usuario y con ella se puede configurar el orden de los campos que aparecen en el control, asi como su ancho. Se pueden definir varias visualizaciones por usuario para el mismo table control, aunque solo una de ellas será la opción por defecto. En el caso de haber varias, se puede cambiar en cualquier momento de una disposición a otra.
• Nivel de Responsable del Sistema: son disposiciones validas para todos los usuarios y todos los mandantes, aunque si un usuario tiene su disposición propia, esta estará por encima de la de sistema. Aqui, ademas del orden de los campos y su ancho, se puede configurar también si un campo es visible o no, así como la cantidad de columnas fijas y las lineas de separación (horizontales y verticales). Esta opción no debería de estar disponible para todos los usuarios (se requiere para ella el objeto de autorización S_ADMI_FCD), por lo delicado de esta configuración general.

Vamos a ver un ejemplo de personalización de ambos tipos.

Personalizacion a nivel de usuario del orden de campos y ancho de estos en el resumen de posiciones de un pedido de compras (transaccion ME21N/ME22N).

En este supuesto un usuario del departamento de compras nos plantea que, de cara a la mejora de productividad en el uso de la transacción de Creación/Modificación de pedidos de compras, la posibilidad de modificar el orden de los campos y su ancho en el resumen de posiciones del pedido. El usuario quiere los siguientes cambios:

• Los flags “Posicion de devolución” y “Posicion gratuita” estén al principio de la linea, despues del campo tipo de posicion.
• Cambio en los tamaños de los campos Material, Texto Breve Material.
• Campo Lote se localize despues de la cantidad de pedido.
• Grupo de material se localize despues del almacén.

Lo primero que hay que realizar es modificar la disposición de los campos; para el caso del ancho de estos, ajustarlo moviendo en la cabecera la esquina superior derecha de cada campo ampliandolo o reduciendolo. Para el caso de la posición, si queremos modificar la de un campo, seleccionaremos este, y lo arrastraremos en el table control hasta el lugar donde queremos que se localice.

Una vez preparada la disposicion, seleccionaremos el icono en la esquina superior derecha del table control y nos aparecera un dialogo para guardar los valores de nuestra configuración.

Para crear la nueva disposición (o modificar una ya existente), indicaremos un nombre para ella en el campo Variante (sección de la pantalla Gestionar Variantes) y pulsaremos el boton Crear para guardarla. Si deseamos que la disposición se quede como por defecto marcaremos el flag “Utilizar como parametrización std”. De esta forma, cada vez que el usuario entre a Sap en esta transaccion (ME21N/ME22N), los campos le sera visualizados de la forma descrita.

Si el usuario quiere en cualquier momento cambiar a la parametrización estandar, volvera a entrar a la configuración del Table Control y en la sección “Seleccionar variantes” indicará en Opción actual “Parametrización básica”, volviendo a la visualización de sistema definida de forma global. También podrá modificar o borrar la disposición que se hubiera creado o seleccionar otra de las disposiciones que se hubieran configurado para el.

Personalizacion a nivel de sistema del resumen de posiciones en la creacion/modificación de pedidos de ventas (transacciones VA01/VA02).

En este caso, queremos configurar para todos los usuarios del sistema, los siguientes aspectos:

• Modificar el ancho de las columnas Material y Denominación.
• El campo Importe se encuentre posicion despues de la unidad de medida de la venta.
• Hacer invisible el campo Numero de material del cliente.

Para ello, hacemos como en el caso anterior. Modificamos por un lado el ancho de los campos y posicionamos los que queremos cambiar de ubicación al sitio deseado. Una vez realizada esta tarea, seleccionamos en la parte superior derecha del table control el icono para su configuración.

En este caso, seleccionamos la opción  Responsable del Sistema. Nos aparecerá un nuevo diálogo donde podremos realizar la configuración de la parametrización de sistema.

En esta pantalla podremos seleccionar los campos que queremos ocultar (Marcando la casilla Invisible). También podremos indicar el número de columnas fijas y si queremos lineas de separación horizontal/vertical en la sección Otras parametrizaciones.

Una vez terminada la configuración, seleccionaremos el botón Activar y la configuración quedará establecida para todos los usuarios del sistema en todos los mandantes (a no ser que los usuarios tengan configuradas sus propias disposiciones).

En nuestro ejemplo, la pantalla de resumen de posiciones en la creación de pedidos de venta tendrá el siguiente aspecto:

Como podeís ver, un truco muy sencillo pero que nos da muchisimas posibilidades de mejorar la experiencia de usuario con las transacciones en las que se utilizan estos controles (muy ampliamente utilizados en la programación de las transacciones de Sap).

El año 2012 ha terminado para bien o para mal, con todos los problemas y dificultades para muchos de nosotros, y esperando que el 2013 sea mucho mejor en todos los aspectos, me gustaria compartir con vosotros los números de este blog durante el año que acabamos de concluir.

El blog tuvo cerca de 220.000 visitas en 2012, habiendo alcanzado las 285.000 visitas totales desde que comence a escribir en él a finales de 2010. En 2012 se publicaron 23 articulos nuevos, aumentando el archivo completo de articulos de este blog a 61 (podeís ver la lista completa aquí). El día con más visitas fue el 24 de octubre de 2012 con 1380 visitas.

Respecto al origen geográfico de nuestros visitantes, la mayoria provienen de paises donde se habla español, destacando España mas de 47 mil visitas, México con cerca de 34 mil, Chile, Colombia, Argentina o Perú.

Algunas de las entradas con más visitas son:

MM		14.043
Preparando la certificación MM de Sap.		11.442
Crear estrategias de liberación en pedidos de compras		9.482
Truco 13. Transacciones personalizadas con las variantes de transacción (SHDO).		9.005
Transacciones		8.718
Truco 8. Parametros de control mas importantes en un sistema Sap.		7.353
Truco 10. Actualización masiva de usuarios.		6.186
Truco 7. Uso de User-exits para verificaciones en datos maestros.		5.042
ABAP		4.682
Truco 6. Ampliacion de ayudas de busqueda (Matchcode).		4.415

El blog ha alcanzado la lista de 200 seguidores, los cuales reciben via email todas las publicaciones que se realizan en este blog. Ademas, a través de mi cuenta de Twitter otros 300 seguidores reciben los links de las nuevas publicaciones así como otros enlaces interesantes de publicaciones referentes al mundo Sap.

Lo que empezo siendo un lugar de trabajo personal donde documentar aspectos de Sap en los que iba trabajando día a día (como recopilatorio de información), va creciendo poco a poco y es un placer para mi poder seguir compartiendo conocimiento con todos vosotros asi como ayudar en lo posible a todo aquel que pregunta o tiene problemas con este sistema al que nos dedicamos que se llama Sap. Seguimos en contacto.

¡Feliz 2013 a todos!

Nuestro truco de hoy habla de las opciones de personalizacion por usuario que podemos configurar en el modulo de Finanzas (FI). Básicamente, las opciones disponibles se pueden acceder desde la transacción FB00.

Cuando llamamos a la transacción desde el menú de Sap, nos aparecen una serie de opciones configurables organizadas en carpetas:

Cuandos estamos en las transacciones enjoy para contabilizar (FB50 Cuentas Mayor, FB60 Facturas de Acreedor, FB70 Facturas de Deudor), accediendo a “Opciones de tratamiento” también podemos configurar aspectos adicionales en el registro de los asientos contables:

Vamos a ver un poco en detalle alguna de las interesantes opciones que podemos configurar.

Por ejemplo, en la pestaña “Entr.documento” podemos definir opciones que afectan al momento de estar registrando movimientos contables. Algunas opciones interesantes son:

• Documentos solo en moneda local: solo se permite registrar documentos en moneda local, desapareciendo los campos para indicar la moneda.
• Solo se pueden reg.docs.compl.prelim: cuando estemos trabajando con documentos preliminares, si se marca este flag no se podran registran este tipo de asientos sino estan saldados (saldo debe/haber a 0).
• Calcular impuestos sobre imptes.netos:
• Copiar texto en registro cuenta mayor: se copia el ultimo texto indicado a nivel de posicion en las posiciones siguientes.
• Estructuras de linea para la entrada rapida de documentos: podemos tener definidas diferentes configuraciones de lineas y aquí seleccionar cual queremos utilizar por defecto.

Si ademas estamos en las transacciones Enjoy (FB50,FB60,FB70, etc), tenemos opciones adicionales a las citadas:

• Visual.periodos: nos muestra el periodo contable en el que estemos contabilizando (util si tenemos que contabilizar en los periodos especiales).
• Permite contab.en periodos especiales: unida a la opcion anterior, permite utilizar los periodos adicionales (13,14,15,16) para contabilizaciones por ejemplo en ajustes de cierre.
• Cl.doc: Opción. Con esta opción podemos hacer que aparezca la clase de documento con diferentes opciones (oculta, solo visualizacion, modificable con o sin descripcion, etc).
• Fe.documento igual fe.contabil: se propone al entrar en los asientos la fecha de documento y la fecha de contabilizacion con la fecha del sistema.
• Proponer ultimo indicar fiscal: nos propone automáticamente el ultimo indicador de impuestos utilizado.

En la pestaña Visual.doc podemos configurar la forma en que se visualizan los documentos contables:

En la pestaña Part.abiertas podemos configurar diferentes aspectos en los procesos de tratamiento de partidas abiertas (compensacion o pago):

• Tratar partidas con comandos: nos muestra en el listado de partidas a compensar un campo donde podemos introducir comandos para el tratamiento de las partidas (con F1 podemos ver la sintaxis. Por ejemplo: – desactiva una partida, + la activa, -* desactiva todas las partidas, +* activa todas, etc).
• Partidas selec.inicialmente inactivas: las partidas al entrar en la transacciones de compensación aparecen desmarcadas (si no se indica esta opción, apareceran todas seleccionadas).
• Utilizacion de pools de trabajo: permite utilizar al compensar, no solo un numero de cuenta, sino también un pool de cuentas (grupos que podremos definir que incluiran varias de ellas).
• Variantes de estructura lineas: podemos indicar que estructura de linea nos aparecerá por defecto en las transacciones de compensación de partidas abiertas de cuentas de mayor, deudores o acreedores.

Finalmente, para terminar, en la Pestaña PI podemos indicar diferentes aspectos que afectaran a los informes de visualizacion de partidas abiertas (FBL1N, FBL3N o FBL5N entre otros). Por ejemplo:

• Pools de trabajo disponibles: los pools de cuentas (agrupaciones configurables) tambien se pueden utilizar para hacer selecciones de partidas.
• Layouts por defecto: podemos configurar un layout por defecto para el usuario en los diferentes informes de partidas individuales (cuentas de mayor, deudor o acreedor).
• Representacion: podemos hacer que el informe de partidas abiertas se muestre en el formato ALV clasico (texto) o en ALV Control Grid (grafico).
• Seleccion linea: bifurcar en: cuando entramos al detalle de una partida abierta desde el informe de partidas, aquí indicamos si queremos ver solo esa posición o el asiento contable completo.
• Cantidad máxima de partidas: podemos indicar un limite al número de partidas que se visualizan.

Como veís, una transacción que hay que tener siempre en mente cuando estamos hablando del módulo de FI, y que permite solucionar más de un requerimiento sencillo de los usuarios. Por cierto, los valores indicados se guardan en el perfil de usuario mediantes parametros de memoria.

Podeis comprobar vosotros mismos cuando al cambiar los valores de configuración en la FB00 el perfil de usuario va cambiando y los valores de los parametros en la ficha del usuario se actualizan (accesibles desde la transacción SU01, pestaña Parametros o desde el menú de Sap, opción Sistema –> Valores prefijados –> Datos propios).

Nuestro truco de hoy habla de una funcionalidad estandar que permite realizar operaciones multisociedad en un entorno Sap donde tenemos varias sociedades de Finanzas en el mismo mandante y se realizan operaciones entre las sociedades: creditos, pagos o cobros por cuenta de la otra sociedad u otro tipo de operaciones. Con estos movimientos multisociedad realizamos en un solo paso movimientos contables en los que estan implicadas 2 o más sociedades, y que en condiciones normales realizariamos en dos asientos (uno en cada sociedad).

A nivel de parametrización, se configura mediante la transacción OBYA (ruta de customizing Gestion Financiera –> Contabilidad principal –> Operaciones contables –> Preparar operaciones multisociedades),  las cuentas de compensación y las claves de contabilización que se utilizaran en estos movimientos.

Se pueden utilizar cuentas de compensacion del tipo Cuenta de Mayor o bien cuentas de Deudor/Acreedor (con las correspondientes claves de contabilizacion). En el ejemplo, estamos utillizando cuentas de acreedor (estaran creadas en la FK01), de forma que en la sociedad 1003 tenemos el acreedor F1004 para reflejar las operaciones multisociedad que hemos hecho contra la sociedad 1004, y en la sociedad 1004 tenemos el acreedor F1003 para las operaciones con la sociedad 1003. Utilizamos las claves de contabilización: 24 Otros creditos y 34 Otras deudas. En esta cuenta tendremos registrados todos los movimientos realizados contra la otra sociedad y por tanto, su saldo.

Para entender mejor a nivel contable como funciona esto, vamos a ver un ejemplo:

La sociedad A realiza un pago de una factura de la sociedad Y.

En la sociedad 1004 hacemos una compensación contra la cuenta de un banco y seleccionamos una factura de un proveedor de la sociedad 1003 que estamos pagando con fondos de la otra empresa. Pero la factura la esta pagando la sociedad 1004. El apunte lo registrariamos con la transacción F-07. La primera parte del asiento (la cuenta del banco), la indicariamos en la sociedad emisora del pago (1004).

Al seleccionar las partidas que se pagan, cambiariamos de sociedad y seleccionariamos la factura en la sociedad 1003 que se esta pagando en la operación. Antes de grabar el documento, lo simulamos y nos aparece algo así:

Las dos primeras posiciones son las que nosotros hemos introducido (ver como cada posicion se asigna a una sociedad). Las dos segundas las ha generado automáticamente el sistema al detectar que estamos en una operacion multisociedad entre las sociedades 1003 y 1004. En este momento ha recuperado la parametrización Multisociedad para saber como tiene que generar el asiento completo. Grabamos el asiento y como tenemos en nuestras opciones de FI por usuario que se muestren las operaciones multisociedad, el sistema nos informa de la contabilización de la siguiente manera:

Se han generado dos asientos, uno en cada sociedad, pero vinculados entre si por un documento multisociedad. Si consultamos el asiento en la sociedad 1004, tiene el siguiente aspecto:

Tenemos un cargo al haber en la cuenta del banco (de donde sale el dinero para el pago) y un cargo al debe a la cuenta del Acreedor que representa la otra sociedad, como un credito que le hemos concedido para realizar el pago en su nombre.

Si nos vamos a la otra sociedad (la 1003), el asiento contable refleja la compensacion de la factura contra la cuenta del proveedor al debe y un cargo al haber a la cuenta del Acreedor que representa la otra sociedad, que nos ha hecho un prestamo, y en esta sociedad aparece como una deuda.

NOTA: cuando se realizan contabilizaciones de este tipo, se crea un documento especial, llamado Multisociedad, que vincula los diferentes documentos generados en las sociedades implicadas en el movimiento. La anulación de estos movimientos se realiza con la transacción especial FBU8 (igualmente la FBU2 para modificar y la FBU3 para visualizar). Por ejemplo, si consultamos el asiento creado tiene el siguiente aspecto:

Si consultamos las partidas abiertas de los acreedores F1003 y F1004 nos reflejan las operaciones que se han realizado entre las sociedades y si son finalmente una deuda o un prestamo.

La misma funcionalidad la podemos utilizar para realizar asientos contables en los que intervienes dos o mas sociedades, operaciones de compensación, registro de facturas en logistica, etc. Y siempre finalmente generaremos movimientos multisociedad que iran generando movimientos en estas “acreedores financieros” que funcionan como una cuenta de credito/deuda entre las diferentes sociedades. De esta forma, estamos ahorrando trabajo administrativo al realizar los asientos y las operaciones se pueden registrar de una forma global cuyo seguimiento y verificación es más facil que dos asientos individuales en cada sociedad.

La metodologia se presenta en forma de jerarquia, en la que se va describiendo de manera profunda cada uno de los pasos de desarrollo de un proyecto Sap, incluyendo acceso a multiple documentación, plantillas (templates), White Papers, Guide Books, Definición de Roles, etc.

Totalmente recomendable para conocer en profundidad todo lo que interviene en un proyecto Sap, viendo como Sap recomienda hacer las cosas (lo podemos comparar con lo que se hace en muchos proyectos en los que hemos participado).

Nuestro truco de hoy habla de la forma de añadir campos de cliente para poderlos utilizarlos en las estrategias de liberación de pedidos de compras. En una entrada anterior del blog hablabamos de la forma de configurar esta funcionalidad en nuestro sistema (Crear estrategias de liberación en pedidos de compras).

Tal y como vimos en dicha entrada, cuando creabamos las características (criterios) que luego ibamos a utilizar en la definición de las estrategias de liberación, utilizabamos la estructura CEKKO que es la que tenemos disponible al crear/modificar los pedidos de compra para obtener información con la que “llenar” las estrategias y decidir que tipo de liberaciones son necesarias.

Puede haber ocasiones en que los campos disponibles no cubren nuestros requerimientos y tenemos que recurrir a la puerta de atras que casi siempre Sap nos deja abierta via ampliaciones o badis. En este caso, la ampliación “M06E0004 – Modif.estructura comunicación p.liberación docs.compras” nos permite personalizar el código Abap para dotar de valor a estos posibles criterios de clasificación adicionales.

Por si no conoceis la forma de activar las ampliaciones, en esta otra entrada del blog hablabamos de la forma de hacerlo.

AMPLIACION DE LA ESTRUCTURA CEKKO.

El primer paso para cubrir nuestra necesidad sera añadir en la estructura nuestros nuevos campos de clasificación. Tener en cuenta que la estructura ya cuenta con varios campos de usuario (USRC1, USRC2, USRN1 y USRN2) que nos podrían valer para este cometido. En caso contrario, con la transacción SE11 añadiremos los campos adicionales utilizando la estructura append CEKKOZZ. Tendremos que registrar la modificación del objeto en el OSS de Sap sino se ha realizado previamente en el sistema. 

Como podemos ver, los campos que hemos añadido a la estructura append ya aparecen en la definición de la CEKKO una vez hemos terminado. En nuestro caso, hemos añadido el campo LAND1 porque vamos a realizar una personalización de las estrategias de liberacion según si el proveedor de la compra es nacional o extranjero. Las compras al extranjero tendrán un esquema de liberación diferente, con un paso de aprobación adicional.

CREACION DEL PROYECTO DE AMPLIACION Y PROGRAMACION PARA LLENAR LA TABLA.

De la forma habitual, crearemos un nuevo proyecto de ampliación con la transacción CMOD y le asignamos la ampliación M06E0004.

A continuación accedemos a los componentes de la ampliación y vemos que utiliza el módulo de función EXIT_SAPLEBND_002 para hacer la llamada a la Exit. Dentro del módulo tenemos el include  ZXM06U22 que tendremos que crear para incluir nuestro código Abap. En este caso, leeremos del maestro de proveedores (tabla LFA1) el pais de este y lo pasaremos a la estructura de salida. Dentro del include tenemos disponibles varias estructuras con información de cabecera y posiciones del pedido, ademas de la misma CEKKO que contiene informacion general del pedido de compras.

Para simplificar luego la gestión de las estrategias de liberación, tendremos el pais ES para las compras nacionales y el pais ficticio OT para indicar cualquier otro país. Esto se podría complicar tanto como se quisiera según area geográficas, zonas, etc.

Activaremos el include y el proyecto de ampliación, y el nuevo campo estara listo para ser incluido en las caracteristicas de la clase para definir las estrategias de liberación.

NOTA IMPORTANTE: en las tablas que tenemos disponibles dentro de la exit podemos acceder de forma detallada a información del pedido:  IT_BEKPO Información de las posiciones, IT_BEKET información de los repartos e IT_EKKNU Información de las imputaciones. De esta ultima tabla leeremos para el caso de que quisieramos leer información de imputación de las posiciones para incluirla en nuestros criterios de clasificación para la liberación (Peps, Centros de coste, Ordenes, etc).

Cuando estemos creando las características para la estrategia de liberación, ya tendremos disponible el nuevo campo que hemos añadido.

Incluiremos la caracteristica en la clase que estemos utilizando y finalmente en los definición de la estrategia de liberación indicaremos los valores correspondientes para que sea necesario un aprobador más o no según el pais de la compra.

Finalmente, al crear los pedidos, el sistema se estara comportando de forma diferente. En la imagen siguiente vemos en la pestaña “Estrategia liberacion” como para un cliente nacional aparece un esquema de liberación. En cambio, para el cliente extranjero (numero 29) aparece una paso de liberación adicional, con la obligación de pasar por el código de aprobador “Z4-Aprob.Importación” antes de poder hacer cualquier tipo de liberación del pedido.

Es un ejemplo sencillo de como podemos personalizar con los criterios mas variados la forma de generar nuestras estrategías de liberación.

Como información adicional os dejo este interesante documento que habla sobre la Exit extraido del SCN de Sap: Release Strategy Enhancement in Purchase Order. Gracias a Zafar A.Valsal por su aportación.

NOTA: si estuvieramos trabajando con estrategias de liberación en Solicitudes de Pedido, hubieramos trabajado con la estructura CEBAN de la misma manera y la ampliación “M06B0005 – Modif.estruct.comunicación p.liberación general solic.pedido”.

Cuando creamos nuestras estrategias de liberación para pedidos de compras, solicitudes de pedido, etc, nos encontramos con un problema (sobre el que he recibido multitud de consultas en el blog): la clasificación que indicamos en cada estrategia de liberación (valores de caracteristicas) no se transporta de forma automatica. Es decir, de toda la parametrización que realizamos para los procedimientos de liberación, se transporta todo excepto esto.

Esto nos obliga a que, una vez realizados los transportes, tenemos que volver a introducir en cada uno de los sistemas los diferentes valores de clasificaciones que tuvieramos. Esto puede llegar a ser tedioso en un sistema con estrategias complejas y con muchos valores de características diferentes. Existe una alternativa que yo no conocia y que nos ha dado a conocer nuestro amigo Milton Fernando Suarez Pulido.

Esta alternativa consiste en utilizar la funcionalidad ALE de Sap (“Application Link Enabling”) que nos permite intercambiar información entre diferentes sistemas Sap de una forma automática utilizando Idoc´s. ALE nos permite intercambiar datos maestros como información de Clientes, Proveedores, Materiales, Registros Info, Centros, Clases de Coste, Cuentas de Mayor, etc . Tambien nos permite enviar documentos, como Pedidos Abiertos,  Libros de Pedidos, Listas de materiales, etc., etc.

Igualmente, también nos permite transportar el sistema de clasificación. En nuestro caso, podremos utilizar la transacción BD93 para enviar toda la configuración de clasificación de las estrategias de liberación de un sistema a otro.

Para nuestro caso, sería tan sencillo como indicar la clase que queremos transportar y la categoria de la clase (siempre indicaremos el valor 032 – Estrategia liber), asi como el sistema lógico destino. Ejecutaremos y el sistema generará los correspondientes Idocs que crearan la información en el sistema destino.

Bueno, en realidad todo no es tan sencillo. La utilización de la tecnología ALE requiere una configuración previa un tanto compleja, que nuestro amigo Milton ha plasmado de maravilla en un documento que nos ha pasado, que comparto con vosotros. Muchas gracias de nuevo por su aportación.

También podeís acceder al documento en este link. Resumiendo, los pasos necesarios y que estan descritos en el manual serían los siguientes:

• Creacion de los sistemas lógicos.
• Asignación de los sistemas lógicos a los mandantes.
• Crear las conexiones RFC para cada mandante.
• Configuración de los puertos ALE.
• Creacion de los acuerdos de Interlocutores (Partners profiles) en cada mandante.
• Creación de los modelos de distribución.
• Generacion de los acuerdos de Interlocutores.
• Distribucion de la vista del modelo a los diferentes sistemas.

En el manual también se incluye la forma de analizar los Idocs que se generan en el momento de la distribución (tanto en el sistema origen como destino), para poder analizar posibles errores en el proceso de distribución.

Hemos solucionado un viejo problema que teniamos pendiente y de paso nos hemos familiarizado con los Idoc´s que serán objeto de estudio en las próximas entradas del blog de una forma amplia.

Si estaís pensando en aprender Abap o en profundizar en uno de tantos componentes o areas de especializacion que este lenguaje dispone (Workflows, Idocs, Smartforms, Sapscripts, Badi´s, Bapi´s, Batch Inputs, Objetos), etc, os recomiendo la visita al blog http://www.abapprogramming.net.

Han elaborado una completa lista de entradas con cursos y explicaciones sobre todos estos topicos:

• ABAP 51 Days Complete Course
• ABAP Dictionary
• OOPS in ABAP
• BDC
• SAP Scripts
• SAP Scripts Controls
• SAP Smart Forms
• Real Time ABAP Programming Reports
• SAP Interview Questions
• Syntax for ABAP Programming
• ABAP Interface Programming
• Financial and Controlling Sample ReportsEDI
• BAPI
• BADI
• ALE IDOC
• SAP Work Flow
• SAP Work Flow in Sales and Distribution
• SAP Work Flow in Material Management
• ERP Overview
• My SAP
• SAP CRM
• ALV SAMPLE CODES
• SAP SCRIPTS COMPLETE
• SAP SCRIPT CONTROLS COMPLETE
• ALE COMPLETE

Si buscais material en Español, pueden resultar interesante para iniciaros el Tutorial de Abap Básico que ha publicado Oscar Arranz en su Blog de Sap. Puede ser una buena opción para empezar:

• Tutorial ABAP básico (I): crear un report
• Tutorial ABAP básico (II): declaración de datos
• Tutorial ABAP básico (III): pantallas de selección
• Tutorial ABAP básico (IV): recuperar datos
• Tutorial ABAP básico (y V): crear un report

Aprovecho para recomendaros su blog, donde se tocan de forma completa aspectos de Sap, customizing y notas tecnicas sobre Abap, BC, SD, FI, CO, MM, PP, PM, PS. Aquí teneís el indice de publicaciones de su Blog.

También Richard Rey ofrece un curso de Abap gratuito en 10 lecciones, con envio de documentación en PDF incluida e información sobre acceso a un sistema Sap IDES gratuito (gracias a la empresa Consolut, de la que ya hemos hablado en el blog en varias ocasiones).

Y si quereis la documentación de los cursos de Sap, la publicamos en una entrada anterior del blog: 

• Manual de Instructor del curso TAW10: Parte 1, Parte 2 y Parte 3. En Ingles, incluye ejercicios prácticos y preguntas de certificación al final de cada unidad.
• Manual de Instructor del curso TAW12: Parte 1 y Parte 2. En Ingles, incluye ejercicios prácticos y preguntas de certificación al final de cada unidad.

En esa entrada también hay información de los examenes para la certificación y preguntas de examen, asi como otra documentación.

Espero que os sea de utilidad todo este material.

Siguiendo en el modulo MM, en nuestro truco de hoy vamos a hablar de una funcionalidad no muy conocida que se encuentra disponible tanto en las solicitudes de pedidos como en los documentos de compras (ofertas, pedidos, pedidos abiertos, plan de entregas, etc.). Se trata de la gestión de versiones. 

Básicamente, la gestión de versiones no permite llevar un historial de las modificaciones realizadas en el documento de compras (independiente del log de modificaciones que tenemos siempre disponible para ver los cambios que se van realizando en los documentos). Una vez activada la funcionalidad, aparece una nueva pestaña a nivel de cabecera, que se llama Versiones.

 Esta pestaña se va llenando con los datos de las versiones del documento teniendo en cuenta lo siguiente.

 1) Cuando creamos, por ejemplo, el pedido, tenemos una versión 0 (inicial), que no se concluye hasta que no se realiza la impresión del mensaje asociado al documento.

2) A partir de ese momento, cualquier modificación posterior del pedido nos obliga a gestionar una nueva versión del documento. Esta nueva versión se crea de forma automática y tenemos disponible en ella una serie de campos de usuario (motivo, texto, solicitante, nº externo, fecha contabilización) que podemos hacer opcionales, obligatorios, ocultos o solo visibles. Estos campos nos pueden informar del motivo de la modificación y aportarnos información adicional del motivo de los cambios.

3) Se pueden añadir nuevas versiones de forma manual, completando los campos que nos informan del origen de las modificaciones. Podemos de esta forma ir concluyendo versiones y creando manualmente nuevas versiones.

4) Una vez realizada una modificación en el pedido y creada una nueva versión, cuando la versión se concluye, automáticamente se genera un nuevo mensaje para el documento y se puede volver a realizar la impresión de este (o el envió mediante email, edi, etc en el caso de que fuera el caso). La próxima modificación del pedido generará una nueva versión del documento automáticamente.

5) En la información de la versión tenemos el valor neto del pedido después de las modificaciones, y la variación con respecto al importe de la anterior versión. 

 6)  Además de la información resumida de las versiones, podemos con la opción visualizar modificaciones ver todos los cambios realizados en un pedido entre una versión y otra, de forma detallada campo por campo (separándonos la información de cabecera, posiciones, etc). 

 Además, cada cambio queda asociado a una versión del documento y se hace sencillo analizar los cambios realizados entre un momento y otro de la vida del documento.

Como podéis ver, una forma útil de ir documentando las modificaciones en los pedidos, además de un registro de los usuarios que van realizando los cambios, todo ello integrado con la gestión de mensajes de los documentos.

 Vamos a ver a continuación la parametrización relacionada con esta funcionalidad.

Activacion de la gestión de versiones.

En la ruta de customizing Gestión de materiales –> Compras –> Gestion de Versiones –> Configurar la gestión de versiones para documento de compras (o SM31, vista V_T16CA). Aquí indicamos por tipo de documento, clase de documento y Organización de compras si queremos activar la gestión de versiones. 

En el detalle de la configuración indicamos los campos que vamos a gestionar en el versionado, indicando si están ocultas, solo visualización, entrada opcional u obligatoria. En nuestro ejemplo, hemos puesto el campo Motivo como obligatorio, el resto opcionales (excepto la fecha de contabilización, que se ha ocultado). 

Parametrización de motivos de modificación.

En la ruta de customizing Gestión de materiales –> Compras –> Gestion de Versiones –> Especificar motivos de modificación ( o SM31, vista V_T16CC). Aquí indicamos los códigos de los motivos de modificación que vamos a poder utilizar en las versiones. 

NOTA: en las solicitudes de pedido se configura la gestión de versiones de forma similar, aunque tiene alguna peculiaridad, como la posibilidad de indicar la lista de campos para los cuales una modificación generará una nueva versión de documento, es decir, los campos que son relevantes para la gestión de versiones.

Podeís acceder a la versión en PDF de este documento aquí.

En las próximas 3 entradas vamos a hablar de la gestión documental en Sap y de las diferentes alternativas que tenemos para añadir nuestros documentos (imagenes, words, pdf, planos, etc) en los diferentes componentes de la aplicación. Por ejemplo, si queremos añadir documentación relativa a un material (imagenes, catalogos en pdf o word, planos en autocad, etc) o un pdf escaneado de una factura de compras al registrarla a través de la verificación de facturas, tendremos varias alternativas disponibles. Dependera del tipo de objeto de negocio tratado las opciones disponibles (no siempre podremos usar las 3 alternativas existentes). En resumen, disponemos de:

• Gos: son los Generic Object Services y nos ofrece funciones como añadir documentos en los objetos (siempre que este disponible el correspondiente icono en la aplicacion donde estemos, tal y como vemos en la imagen siguiente). Ademas nos permite otras opciones como añadir links a los objetos, notas, añadir a lista de favoritos o seguimiento sobre las modificaciones (a traves del Sapoffice, que es la mensajeria interna en Sap). El GOS no requiere una parametrización específica, aunque se pueden personalizar determinadas cosas (como veremos más adelante). Tiene dos grandes inconvenientes: no hay un herramienta de búsqueda para los anexos y por defecto los archivos se almacen en la misma base de datos de Sap (lo que nos puede ocasionar graves problemas de ocupación o rendimiento si se usa de forma masiva). Este ultimo incoveniente se puede solucionar (ver nota oss 530792), pero con efectos laterales sobre el Sap Office.
• Archivelink: a esta opción se accede tambien desde el GOS (lo que Sap llama Archivar Business Document) o bien desde una transacción especifica (la OAAD). En este caso, si necesitamos una parametrización adicional asociada a cada Business Object (objeto de negocio, por ejemplo, pedido de compra, factura, etc). Los documentos se pueden almacenar en la Base de datos de Sap o en un  Content Server (Sap nos ofrece uno gratuito con la licencia, aunque hay alternativas noSap) y si tenemos herramientas de busqueda, como las transacciones OAAD o OAOR. Ademas cada documento enlazado se clasifica por tipo y esta relacionado con cada objeto de negocio en si (por ejemplo, un pedido de compras).
• DMS: es la gestión documental propiamente dicha. Su disponibilidad es mucho más limitada que el GOS o el ArchiveLink (por ejemplo, maestro de materiales, maestro de proveedores o clientes; avisos, ordenes, ubicaciones (modulo PM); posicion de solicitud de pedido o pedido de compras, posicion de documento de ventas, proyectos, etc). Se crea un registro de documento con multitud de información que se vincula a los objetos de la aplicación. Tiene multitud de funcionalidades disponibles como la gestión de aprobación de documentos, gestión de versiones, utilización del sistema de clases para clasificar los documentos, busqueda e indexacion de documentos(Trex), etc. Ademas, dispone de una herramienta Windows (el Easy DMS) que nos permite estructurar en carpetas los documentos que hubieramos anexado.

A continuación vamos a ver en detalle cada una de las tres alternativas de las que hemos hablado, empezando por el GOS.

Utilización del GOS.

La utilización es muy sencilla. Una vez estemos en el objeto Sap donde queremos añadir el añexo, seleccionamos en el control del GOS la opción Crear –> Crear Anexo. Nos aparecerá un dialogo donde podremos seleccionar el documento que queremos anexar.

Podremos añadir todos los documentos que queramos. Para consultar los ficheros anexados, importante, tendremos que estar siempre en el objeto relacionado y mediante la opción del Gos “Lista de Anexos” podremos ver los diferentes ficheros enlazados con la opción de acceder a su contenido.

En el caso de que hubieramos creados notas o enlaces a documentos externos (URL) asociados al objeto, también los veriamos en la opción de lista de anexos.

Parametrización del GOS.

Tenemos tres vistas donde podemos configurar los aspectos mas importantes del GOS.

• Vista SGOSATTR (transaccion SM31): aquí se configuran las opciones disponibles en el gos (incluso podriamos añadir nuevas opciones con la correspondiente programación). En esta tabla se configuran las opciones disponibles, su jerarquia, el icono correspondiente a cada opción y la clase que se utiliza para su gestión.
• Vista SGOSCUST (transaccion SM31): nos permite habilitar/deshabilitar servicios. En el ejemplo de la imagen estamos deshabilitando la opción de crear anexos.
• Vista SGOSSUB (transaccion SM31): nos permite configurar la funcionalidad de las subscripciones a la modificación de objetos. Para el objeto deseado (por ejemplo, BUS2012 para el pedido de compra), según el evento producido en el objeto (modificación, liberación, etc), se puede indicar si la subscripcion está disponible y que texto se enviara a los usuarios subscritos al objeto. Se puede crear textos con variables que se referiran al objeto en tratamiento (ver ejemplo texto SGBT_DEF_SUB, transacción SE61).

Además, para que el GOS aparezca en los pedidos de ventas, necesitamos el parámetro de usuario SD_SWU_ACTIVE con el valor X.

Finalmente, si queremos realizar alguna personalización en el comportamiento estandar del GOS, Sap nos ofrece dos Badis para este cometido.

Nota sobre el lugar de almacenamiento de los objetos: en la nota OSS  530792 se habla del lugar donde se almacen los objetos vinculados con el GOS. Resumiendo los aspectos más importantes que menciona la nota:

• Tecnicamente hablando, los anexos, las notas y los links son tratados en Sap como si fueran documentos del Sapoffice (con sus correspondientes entradas en las tablas SOOD y SOFM).
• Antes de la version 4.6B, el contenido de los anexos se almacenaba en la base de datos en la tabla SOC3.
• A partir de la version 4.6B, en la SOC3 se guarda información de control del anexo, pudiendose decidir si el contenido se almacena en BD o en un gestor de contenido. Si se almacen en BD los datos estarán en la tabla SOFFCONT1.
• Si estamos en version >=4.6B y no queremos almacenar en base de datos, tendremos que configurar un repositorio con la transacción OAC0 del tipo Archivelink, asignarlo a una categoria con la OACT y configurar en la tabla SDOKPHCL para la clase de documento SOFFPHIO, la categoria de almacenamiento (indicando el nombre de la categoria creada). Por defecto, en ese campo aparece el valor SOFFDB (que indica que se archiva en la base de datos). Tambien podemos hacer la asignación con la transacción SKPR08.
• Efecto colateral del cambio: si cambiamos el almacenamiento a un repositorio externo, esta afectando a los anexos del GOS y también a todos los anexos del SapOffice. Esto es importante tenerlo en cuenta antes del cambio por lo que pueda afectar al sistema.

Otros enlaces de interes.

Si quereis ampliar información sobre este tema, os dejo algunos links interesantes:

• Revision del tipo de usuario Sap para que funcione el GOS: gracias a Teknodatips.
• Preguntas frecuentes sobre el GOS en la wiki del SDN de Sap. En esta entrada se tratan los problemas más frecuentes con los que nos podemos encontrar cuando trabajamos con el GOS:
  • 1. The „Generic object services” (GOS) is not available for a user
  • 2. The GOS is not available in an application at all
  • 3. Problem while displaying “Generic object services” or some service is not functioning correctly
  • 4. Authorizations in GOS
  • 5. Service “Store Business Document” is inactive
  • 6. Some attributes of attachments are not displayed in attachment list (title, creator name, time)
  • 7. Performance problem while opening “Generic object services”
  • 8. Where are the documents stored while using “Generic object services”
• Ejemplo de como añadir nuevas opciones en el GOS: gracias a ZEVOLVING (Parte 1 y parte 2).
• Ayuda Online de SAP sobre GOS: ver aquí.
• Ayuda Online de Sap sobre el Eays DMS: https://help.sap.com/easydoc71

Como ya comentamos en la anterior entrada del blog, otra alternativa para anexar documentos en el sistema era utilizar el Archive Link, funcionalidad que esta disponible a través del GOS en la opción “Archivar Business Document”. Lo podriamos considerar una mejora de la función “Crear Anexo”, ya que aquí se realiza de una forma clasificada, disponiendo además de una herramienta de búsqueda sencilla para los objetos anexados (lo que no ocurre con la otra forma de anexar).

La funcionalidad requiere una parametrización especifica por objeto de negocio (por defecto no esta activada) y podemos realizar el archivo de los documentos en la base de datos de Sap o en un Servidor de Contenido.

Utilización del Archive Link.

El anexo de los documentos lo realizamos desde el control del GOS, a través de la opción Crear –> Archivar Business Document (la opción solo estará disponible si previamente se ha configurado para el objeto de negocio, a diferencia de la opción “Crear Anexo” que siempre esta disponible).

A continuación, el sistema nos preguntará la Clase de Documento que queremos anexar. Las clases de documento disponibles las parametrizaremos nosotros (asociadas a un tipo de documento), como un documento lógico que vamos a utilizar para clasificar los diferentes documentos que podemos anexar a los objetos. Por ejemplo, en un pedido de compra, podríamos tener las clases de documento: Oferta del proveedor, Catalogo de materiales, Fotos de materiales, etc. Cada una de estas clases de documento llevaran asociado un tipo de documento: por ejemplo, la oferta del proveedor será un tipo de documento pdf, las fotos de materiales un jpg, etc.

Si estuvieramos trabajando con el objeto de negocio Empleado en el módulo de administración de personal, las clases de documento podrían ser: foto del empleado, contrato de trabajo, material entregado, etc, cada uno de ellos de un tipo de documento concreto (jpg, doc, xls, etc). En esta entrada del blog hablabamos de la forma de cargar las fotos de empleado en el sistema y verlas en la transacción PA20/PA30, contenido relacionado con el que estamos tratando en esta entrada.

Seleccionaremos el archivo asociado a la clase de documento elegida y el fichero quedará anexado al objeto en el que estemos trabajando, un pedido de compra en nuestro ejemplo. Para consultar los documentos anexados accederemos desde el control del GOS a la opción “Listar anexos”. Aquí nos aparecera la lista de todos los objetos creados a través del Gos: Anexos, Notas, Enlaces y Documentos anexados con el archive link.

Tenemos otra alternativa para anexar documentos a los objetos de negocio, a través de la transacción OAAD. Desde esta transacción podemos anexar ficheros o bien realizar la busqueda directa (incluyendo la visualización posterior de los documentos anexados). 

Para anexar, seleccionaremos la opción “Asignar y asignar” y el sistema nos preguntara, el objeto de negocio a utilizar, la clase de documento a anexar y el número del objeto donde estamos vinculando los documentos (en nuestro ejemplo, un número de pedido), abriendo una ventana de navegación para seleccionar los archivos a “subir”.

El “Business Object” es un código que representa al tipo de objeto de la aplicación: por ejemplo, el BUS2012 representa un Pedido de compras, el BUS1001 un Material, el LFB1 un Proveedor, etc. Es fundamental conocer estos códigos tanto para parametrizar la funcionalidad como para su uso desde la transacción OAAD.

Una vez anexados los documentos, tenemos disponible la opción de búsqueda desde la OAAD con la opción “Búsqueda técnica” en la sección Documentos. Desde aquí podemos realizar búsqueda de los documentos anexados en 1 o varios objetos de negocio. Por ejemplo, para el business object BUS2012 Pedido de compra, podriamos poner la lista de documentos de compra para los cuales queremos sacar los documentos anexos.

Nada que ver con la opción de tener que entrar pedido por pedido a ver los anexos. Ademas, tenemos la posibilidad de filtrar la búsqueda por multiples criterios (repositorio, clase de documento, tipo de documento, fecha de archivado, etc). Desde la lista de resultados, esta disponible la navegación a los documentos con un doble click.

Desde la transacción OAOR también se puede realizar la búsqueda de los documentos anexados a un determinado objeto de negocio.

Parametrización del ArchiveLink.

A la parametrización de las opciones del ArchiveLink se accede desde la ruta de customizing Sap NetWeaver –> Servidor de Aplicacion –> Servicios Base –> ArchiveLink –> Customizing de base.

En primer lugar, definiremos el lugar donde se van a almacenar los documentos que anexemos utilizando el ArchiveLink, a través de la opción de custo “Definir Repositorios de Contenido” o con la transacción OAC0. Crearemos si es necesario un repositorio de contenido que siempre tendrá que tener el Ambito de documento “ARCHLINK”, y que luego asociaremos a nuestros objetos de negocio para indicar que el archivado para ellos se realizará en este lugar.

Ademas, con la opción “Tipo de archivo” podremos indicar si los documentos se almacenan fisicamente en la base de datos de Sap o bien en un repositorio de contenido externo (por ejemplo, el content server que Sap proporciona gratuitamente con sus productos y que requiere un servidor adicional para depositar los documentos via HTTP).

A continuación, con la opción  “Tratar tipos documentos” definiremos los tipos de documentos que se pueden anexar (extensiones de fichero) y el tipo MIME asociado, que determinará la aplicación que se utilizará para su visualización. Sap dispone de varios tipos de documento prefijado que cubre los más habituales, aunque es posible que tengamos que definir algunos propios.

El siguiente elemento a configurar serán las “Clases de Documento”, donde definiremos nuestros documentos lógicos asociandolos a un tipo de documento de los definidos en el punto anterior. Para nuestro ejemplo, vamos a definir tres clases de documento, que serán la clase de documento que permitiremos anexar a los pedidos de compra: Oferta del proveedor (del tipo PDF), Catalogo de materiales (del tipo Excel xls), Fotos de materiales.del tipo jpg).

A continuación configuraremos la opción “Tratar enlace” que relaciona el objeto de negocio con las clases de documento y el repositorio de contenido. Para cada objeto de negocio donde vayamos a permitir el enlace de documentos, indicaremos las clases de documento permitidas y el repositorio de documentos donde se va a almacenar (el que creamos en el primer paso de la configuración). En el campo Conexión se indica la tabla donde se van a guardar los enlaces a los documentos (Sap ofrece varias tablas para mejorar el rendimiento del sistema, así como la posibilidad de crear nuestras propias tablas Z de enlace (con la transacción OAC3, siguiendo como modelo la estructura TOAV0).

Una vez completada esta parametrización, la opción “Archivar Business Document” ya debe de aparecer activa en el GOS y las clases de documento configuradas accesibles para anexar ficheros al pedido de compra del tipo correspondiente.

Opciones generales del archivel link.

Existen unas opciones finales de configuración que se acceden desde la ruta de customizing Sap NetWeaver –> Servidor de Aplicacion –> Servicios Base –> Archive Link –> Customizing comunicación frontend.

Los aspectos que podemos configurar son las “Parametrizaciones de archivo y visualizacion”, donde podemos indicar la forma de ver los resultados de búsqueda, opciones de visualización, etc.

Como habeís visto, una opción sencilla de configurar y que ofrece bastante posibilidades, sin llegar a ser un verdadero sistema de gestión documental.

Para terminar la serie, en la próxima entrada hablaremos del DMS y los registros info de documento que nos ofrecen unas funcionalidades mucha más avanzadas en la gestión documental, incluyendo un herramienta Windows (el Easy DMS) y sistemas de búsqueda y clasificación mucho mas potentes.

Para terminar nuestro monografico sobre las funciones básicas de gestión documental que proporciona SAP, vamos a hablar de los registros info de documento (DMS) y de las funcionalidades y herramientas que nos proporciona Sap. Algunas de las características son:

• Gestión de aprobación de documentos con diferentes status (incluyendo posibilidad de Workflow).
• Gestión de versiones.
• Utilización del sistema de clases para clasificar los documentos con criterios propios.
• Busqueda de documentos por criterios multiples: clase de documento, descripción, texto, valores de características de clasificación, por enlaces a objetos de negocio, etc.
• Si tenemos montada la indexacion de documentos (servidor Trex), podriamos buscar dentro del contenido de los documentos anexados.
• Gestion de documentos via Web (utilizando BSP).
• Sap Easy DMS: herramienta windows tipo explorador que nos permite crear, modificar y visualizar los documentos, clasificarlos, anexar a objetos Sap. Incluye funciones drag and drop, busqueda de documentos y la posibilidad de ordenar los documentos en carpetas (cada carpeta tambien se crea en Sap como un registro info de documento sin anexos).
• Los documentos se pueden almacenar en un repositorio tipo DMS (que puede ubicarse en la base de datos de Sap o en un Content Server  externo (el de Sap u otro fabricante)) o bien en carpetas a nivel de sistema de ficheros u otros sistemas de almacenamiento externo.
• Los documentos pueden estar almacenados de forma independiente en el sistema o vinculados a objetos de negocio (la cantidad de objetos disponible es mucho menor que para el ArchiveLink).
• En los objetos de negocio previstos tenemos dentro de las aplicaciones la funcionalidad para ver los registros info de documento asociados. Por ejemplo, para el maestro de materiales tenemos en Datos adicionales la pestaña Datos de documento dondre podriamos ver todos los documentos relacionados.
• Otras funcionalidades: jerarquía de documentos para relacionar varios registros de forma jerarquica, distribución, etc.

Como podeis ver, una funcionalidad mas completa y versatil que la que nos ofrecian los anexos del GOS o el Archivelink.

Utilización de DMS. Creación de documentos.

Los Registros Info de Documento (DIR) se pueden crear directamente con una transacción especifica, la CV01N (CV02N para modificar y CV03N para visualizar).

Trabajamos con clases de documento (que previamente habremos parametrizado). Al crear un registro info de documento, le indicamos una descripción, información de status, responsable, etc (hay diferentes campos disponibles, para los cuales se puede configurar su disponibilidad, obligatoriedad o no, etc)  así como los anexos a los documentos originales asociados. Ademas, si para la clase de documento hemos indicado una clase asociada, podremos indicar los valores de característica que clasifican al documento así como el enlace a objetos de negocio Sap (también se parametriza por clase de documento a que objetos podemos vincular). En nuestro ejemplo, al maestro de materiales.

Con el status del documento podemos gestionar un sistema de aprobación de los documentos (incluyendo un Workflow), impidiendo igualmente si es necesario la modificación de los documentos una vez aprobados.

Si se ha parametrizado a nivel de clase de documento, también se pueden crear los registros info de documento desde las transacciones asociadas a los objetos de negocio. Por ejemplo, para el maestro de materiales, lo podremos hacer desde la sección Datos Adicionales, pestaña Datos de Documento en la transacción MM01/MM02.

Además, en este lugar podremos ver todos los documentos que se han creado en el sistema (desde cualquier fuente) asociados al objeto de negocio material. Desde este lugar se puede acceder a la modificación/consulta de los documentos ya creados o a crear nuevos registros.

La tercera alternativa para crear o modificar documentos sería la utilización de las herramientas externas: la via Web (que no vamos a ver) y el Easy DMS. Como indicamos antes, el Easy DMS es una herramienta que proporciona Sap y que nos permite, en un entorno Windows, similar al Explorer, realizar la gestión de los documentos.

En nuestro ejemplo, hemos creado una estructura de carpetas (es una de las ventajas de la herramienta) para diferencias los diferentes documentos que vamos a anexar. Al crear las carpetas también se crea un registro info de documento para cada una de ellas (sin anexos).

Desde el Easy DMS podemos crear o modificar los documentos, en un entorno visual totalmente conectado con Sap, donde se nos pedirá toda la información relevante según la parametrización de la clase de documento que estemos utilizando. Igualmente, para datos que requieran una lista de valores o para el enlace con los objetos de negocio de Sap, tenemos disponibles las ayudas de búsqueda que leen en la base de datos de Sap.

Esta herramienta es mucho más versatil que la transacción CV01N/CV02N y permite realizar la gestión documental de una forma mucho más intuitiva.

Utilización de DMS. Búsqueda de documentos.

Para buscar en los documentos desde Sap podemos utilizar la transaccion CV04N, la cual nos permite restringir la selección por todos los criterios asociados al documento: número, descripcion, status, características de clasificación, enlace de objets. etc.

Los resultados se visualizan en forma de lista (tambien se pueden ver en forma de mosaico), pudiendo acceder desde aquí a visualizar tanto el contenido de los registros info de documento como los documentos anexados propiamente dichos.

Si hubiesemos tenido instalado un servidor Trex con indexación de documentos tendriamos activa en esta transacción la búsqueda por texto completo dentro de los documentos.

También podriamos realizar la búsqueda de documentos via Web o desde la herramienta Easy DMS, que también tiene habilitadas las funciones de búsqueda.

Una vez ejecutada la búsqueda, el sistema nos devuelve la lista de documentos que cumplen las condiciones (no necesariamente creados con el Easy DMS), sino que también nos aparecen los documentos creados directamente desde Sap.

Desde los resultados de búsqueda podemos acceder a las propiedades del registro info de documento y también a visualizar los anexos (si el estado del documento lo permite también podriamos editar su contenido y generar una nueva versión del documento).

Parametrización del DMS.

Los aspectos más relevantes de la parametrización de las funcionalidades vistas son:

• Creación del repositorio de contenido (transacción OAC0), que siempre tendrá que ser del tipo DMS. Para el caso de que vayamos a realizar archivado a nivel de sistema de ficheros, no será necesario disponer de un repositorio. Este repositorio podrá estar en la base de datos de Sap o en un Content Server externo.
• Creación de categoria de archivo (transacción OACT): para poder utilizar el repositorio creado en el punto anterior, es necesario vincularlo a una categoria de archivo, que crearemos en este punto de parametrización. Siempre del ámbito de documento DMS.
• Configuración de las clases de documento: es la parte más importante de la parametrización en el sistema documental. Se accede desde la ruta de customizing Componentes multiaplicaciones –> Gestion de documentos –> Datos de control –> Definir clases de documento. 

Aquí definiremos los diferentes status que tenemos disponibles según la clase de documento (y como la secuencia entre cada uno de elos y atributos que personalizan el comportamiento de los documentos).

Igualmente definiremos el enlace de objetos permitidos a la clase de documento y si permitimos crear documentos solo desde la CV01N o también desde las transacciones asociados al objeto de negocio (como vemos en la imagen, el valor 1 en crear documento nos lo permite, el valor 2 solo desde la CV01N).

En la configuración de la clase de documento le indicaremos el rango de números a utilizar (también habrá que parametrizarlo), si el archivo es Kpro o no. Igualmente, definiremos si utilizamos una clase para la clasificación de los documentos, campos disponibles en la información del documento (con opciones de ocultarlos, hacerlos obligatorios u opcionales, etc), etc.

• Definir aplicación para la estación de trabajo: en la ruta de customizing Componentes multiaplicaciones –> Gestion de documentos –> Datos generales –>Definir aplicacion para la estacion de trabajo. Aquí definimos las extensiones para los documentos que vamos a poder utilizar y las aplicaciones relacionadas para su visualización/modificación.

En el caso de no archivar los documentos anexados en el Content Server y realizarlo a nivel de sistema de ficheros, tendremos que configurar los soportes de datos en la ruta de parametrización Componentes multiaplicaciones –> Datos generales –> Definir soporte de datos.

Nota importante: en el archive link habia una vinculación directa con el lugar donde se almacenaban fisicamente los documentos a traves de la asociación Objeto de negocio, clase de documento y repositorio de contenido.

En el DMS esta vinculación no existe de forma directa y se indica al anexar los documentos con la categoria de archivo (si estamos en el Easy DMS, si la clase de documento es KP nos mostrara las categorias de archivo del ambito de documento DMS; si no es KP, nos mostrara los soportes de datos definidos; si estamos en la CV01N, nosotros seleccionaremos la categoria de archivado o el soporte de datos). Es importante tener esto en cuenta. Si se pueden configurar valores propuestos en los Perfiles de gestión de docuentos (Datos generales –> Definir perfil) o en valores predeterminados en el Easy DMS. Esto es uno de los temas más confusos de la parametrización del DMS, y hay que revisarlo con detenimiento y entender bien para su correcta utilización.

La parametrización mostrada en esta entrada esta descrita de forma general y no detallada, teniendo disponibles otras configuraciones adicionales que tendremos que tener en cuenta según el tipo de archivado documental que vamos a realizar.

Para concluir, podemos indicar que la funcionalidad esta disponible para enlazar los objetos de negocio más habituales como por ejemplo:

• Activos fijos: inmovilizado (objeto ANLA).
• Posicion de solicitud de pedido de compras (objeto EBAN).
• Posicion de pedido de compras (objeto EKPO).
• Maestro de equipos (objeto EQUI).
• Ubicaciones técnicas de mantenimiento (objeto IFLOT).
• Puntos de medida de mantenimiento (objeto IMPTT).
• Cliente (objeto KNA1).
• Proveedor (objeto LFA1).
• Maestro de materiales (objeto MARA).
• Unidad organizativa (objeto NORG).
• Aviso mantenimiento (objeto PMQMEL).
• Listas de materiales (cabecera: objeto STKO_DOC, posiciones: STPO_DOC).
• Elementos Pep (objeto PRPS).
• Etc, etc.

En mi experiencia en proyectos lo he visto utilizar sobre todo en la gestión del módulo de mantenimiento, para añadir documentación de ubicaciones, equipos, avisos, etc o en el módulo de gestión de calidad (QM). Igualmente, en los documentos de compras para anexar especificaciones de la compras de determinados materiales, equipos o servicios.

Documentación adicional: Manual de Instalacion del Content Server que Sap proporciona de forma gratuita (requiere un servidor adicional, con servidor Internet activado): Content_Server_Win_640. Lo utilizaremos en el caso de que no queramos almacenar los documentos en base de datos o a nivel de sistema de ficheros, y si en un servidor de repositorio externo (existen otros productos de fabricantes distintos  a Sap). Si necesitais descargaros el software, desde el http://service.sap.com/swdc, buscando a continuación Content Server (Sap proporciona la licencia gratuita, incluyendo la base de datos MaxDB).

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.

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:

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.

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.

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.