Manuales de LSMW.


Comparto con vosotros algunos enlaces interesantes sobre la herramienta LSMW. Como ya sabeís, Sap nos proporciona esta herramienta para los procesos de cargas iniciales de datos en un proyecto de implantación de Sap, aunque se puede utilizar también para migración de datos, interfases con otros sistemas, etc.

La herramienta nos permite utilizar varías técnicas para la carga de datos, como la tradicional del Batch Input, Direct Input, Bapis o Idocs, utilizando un procedimiento guiado donde Sap nos va marcando todos los pasos necesarios en cada metodo para realizar los procesos de carga de datos.

En su día, vimos un ejemplo práctico de utilización de la herramienta LSMW para realizar la carga del maestro del proveedores a partir de un fichero de texto:

http://saptricks.wordpress.com/2011/02/27/utilizando-lsmw-legacy-para-carga-el-maestro-de-proveedores/

En la siguiente entrada en scribd teneis un tutorial de la herramienta:

El documento de la presentación es accesible en este link 55577068-Step-by-Step-Lsmw-Tutorial[1]

Páginas de la SCN de Sap donde se habla sobre la herramienta LSMW:

http://wiki.sdn.sap.com/wiki/display/ABAP/LSMW

http://scn.sap.com/docs/DOC-26159

Otros Tutoriales con ejemplos sobre LSMW:

http://blogdefloren.files.wordpress.com/2009/03/manual-lsmw-blogdefloren.pdf

http://www.sap-topjobs.com/LSMW.pdf

http://de.slideshare.net/arun_bala1/sap-sd-lsmw-legacy-system-migrationworkbench

http://www.slashdocs.com/ntpsru/lsmw-steps.html

Vídeos sobre la herramienta:

Espero que os sea de utilidad todo este material. Nos vemos a la vuelta de mi vacaciones a mitad de septiembre.

Publicado en Formacion, Sap Basis | Etiquetado | 1 Comentario

Truco 56.Costes indirectos planificados en compras que no afectan a la cuenta de existencias.


Este es un tema sobre el que he recibido múltiples consultas en el blog. En la configuración estándar de las clases de condición para los costes indirectos planificados de adquisición en los procesos de compra del Modulo MM (por ejemplo, las condiciones para gastos de transporte como FRA1, FRA2, FRB1, FRB1, FRC1, FRC2; gastos de aduana, etc), estos costes se añaden como más valor en la cuenta de existencias de los materiales.

Costes_transporte1

Esto esta bien, pues nos permite incluir en la valoración de los materiales aquellos elementos que no son solamente el precio de la compra, y podemos incluir otros importes provenientes de gastos de transporte, tasas, aduanas, gastos de seguros, etc.

Pero en algunos tipos de negocio, todos estos costes no se han de considerar como valor de las existencias (debido a que los gastos serán reembolsables, por temas legales específicos de algún país o por criterios contables). En este caso, estos gastos tendrán que ser contabilizados en una cuenta contable diferente para poder realizar otro tipo de tratamiento.

Para solucionar este problema, hemos de crear nuevas clases de condición, modificando los parámetros de control de ellas para obtener el comportamiento deseado del sistema. Los pasos son los siguientes:

1. Crear una nueva clase de condición, como copia de las estándar (por ejemplo FRA1, FRB1, FRC1, etc), desde la transacción M/06 o ruta de customizing Gestión de materiales –> Compras –> Condiciones –> Fijar determinación del precio –> Fijar clases de condición –> Definir clase de condición.

Costes_transporte2

Importante: indicar en tipo de condición el valor blanco y y en el signo el valor X Negativo.

2. Creación de una nueva operación para la determinación de cuentas: desde la vista V_T687, aplicación “M” Compras (transacción SM31) o bien desde la ruta Gestión de materiales –> Compras –> Condiciones –> Fijar determinación del precio –> Fijar clave de operación –> Clave de operación (también accesible desde la transacción OLME).

Costes_transporte3

3. Asignar la nueva clase de condición al esquema de cálculo: con la transacción M/08 o la ruta de customizing Gestión de materiales –> Compras –> Condiciones –> Fijar determinación del precio –> Fijar esquema de cálculo. La incluiremos en la misma sección del esquema de cálculo que utilicemos donde están el resto de condiciones de costes indirectos planificados (fletes).

Costes_transporte4

Importante: en la clave de operación de la clase de condición (columna Delim), asignar la nueva operación creada en el paso anterior (en este caso, la ZR1).

4. Configuración de la determinación de cuentas para la nueva operación: con la transacción OBYC, realizaremos la asignación de cuentas para la nueva clave de operación. Aquí indicaremos la cuenta contable diferente donde queremos llevar los gastos de transporte.

Cuentas

Importante: antes de indicar las cuentas, configurar las normas (según los criterios que queramos utilizar para la determinación de la cuenta: agrupador de áreas de valoración, categorias de valoracion, D/H, etc). Igualmente, definir las claves de contabilización que se utilizarán para los asientos (40/50).

En principio, con esta configuración todo esta preparado para que el sistema se comporte de la forma deseada por nosotros. Vamos a ver un ejemplo de un pedido de compras utilizando esta clase de condición para verificar que la parametrización ha sido correcta.

Costes_transporte6

En el nuevo pedido utilizamos la clase de condición creada (ZFR1) y la clase de condición original (FRA1). Con la combinación de las dos vamos a conseguir realizar el juego contable deseado.

NOTA: SE HAN DE INTRODUCIR LAS DOS CONDICIONES (HACER EL JUEGO CON LAS DOS) PARA CONSEGUIR EL RESULTADO DESEADO. NO BASTA CON UTILIZAR SOLO LA CLASE DE CONDICION CREADA. ESTO ES TANTO VALIDO PARA COMPRAS A STOCK COMO PARA COMPRAS IMPUTADAS. EN ESTE ULTIMO CASO, EL FLETE SE LLEVARA A OTRA CUENTA DIFERENTE DE LA DEL GASTO DE MATERIAL.

A continuación, realizamos la entrada de mercancía del pedido. Podemos observar el apunte contable que se ha generado en el sistema al realizar la EM con la transacción MIGO:

Costes_transporte7

Podemos observar que en la cuenta de existencias (cuenta 301000) no hay ningún reflejo del gasto de transporte. Por otro lado, en la cuenta que hemos parametrizado para la clave de operación ZR1, nos aparece el importe del gasto (en rojo). En la parte marcada en naranja en el asiento, podemos ver las cuentas de la clave de operación FRE (generadas por el juego de las clases de condición FRA1 y ZFR1) se compensan entre si. Por otro lado, la cuenta de facturas pendientes de recibir para los portes refleja el importe de estos.

Cuando recibamos la factura, el asiento generado será el siguiente (en este caso hemos supuesto que el proveedor del transporte es el mismo que el de la mercancía). En caso contrario, haremos la contabilización en dos movimientos pero con el mismo resultado contable. Su aspecto es:

Costes_transporte8

Se compensan las cuentas de EM/RM de la mercancía y del transporte, y se lleva la deuda a la cuenta del proveedor.

Conclusión.

Con este método hemos conseguido nuestro propósito de separar los costes indirectos planificados de adquisición de la valoración del material, contabilizándolos en una cuenta contable diferente, separándolo del importe de las cuentas de existencias del material.

La alternativa no es un método directo y nos obliga a indicar las dos clases de condición en el pedido (siempre habrá que hacer ese juego). Pero el resultado contable es el deseado y nos puede valer para aquellas excepciones donde tenga que realizarse esta separación.

Bibliografía: entrada original publicada por Raja Ramasamy en el SCN de Sap http://wiki.sdn.sap.com/wiki/display/ERPLO/Posting+planned+delivery+cost+to+Non-inventory+account

Publicado en Formacion, SAP MM | Etiquetado , , | 10 comentarios

Truco 55.Pedido de compra automático desde SD.Pedido a Terceros.


Tenemos otra alternativa a la vista en nuestro anterior Post  para crear automáticamente un pedido de compra desde ventas. Es lo que llamamos Pedido a Terceros. A partir del pedido de venta se creará la solicitud de pedido de compra, pero en este caso, la entrega de la mercancia al cliente la gestionará directamente el proveedor y la mercancia no pasará por nuestras instalaciones.

terceros1

El pedido a terceros tiene alguna peculiaridad a nivel de SD que conviene destacar: no hay entrega en SD ni picking (realmente todo eso lo esta gestionando por nosotros nuestro proveedor). Además, el pedido de venta no se podrá facturar hasta que no se reciba la factura del proveedor y se registre en el sistema (esto se puede cambiar en la parametrización).

Grupo de Tipos de Posición BANS.

En el estandar existe un grupo de tipos de posición llamado BANS – Posición terceros, que incluye en su parametrización el tipo de posición TAS – Posición pedido a terceros.

terceros2

Al igual que con el tipo de posición TAB, con el tipo de posición TAS el sistema nos creará automáticamente la correspondiente solicitud de pedido en el módulo de compras, pero con unas características especiales:

  • Tipo de posición I: pedido a terceros.
  • Tipo de imputación X: todas las imputaciones. En los datos de imputación se relacionara el pedido de venta y la posición que origina la solicitud.
  • Dirección de Entrega: se indica en esa información los datos del cliente, ya que será realmente a ellos a quien nuestro proveedor entregue la mercancia.

Podemos consultar el número de la solicitud de pedido creada  en la pestaña repartos del pedido de venta. La solicitud de pedido será convertida a pedido de forma manual de la manera habitual (también, como ya indicamos, se podría haber convertido  de forma automática en el caso de tener una fuente de aprovisionamiento definidad, y tener el proveedor y el material marcados en sus datos maestros con el indicador de Pedido Automático).

Una vez creado el pedido de compra, la referencia aparecera en el flujo de documentos del pedido de venta. Si intentamos crear la entrega sobre el pedido, el sistema nos informará que no hay posiciones relevantes. Y si intentamos facturar el sistema tampoco nos dejará y nos indicará que “Ninguna cantidad pendiente de factura determinada”.

terceros4

El ciclo de la compra continuará de la forma habitual (podremos registrar o no la entrada de mercancía del pedido, aunque realmente no entrará ningún stock en el almacén, solo será un reflejo del gasto y el registro de la factura pendiente de recibir). Sino hacemos entrada de mercancía (desmarcando el flag VerFactEM a nivel de posición en la pestaña Entrega), toda la contabilización se realizará al registrar la factura.

Una vez registrada la factura de compras, las posiciones del pedido de venta ya serán facturables y podremos crear de la forma habitual la correspondiente factura para enviar al cliente (VF01 o VF04 para hacerlo masivamente desde el Pool de facturación).terceros5

Si nos vamos al flujo de documentos de nuestro pedido de ventas, veremos que no hay rastro ni de entrega, ni del picking ni del correspondiente movimiento de mercancia. Toda esta gestión la habrá realizado el proveedor por nosotros.

terceros6

Es una funcionalidad interesante aunque con algunas limitaciones. Al realizarse el flujo de mercancias por un tercero, perdemos un poco el control (podriamos utilizar las confirmaciones de pedido para tener más información de las operaciones que va realizando el proveedor).

Igualmente, hay un report estandar (el SDMFSTRP), que se utiliza para la supervisión de cantidades en operaciones con terceros.

Publicado en Formacion, SAP MM, Sap SD | Etiquetado | 2 comentarios

Truco 54.Pedido de compra automático desde SD.


En ocasiones, necesitaremos generar automáticamente, a partir de cada pedido de venta, el correpondiente pedido de compra para gestionar el aprovisionamiento de ese stock para poder servir a nuestro cliente. Podriamos haber utilizado la Planificación de Necesidades para que el sistema determinará la necesidad de la compra y nos generase las correspondientes PR al lanzar el MRP según el metodo de planificación seleccionado, pero existen otras alternativas.

Grupo de Tipos de Posición BANC.

En el estandar existe un grupo de tipos de posición llamado BANC – Pedido Invidual, que incluye en su parametrización el tipo de posición TAB – Pedido compras individual.

mm_desde_sd

Este tipo de posición nos permite utilizar una funcionalidad muy interesante de Sap. Al crear el pedido de venta, si la posición del pedido tiene este tipo de posición, automaticamente el sistema va a tratar de crear la correspondiente Solicitud de Pedido en el módulo MM. De hecho, nos pedirá despues de cada posición información adicional para completar todos los datos necesarios para este cometido (en los datos de entrega de cada posicion).

mm_desde_sd2

Una vez completado el pedido de venta, cuando lo grabamos, Sap en un proceso paralelo nos habrá creado la solicitud de pedido. Incluso, si cambiamos el pedido de venta posteriormente (antes de convertir la solped a pedido), la solicitud de pedido asociada se actualizara con la información modificada. Si nos vamos al módulo de Compras, podremos localizar la Solped creada con una característica especial. Las posiciones de esta tienen el tipo de imputación M – IndivClte s/CO PdClt. Y el objeto de imputación es el documento de venta y la posición que da origen al documento.

mm_desde_sd3

En este caso, gestionaremos la solicitud de pedido para gestionarla de la forma habitual para asignarle proveedor y convertirla a pedido manualmente (también se podria haber creado el pedido automáticamente en el caso de tener una fuente de aprovisionamiento definida, y tener el proveedor y el material marcados en sus datos maestros el indicador de Pedido automático).

Una vez creado el pedido de compra, si volvemos a consultar nuestro pedido de venta, podremos ver en su flujo de documentos que nos aparece el número de documento de compras y ambos documentos quedan ligados de forma univoca.

mm_desde_sd4 

Ademas, Sap no nos dejará modificar la cantidad del pedido de venta, a no ser que añadamos un nuevo reparto y creemos sobre el una nueva solicitud de pedido para las cantidades adicionales.  El pedido de compras será gestionado de la forma habitual, y cuando se reciba la mercancia, observaremos al consultar los stocks (transacción MMBE o MB52), que las cantidades recibidas han sido llevadas a un stock especial llamado Stock de pedido para cliente.

mm_desde_sd5

Este stock tiene la clave de Stock especial E y el stock individual esta siempre relacionado con el pedido de venta original. Podremos en todo momento controlar si tenemos el stock disponible, estará reservado para ser usado en el pedido y una vez recibida la mercancia, se podrá gestionar la entrega al cliente de la forma prevista y su posterior facturación.

mm_desde_sd6

Por otro lado, el proceso de recepción de factura de compras seguira su flujo, no restringiendo para nada las operaciones que se hagan en el pedido de venta a nivel de suministro y facturación al cliente. Además, el stock especial E podrá ser gestionado en gestión de stocks y realizarse operaciones sobre el: mermas, inventario, etc, aunque siempre identificando cada cantidad concreta que esta asociada a cada pedido de venta y a cada posicion/entrega de el.

mm_desde_sd7

Existe ademas una forma similar de gestionar esta funcionalidad que es el pedido a terceros. En ese caso, la entrega directa al cliente la gestionará directamente nuestro proveedor y el stock no pasará por nuestras instalaciones. Lo veremos en la próxima entrada.

Publicado en Formacion, SAP MM, Sap SD | Etiquetado , , , | 1 Comentario

Truco 53. Debug en ventanas popup.


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

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

debug1

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

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

debug2

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

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

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

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

debug3

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

Publicado en Abap, Formacion | Etiquetado , | 5 comentarios

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


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

ob52_1

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

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

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

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

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

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

ob52_2

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

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

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

ob52_5

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

Publicado en Autorizaciones, Sap FI | 23 comentarios

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


Continuando con el tema de las autorizaciones de las que hablamos en nuestros dos anteriores posts del blog, hoy veremos el Sistema de Información de Usuarios. Para la gestión de autorizaciones es fundamental conocer el Sistema de Información de usuarios (se accede desde la transacción SUIM). Con una gran variedad de herramientas, nos permite realizar análisis relacionados con las autorizaciones asignadas a los usuarios en sus datos maestros, roles, perfiles de autorización y objetos. suim1

La ejecución de los reports se realiza seleccionando el icono ejecutar.

Algunos de los informes más interesantes son:

  •  Usuario –> Según fecha de alta y modificación clave de acceso: resumen de los usuarios del sistema, ultima entrada al sistema, estado de la clave de acceso, bloqueo, etc. suim2
  • Usuario –> Con autorizaciones críticas: para detectar usuarios con autorizaciones criticas (por ejemplo, usuarios que pueden modificar el maestro de usuario, jobs, etc). Podremos crear nuestras combinaciones críticas de autorizaciones para ejecutar el informe con esa variante y el informe nos devuelva los usuarios que tienen en sus autorizaciones esa combinación de autorizaciones (en forma de semáforos con colores según la criticidad que otorgamos a cada tipo de autorización). suim3
  •  Roles –> Roles por criterios de selección complejos: es la transacción “principal” para obtener información de los roles. Podemos buscar los roles por nombre, por usuario a los que están asignados, por transacciones incluidas en el menú del Rol, por valores en los campos de  los objetos de autorización, por perfiles de autorización asignados al rol, etc. Nos va a permitir localizar por casi cualquier criterio un rol. suim4

Se suele utilizar para localizar roles que incluyen una determinada autorización. Por ejemplo, si queremos localizar en que roles esta el objeto de autorización F_KNA1_AEN, lo indicaremos en la parte sección “Selección según valores de autorización”. suim5

Además, al indicar el objeto de autorización, a continuación nos aparecen los campos de autorización que lleva asociados (podremos indicar también valores a buscar en el contenido de estos campos o con “*” la autorización global a todos los posibles valores). Al ejecutar el informe, se nos devolverá la lista de roles que incluyen el objeto (con los valores en los campos que coincidan si los hubiéramos incluido).

  •  Transacciones –> Transacciones ejecutables: nos permite analizar las transacciones que puede ejecutar un usuario con sus autorizaciones actuales, las transacciones que se pueden ejecutar con un rol determinado, etc. Es un mecanismo rápido para ver que puede ejecutar un usuario o un role si entrar al mantenimiento de roles. suim6
  •  Comparaciones –> De usuarios: nos permite comparar los objetos de autorización asignados a dos usuarios. Muy útil para cuando tenemos un usuario al que le faltan autorizaciones y queremos, en comparación con otro que si tiene los accesos, saber donde radican las diferencias. suim7

Entrando al detalle podemos ver incluso los valores de los campos de autorización y desde que perfil de autorización se están heredando al usuario (como vemos en la imagen a continuación). Tener en cuenta que en el detalle se muestra los perfiles de autorización asociados al Rol (lo que se indica como autorización). suim8

  •  Comparaciones –> De roles: similar al anterior, en este caso nos permite comparar las autorizaciones de dos roles, objeto por objeto. Es una forma sencilla de comparar que objetos están en un rol y no en el otro. Igualmente, entrando al detalle podemos ver los valores de los campos de autorización. suim9
  •  Referencia de utilización –> Roles –> En usuarios: nos permite visualizar los usuarios que están asignados a los roles. suim10

Pulsando el botón “ROLES” podemos ver de forma detallada toda la asignación de roles al usuario, con información detallada si el rol es simple o compuesto, si la asignación es directa (al usuario) o indirecta a través del módulo de organización de Sap, fechas de validez, etc. suim11

Pulsando el botón “PERFILES” podemos ver cada uno de los perfiles asociados a los usuarios que cumplen los criterios de selección del report.suim12

En la proxima entrada del Blog, y para concluir el tema de autorizaciones, veremos la forma de crear nuestras propias variantes para analisis de autorizaciones críticas. Nos puede ser útil, en instalaciones muy grandes y con muchos usuarios, para evitar que nunca se den determinadas combinaciones de autorizaciones y para facilitar la labor en Auditorias de Seguridad (por mi experiencia muchas auditorias contables ya incluyen incluso auditorias de usuarios en Sap).

Publicado en Autorizaciones, Sap Basis | 14 comentarios

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


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

pposw_uso3

  • 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.pposw_uso1

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

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

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

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”. pfud1

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

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”.pfud8

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

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.pposw_custo1
  • 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).pposw_custo3
  • 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.pposw_custo4

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.

Publicado en Autorizaciones, Sap Basis | 3 comentarios

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


En nuestro dos próximos trucos volvemos al modulo Basis para hablar de una funcionalidad no demasiado conocida pero que puede ser muy útil si queremos utilizar el modulo de Organización para construir la estructura de puestos de trabajo de nuestra organización (desde el punto de vista de RRHH o también desde el punto de vista de uso o funciones en Sap). Cada unidad organizativa y/o puesto de trabajo tendrá asociadas las diferentes autorizaciones en el sistema, de forma que cuando un empleado/usuario sea asignado en los diferentes puestos/roles en el arbol organizativo, automáticamente en su perfil de usuario Sap se asignarán todas las autorizaciones vinculadas para que pueda desempeñar las funciones previstas.

De esta forma se realiza una gestión de las autorizaciones mucho más ordenada. Utilizando el arból organizativo de las transacciones del modulo de organización (PPOMW/PPOSW), podemos ver de forma visual nuestra estructura y quién esta asignado en cada lugar (asi como los roles de autorización asignados). Como os digo, puede ser una funcionalidad muy interesante para poner un poco de “orden” en el laberinto en el que se suele convertir la gestión de autorizaciones en Sap conforme los proyectos van evolucionando.ppome1

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

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

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

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

Dentro de la programación de las aplicaciones SAP, con la sentencia “AUTHORITY-CHECK” verificaremos que el usuario dispone de la autorización correspondiente y le dejaremos continuar o no con la acción a realizar (en caso de informes podremos estar restringiendo también la información a mostrar). En el estandar Sap lo hace de forma automática, aunque este procedimiento lo podremos incluir también en nuestros desarrollos Z.

* Verificacion de autorizacion para crear pedidos de venta
                       AUTHORITY-CHECK OBJECT ‘V_VBAK_AAT’
                                ID ‘AUART’ FIELD VBAK-AUART
                                ID ‘ACTVT’ FIELD ’01′.
                       IF SY-SUBRC ne 0.
                          message e008(ZSISTEMAS) with ‘SIN AUTORIZACION PARA CLASE DOC’.
                       ENDIF.

Como podeís ver, al final se acaba chequeando cada objeto de autorización concreto y los valores de este. Si el usuario tiene asignada la autorización requerida, puede llevar a cabo la acción. En caso contrario, se genera un mensaje de error o simplemente no tiene acceso a la visualización de los objetos involucrados.

Hay objetos de autorización para casi todo en Sap, desde el acceso a ejecutar transacciones que veiamos antes (TCODE), objetos para modificar datos maestros en los diferentes ambitos (general, centro, sociedad, organización de ventas, sociedad CO, organización de compras, etc). También hay objetos de autorización para las funciones básicas del sistema. De esta forma, casi cualquier operación sobre el sistema, siempre se podrá permitir o no (con la ausencia de la autorización).

Perfiles de autorización.

En versiones anteriores no existia el concepto de roles y se trabajaba con los perfiles de autorización. Estos no eran mas que un conjunto de objetos de autorización con sus correspondientes valores que se asignaban a los usuarios en la transacción SU01/SU10. En versiones mas recientes se  introdujo un concepto mucho mas potente, el de los roles (aunque realmente por detras siempre siguen estando los perfiles de autorización). Los roles se gestionan desde la transaccion PFGC y tiene un generador automatico de perfiles de autorización que veremos a continuación, que facilitan la utilizacion de los objetos de autorización.

Sino queremos trabajar con los roles, siempre podemos definir los perfiles de autorización con la transacción SU02 (opción que no os recomiendo en absoluto).perfiles

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.pfcg_menu
  • 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:pfcg_menu2
  • 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).pfcg_perfil

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

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

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

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

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

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

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.

Publicado en Autorizaciones, Sap Basis | 16 comentarios

Truco 48. Liberación en pedidos de ventas.


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

  • Utilizar el “Bloqueo de entrega” o el “Bloqueo de factura” para impedir que los pedidos se puedan servir o facturar. Este método no es muy efectivo, ya que cualquier usuario que tenga acceso a la transacción VA02 va a poder quitar el bloqueo. Podriamos quitar la autorización a la transacción, pero no es practico pues los vendedores o administrativos seguro que tendran que poder modificar otras cosas de los pedidos.lib_ventas1
  • 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.lib_ventas2

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):lib_pvta1

  • 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”.lib_pvta2

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

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

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

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”.lib_pvta6

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:lib_pvta7

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

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

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

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.lib_pvta11
  • 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)).lib_pvta10

Links de interes y bibliografia utilizada:

Gracias al blog http://www.learnsaptips.com/, Anupa Wijesinghe ha eleborado este manual con los pasos a seguir para la configuración de la parametrización:
 
 
Aprovecho para recomendaros la lectura del blog, con gran cantidad de material y tutoriales elaborados por Anupa de gran calidad.
 
 
Publicado en Sap SD | Etiquetado , , , , | 8 comentarios