Fuentes web
Entradas
Comentarios

Durante mis 12 años de experiencia en implantaciones y mantenimiento de sistemas Sap (al igual que en otro tipo de aplicaciones), he constatado lo importante que es una correcta formación a los usuarios en las herramientas que van a utilizar, no solo a nivel del módulo especifico con el que van a trabajar, sino en aspectos básicos de la aplicación y el entorno de usuario concreto.

Traducido esto a Sap, es imprescindible desde mi punto de vista, que el usuario reciba formación especifica sobre el entorno de usuario de Sap, lo que repercutira en una mejor productividad, asi como en una mejora de la experiencia de usuario (importante muchas veces al empezar a usar un sistema nada sencillo como es Sap).

Aspectos como la personalización del Sapgui, el uso de variantes de reports, variantes de visualización en ALVs, configuración personalizada de table control, la creación y organización de favoritos, el uso de atajos, las opciones de ayuda de busqueda y su customizacion, exportacion de informacion a otros formatos (Excel, Texto,), opciones de impresión o envio de informes, mensajería interna de Sap, etc, son fundamentales para sacarle todo el partido al sistema

Son temas sencillos en principio pero que al usuario le van a mejorar su percepción del sistema y le van a ayudar a trabajar de una forma mucho más fácil y productiva.

Aunque veremos más adelante con ejemplos concretos como mejorar la experiencia de usuario con estos Tips, os dejo un documento desarrollado por mi donde se explican los aspectos mas importantes de la Ergonomia de usuario en Sap. Para mi, el primer documento que tendria que   “estudiar” cualquier usuario que empezará a trabajar con Sap.

El documento también lo podeís descargar aquí. Se distribuye con licencia “Creative Commons Reconocimiento 3.0 España License“, para que podais utilizarlo sin ninguna restricción, siempre que hagais un reconocimiento de la fuente.

Para los que estais empezando con Abap o para los que trabajais habitualmente con el, es util conocer que Sap proporciona, a través de varias transacciones, un autentico repositorio de ejemplos de código, que nos puede sacar de algún apuro en muchas ocasiones, además de “darnos ideas” respecto a opciones que tenemos disponibles con el lenguaje, posibilidades de programacion, opciones de ergonomia o simplemento ejemplos totalmente funcionales que nos pueden dar una nocion de como resolver un determinado requerimiento o problema a la hora de programar en Abap. Las mas interesantes son:

  • Transacción ABAPDOCU: completa documentacion del lenguaje de programación Abap, que incluye ejemplos de código de los elementos más importantes, en forma de arbol estructurado.

  • Transaccion BIBS: ejemplo de configuración de superficies. Es una guia de estilo enfocada a la configuración de los elementos de entrada/salida del lenguaje, de cara a la interaccion con el usuario en las pantallas de selección (principalmente) y los dynpros.
  • Transacción DWDM: centro de presentaciones Enjoy. Galeria de reports con ejemplos orientados a la programación orientada a objetos, dentro del estilo Enjoy principalmente.
  •  Transacción SE81 Reuse Library: transacción muy interesante que combina, agrupado por areas, el acceso a la documentación y la ayuda Online de Sap, con ejemplos de código, dandonos acceso directo a los reports de ejemplo que Sap tiene disponibles en el repositorio.
  • Transacción GUIT: suite de ejemplos que nos muestra un programa de forma secuencial, principalmente orientados a las programación con listas.
  • Transacción GRAL: galeria de ejemplos para trabajar con gráficos en Abap (presentacion de resultados con graficos de barras, de tarta, etc).
  • Transacción SE30 Tip and Tricks: interesante utilidad para analizar tiempos de ejecución de los reports y analizar los consejos de programación que nos ofrece Sap para mejorar el rendimientos de los programas.

Ademas, en la Web tenemos multitud de paginas donde tambien podemos encontrar ejemplos de programacion (principalmente en la SDN de Sap). Algunos links interesantes son:

  1. Abap Development and Programming: link.
  2. Abap Tip and Tricks: link.
  3. Manuales de Abap en castellano online: link.

Otra utilidad que os puede sacar de algun apuro en la busqueda de ejemplos es el report RPR_ABAP_SOURCE_SCAN. Nos permite buscar sentencias en el codigo fuente de los programas Abap. Por ejemplo, buscamos un ejemplo de uso de determinada sentencia. Igualmente, con la transacción S_ALR_87101287  podemos buscar en un determinado programa si acceder a el con las transacciones de modificación (SE38, SE51, etc).

Finalmente, os dejo como contenido relacionado el interesante tutorial publicado en Saptechnical.com donde nos habla del nuevo editor Abap y las opciones de configuracion de este:

En las próximas entradas del blog vamos a abordar ejemplos prácticos de como utilizar los Idocs para comunicar nuestro Sap con otros sistemas (tanto Sap como no Sap). Para abrir un poco el apetito, os dejos una fabulosa presentación que he encontrado sobre este tema donde se abordan los aspectos fundamentales de esta tecnologia.

Con ella nos podemos hacer una idea de su funcionamiento, estructuración y posibilidades para implementar nuestros procesos de comunicación y traspaso de información entre los diferentes componentes de nuestro parque TI.

Espero que os resulte interesante.

NOTA: en la presentación Online de slideshare no se visualizan correctamente las imagenes del documento. Os recomiendo descargaros la presentación para observar todos los detalles. Link aquí: ale-idoc-edi-1195039813411322-3.

Después de un largo mes de diciembre, y un mes de enero “movidito”, como todos los comienzos de año con Sap (ya sabéis, instalación de parches, arreglo de errores, notas,  cambios legales, etc, etc), vamos retomar el blog con un truco sencillo donde vamos a hablar sobre los valores fijos y parámetros de memoria que podemos fijar en el sistema a nivel de usuario.

Accedemos tanto a los valores fijos como a los parámetros desde la opción de menú Sistema –> Valores Prefijados –> Datos Propios. Esta opción de menú esta disponible desde cualquier lugar, bien desde los menús o dentro de una transacción. Los datos también se pueden mantener en las transacciónes de gestión de usuarios (SU01 para un usuario individual o la SU1o para la modificación de usuarios de forma masiva).

Valores Fijos.

En los valores fijos indicamos la configuración de trabajo del usuario con el sistema, pudiendo indicar aspectos como:

  • Menú inicial: podemos hacer que el usuario tenga por defecto un menú inicial que no sea el general del sistema (S000). Incluso podríamos crear nuestros propios menús personalizados y asignárselos a los usuarios que van a trabajar en un determinado ámbito (aunque esto también lo podemos hacer vía roles de autorización).

  • Idioma de trabajo: el idioma indicado aquí tendrá prioridad por el indicado en el momento del logon al sistema.
  • Representación decimal: este valor fijo es muy interesante. Por defecto, Sap nos ofrece la coma como separador para los decimales y el punto para los miles. La mayoría de gente que trabaja con los módulos de finanzas, compras o ventas suele utilizar el teclado numérico para introducir las cifras en el sistema y está acostumbrado a trabajar con el punto (.) como separador de los decimales. Aquí podemos cambiar la representación para que siga este formato (internamente no afecta, pues Sap guarda la información en la base de datos de la misma forma).
  • Representación de la fecha: el formato por defecto es el dd.mm.aaaa, aunque aquí podremos trabajar con otros formatos, habituales en otros países ( mm/dd/aaaa, aaaa.mm.dd, aaaa-mm-dd, etc).
  • Control Spool: aquí indicamos valores relacionados con la impresión, como la impresora por defecto del usuario y la forma de imprimir (impresión inmediata o no, conservación de las ordenes en el spool una vez realizada la impresión).

Parámetros.

Los parámetros son valores de usuario que se pueden conservar en memoria y que luego nos van a aparecer predefinidos cuando entremos en las transacciones. Por ejemplo, podemos fijar la sociedad de finanzas o controlling con la que trabajamos (parámetros BUK o CAC), Organización de compras (EKO), Grupo de compras (EKG), Organización de ventas (VKO), Tipo de documento de ventas (AAT), Clase de documento de finanzas (BAR), etc, etc. Cuando entremos en una transacción que tenga estos campos y habilitada la recuperación de valores de memoria, estos campos se llenarán con estos valores predefinidos, agilizando el trabajo de usuario.

La forma de localizar si un campo en una determinada transacción es susceptible de ser importado a partir de los valores en memoria del usuario es hacer un F1 posicionados en el campo y buscar el valor “ID parámetro”.

Ademas, los parámetros nos pueden servir para guardar configuraciones predefinidas cuando las fijamos utilizando los diferentes programas de Sap. Por detras, el sistema se ha guardado los valores de dicha configuración utilizando parámetros de memoria. Por ejemplo, la configuración de Opciones de tratamiento en finanzas (transacción FB00), guarda su configuración en el perfil del usuario en los parámetros.

En el ejemplo, he fijado diferentes opciones para trabajar con finanzas (calculo de impuestos, variantes para las pantallas de contabilización, variantes de visualización en las listas de partidas abiertas, etc). Todo eso se ha quedado guardado automáticamente en mi perfil de usuario en los parámetros FBA, FBZ, F02, F03, FOP, etc.

Existen una multitud de parámetros relevantes en el sistema, como el MOL y UGR en Recursos Humanos, donde se determina el grupo de usuario y modificador de país, lo que luego afecta al comportamiento del sistema y a los menús de infotipos o de medidas; el parámetro IVFIDISPLAY que nos permite, al contabilizar facturas de compras desde la transacción MIRO, que el sistema nos devuelva el número de documento contable además del número de registro de facturas; el parámetro SD_VARIANT_MAINTAIN que nos permite mantener las variantes de visualización en los informes comerciales, etc, etc.  Son solo algunos ejemplos de la multitud de aspectos que se pueden configurar para mejorar la productividad de usuario en el sistema usando esta funcionalidad.

Nota: podremos crear nuestros propios parámetros de memoria manteniendolos con la transacción SM30/SM31 en la tabla TPARA. Luego los podremos utilizar en nuestros desarrollos a medida y utilidades para inicializar valores o para establecer diferentes comportamientos de las aplicaciones según los valores prefijados (utilizando las sentencias abap SET PARAMETER/GET PARAMETER). Igualmente, podremos recuperar con estas instrucciones los valores de los parámetros estandar.

Los duendes de las estadísticas de WordPress.com prepararon un reporte para el año 2011 de este blog.

Aqui es un extracto

La sala de conciertos de la Ópera de Sydney contiene 2.700 personas. Este blog fue visto cerca de 58.000 veces en 2011. Si fuese un concierto en la Ópera, se necesitarían alrededor de 21 actuaciones agotadas para que toda esa gente lo viera.

Haz click para ver el reporte completo.

En una entrada anterior de Blog dejabamos el ejemplo de una utilidad que nos permitía localizar las user-exit de una transacción (aquellas definidas por Sap mediante la transacción SMOD y que luego nosotros activamos en un proyecto de ampliación con la transacción CMOD).

Utilidad para buscar User-exits (CMOD/SMOD)

Posteriormente, en varias entradas del Blog vimos las diferentes técnicas que Sap pone a nuestra disposición para personalizar nuestro sistema en aquellos aspectos que la parametrización no cubre. Hicimos un resumen de las diferentes técnicas con ejemplos prácticos de todas ellas (field exits, variantes de transacción, ayudas de búsqueda y las más relacionadas con la programación: User Exit, Customer Function, Badis, BTE y Enhancemets).

NOTA: además de en esta página, en varios Blogs amigos han aparecido entradas similares donde se explican muy bien las diferentes opciones de personalización de nuestro Sap. Os recomiendo su lectura: TEKNODATIPS y CONSULTORIA SAP, cada uno con su enfoque particular.

Como ya comente, muchas veces lo realmente difícil es encontrar en el punto que nos interesa (transacción, report), los componentes de este tipo que Sap nos deja disponibles, para poder analizarlos para ver si cubren nuestro requerimientos e intentar personalizar en el sistema con el aspecto necesario solicitado por nuestros clientes o usuarios internos.

Para facilitar esta tarea, os dejo una utilidad desarrollada por Luciano Rebuffi  (podéis descargaros el código fuente en este link), muchas gracias por su aportación.

En la utilidad hemos de indicar un nombre un nombre de transacción o un programa, y los elementos a analizar, pudiendo seleccionar User-exits, Badis, BTE, Ampliaciones o Sustituciones (de ellas hablaremos más adelante en nuestro blog) o Field-exits.

La herramienta realiza un completo barrido en el código fuente de la transacción indicada y nos devuelve una lista de resultado completa donde empezar a analizar si tenemos alguna opción disponible para cubrir nuestra necesidad.

En mi ejemplo, he ejecutado la utilidad con la transacción VA01 (creación de pedidos de venta) y me ha salido una lista de resultados completa (y amplia) donde puedo ver la cantidad de puntas que Sap deja disponibles para personalizar los procesos de venta.

  • User-exits: aquellas rutinas con el nombre USEREXIT_XXXX_XXXX que Sap deja vacias dentros de unos include estandar que nunca serán tocados en las actualizaciones (mencionamos que en el módulo de ventas se utilizaban muchisimo). En la búsqueda me han salido 242 ampliaciones de este tipo.

  • Customer Function: corresponden a las llamadas a los módulos de función EXIT_SAPXXXX_XXX, donde Sap define un include Z donde podremos incluir nuestro código (son las relacionadas con las transacciones SMOD/CMOD como ya vimos).

  • Badis: las ampliaciones de última generación, relacionadas con la programación orientada a objetos y que podemos gestionar desde la transacciones SE18/SE19.

  • BTE: aquellas ampliaciones que gestionamos desde la transacción FIBF, casí siempre más relacionadas con transacciones financieras (son igualmente una llamada a un módulo de función que nosotros podremos personalizar).

Como podéis ver, una utilidad totalmente recomendable y que a mi me ha solucionado muchos problemas en unas cuantas ocasiones.

Al contrario que en la mayoría de módulos de Sap, donde podemos consultar un útil historial de modificaciones (en el maestro clientes, proveedores o artículos; pedidos de compras o ventas, apuntes contables, etc), en la gestión de datos maestros de empleados (los famosos infotipos), no existe un log de modificaciones por defecto y toda la información que nos proporciona Sap es la fecha de la última modificación y el usuario que la realizo.

Esto nos impide analizar los cambios realizados en los datos de los empleados (tanto datos personales como datos relevantes para el pago o para cuestiones legales, tales como impuestos, seguridad social, etc). Tampoco podemos hacer una traza de registros borrados, pues por defecto no queda ningún rastro de las acciones en el sistema. Tratándose de un módulo tan delicado como el que afecta la gestión de la remuneración y muchos datos personales de los empleados, se echa en falta disponer de un completo log de modificaciones.

Como siempre, aunque no se encuentra activado por defecto, Sap nos deja abierta una puerta para este registro sin necesidad de programar (podiamos haber utilizado, por ejemplo, la ampliación PBAS0001 PA: Gestión/contratac. personal: Valores propuesta y verif., que se ejecuta después de cada interacción del usuario con los datos en los infotipos, que se gestiona como ya vimos con las transacciones CMOD/SMOD).

La activación de la creación de los documentos de modificación se realiza a través de la ruta de customizing Gestión de Personal –> Gestión de Personal –> Herramientas –> Revisión –> Definir documento de modificación.

La configuración de esta funcionalidad se realiza en tres pasos, que vamos a explicar a continuación:

  • Definición de infotipos relevantes para el historial: en ese paso, indicamos que infotipos son susceptibles de gestionarse en el log.

  • Definición de grupos de campos por infotipo: dentro de cada infotipo de los relevantes, indicaremos los campos para los que se ha de grabar el log de modificaciones. Los campos se organizan en grupos, de forma que cuando se realice una modificación en alguno de los campos del grupo, se guardará información del valor de todos los campos del grupo. En el ejemplo, hemos creado un grupo en el infotipo 2 de Datos Personales con los campos Nombre, Apellidos, Identificador Fiscal y Lugar de nacimiento.

  • Especificar propiedades de los grupos de campos: en este último paso realizamos la activación del log para cada uno de los grupos de campos definidos. Importante indicar la clase de protocolo a largo Plazo (valor L en el campo Cl.comp), para luego poder analizar la información de forma detallada.

Una vez realizada la configuración, el sistema ira registrando las modificaciones realizadas en los infotipos y campos relevantes, guardando la información en la base de datos. Posteriormente, podremos analizar los cambios realizados mediante el report estandar RPUAUD00. En el caso de querer programar para preparar nuestros propios informes personalizados, podemos utilizar los módulos de función:

  • HR_INFOTYPE_LOG_GET_LIST: para el resumen.
  • HR_INFOTYPE_LOG_GET_DETAIL: para el detalle de modificaciónes.

Al utilizar el report RPUAUD00 podemos seleccionar por diferentes criterios tales como empleado, infotipo, fecha y usuario de la modificación, etc. Nos aparece un resumen de las modificaciones realizadas según los criterios de selección indicados, y en el detalle la información de los campos que se han modificado (todos los que pertenecen al grupo, aunque no hayan variado), con sus valores anteriores y sus valores nuevos.

Desde este log, además de las modificaciones, podemos analizar los registros que se han creado o que se han borrado, con lo que queda completamente controlado las acciones que se realizan sobre los campos e infotipos que hayamos seleccionado.

NOTA: deberemos de usar el log de modificaciones con la debida precaución, pues seguramente no será necesario registrar todos los cambios en todos los infotipos, teniendo en cuenta el gran volumen de información que podemos estar registrando de forma inutil. Nos centraremos en aquellos infotipos más críticos o mas relevantes para los pagos.

NOTA sobre protección de datos: aunque existe una funcionalidad especifica para el registro del acceso a datos personales con nivel de protección alto (según la ley LOPD en España, ver notas del OSS 394999, 848119), con el log de modificaciones podemos realizar también funciones de control sobre la modificación de determinados datos delicados (salud, ingresos, etc).

NOTA: también podríamos haber configurado un registro del lanzamiento de determinados reports en la gestión de personal desde la ruta de custo Gestión de Personal –> Gestión de Personal –> Herramientas –> Revisión –> Grabar en log los lanzamientos de reports. Posteriormente, con el report RPUPROTD se pueden visualizar estos datos y borrar los logs con el report RPUPROTU.

Seguir

Get every new post delivered to your Inbox.

Únete a otros 282 seguidores