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.

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.

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.

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.

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.

El mantenimiento de los formularios se realiza desde la transacción PE51, donde disponemos de las diferentes secciones del recibo donde pintar la información que queremos mostrar a los empleados referente a su pago.

Básicamente disponemos de los siguientes objetos en un típico formulario:

• Fondo: textos fijos que aparecen en el formulario y que siempre se imprimen.
• Campos individuales: información que siempre se imprime en el mismo lugar, y que será variable según el empleado que estemos tratando (por ejemplo, número de empleado, nombre, dirección, número de la seguridad social, total de pago, etc).
• Ventana: sección para la impresión de los conceptos salariales (tabla). Se definen lineas con la definición de los conceptos que la incluyen y su formato de impresión (disposición de las lineas).
• Disposición de lineas: formato para la impresión de los conceptos salariales en la ventana.
• Identificadores de acumulación: acumuladores donde totalizamos los diferentes conceptos salariales (por ejemplo devengos, deducciones, retenciones, seguridad social, etc) y que podremos utilizar también en el formulario para su impresión.
• Textos: definición de textos que luego se podrán utilizar en el formulario.
• Reglas: nos permiten la impresión o no de determinada información si se cumplen ciertas reglas.

La tecnología de los recibos es un poco antigua y bastante limitada de cara a las inclusión de nuevos campos o a la incorporación de campos propios calculados de una forma especial, así como en lo referente al diseño del formulario (inclusión de imágenes o logos, ficheros de firma, etc).

Para el caso de que tengamos la necesidad de incluir nuevos campos que no estén en el estandar, Sap nos deja una puerta abierta en el programa de impresión a través de los includes:

• RPCEDDZ9: include para la definición de estructuras de datos.

• RPCEDSZ9: include para la programación de llenado de estas nuevas estructuras de datos o rutinas adicionales.

En estos includes podemos definir los campos o estructuras de datos que luego utilizaremos en el formulario, y el código Abap para el llenado de dichos campos.

Ademas de la programación, hay que realizar un customizing adicional para decirle al sistema que estos nuevos campos están disponibles y en que lugar de los recibos los vamos a poder utilizar. Para ello, utilizaremos la transacción PE51_CHECKTAB.

EJEMPLO PRACTICO. NUEVOS CAMPOS PARA DIRECCION DEL CENTRO DE TRABAJO DEL EMPLEADO.

Hemos creado en el infotipo 6 de direcciones una nueva clase de dirección, Z1 donde almacenaremos la dirección del centro de trabajo de empleados que no estan en la sede central de la compañia (que es la que se mantiene a nivel de División/Subdivisión de personal). A continuación, realizamos la modificación de los includes:

• Include RPCEDDZ9: incluimos el registro donde vamos a guardar los datos de la dirección recuparada del empleado.

* Datos de Direccion para Centro de Trabajo.
 DATA: BEGIN OF Z500P,
         STRAS TYPE T500P-STRAS,
         PSTLZ TYPE T500P-PSTLZ,
         ORT01 TYPE T500P-ORT01,
       END OF Z500P.

• Include RPCEDSZ9: en el form POS-FIX-DATA-MOD  (pues lo que vamos a añadir es un campo individual),

FORM POS-FIX-DATA-MOD USING $FOUND LIKE BOOLEAN
                             FLD_INFO TYPE TR_FLD_INFO.
   $FOUND = TRUE.
   CASE FLD_INFO-LNAME-STRNG.
     WHEN '$1'.
       PERFORM POS-$1.

    WHEN 'Z500P'.
       PERFORM fill_z500p using wpbp.             "Rutina para hacer la lectura de la direccion del centro de trabajo.

Esto no es suficiente para que el campo este disponible en el momento de diseñar el formulario. Para que los nuevos campos sean visibles, hay que parametrizar las tablas T514?, a través de la transacción PE51_CHECKTAB. Para los formularios de nómina de España, trabajaremos con el agrupador de paises 04 y la clase de formulario CEDT.

En este caso, al tratarse de un registro con varios campos, lo incluiremos en la sección Tablas (marcando el flag de campo individual, que es la sección del formulario donde lo utilizaremos). Igualmente, incluiremos cada uno de los campos en la sección  Campos. Una vez realizada la parametrización, ya podemos editar el formulario y colocar en el lugar deseado los nuevos campos.

NOTA ADICIONAL: también podemos utilizar el include RPCEDSZ9 (rutina CHECK_PRINT_MOD), para incluir criterios de selección adicionales en la impresión de los recibos de nómina (al seleccionar el valor AZ en el campo Imprimir periodo actual). Podemos, por ejemplo, crear una rutina que solo imprima nóminas para las que se haya realizado el pago o alguna casuística similar.

• Field exits: a nivel de campo en cada pantalla, podemos introducir código abap propio para realizar verificaciones adicionales en los datos (ver entrada relacionada). Es una tecnologia obsoleta que Sap va abandonando, pero que aun se puede utilizar en muchas dynpros.
• Variantes de transacción: con las variantes de transacción podemos crear nuestras propias transacciones proponiendo valores por defecto, modificando los campos que aparecen, su tipo (visibles, invisibles, solo visualización, obligatorios, etc). Ejemplo aquí.
• Documentación de campo estandar: con esta funcionalidad podemos añadir documentación adicional a cualquier campo. La ayuda de campo se accede desde la tecla F1. Ejemplo aquí.
• Ayudas de búsqueda: Sap ofrece los matchcode o ayudas de busqueda (con la tecla F4) de forma estándar de una forma muy completa en la mayoria de campos. En el caso de que las ayudas estandar no nos valgan,porque queramos buscar por campos adicionales o por campos de cliente, podemos ampliarlas con las nuestras propias. Ejemplo aquí.

Respecto a las ampliaciones o Enhancements, estos son programas que Sap deja habilitados para cubrir las necesidades adicionales del cliente, sin modificar el código fuente del programa estandar.  Es decir, son usadas para expandir la funcionalidad estándar dentro del sistema SAP.

Actualmente existen en SAP tres generaciones de ampliaciones:

• Primera generación: subrutinas vacías dentro de un programa estándar en las cuales se puede agregar código. El nombre de las mismas comienza con USEREXIT. Esta modalidad implica modificar el estándar (necesitamos clave de modificación de Sap), aunque Sap asegura que las rutinas para las exits no serán tocadas en las actualizaciones. Las Userexit se utilizan mucho en el módulo SD, donde vimos un ejemplo para añadir campos adicionales en los informes de pedidos y en el pool de facturación (ver aquí).
• Segunda generación: CUSTOMER-FUNCTION. En algunos lugares del código estándar hay llamadas de tipo CALL CUSTOMER-FUNCTION <NRO> (Ej:‘001’). Estas rutinas se definen con la transacción SMOD y se editan con la transacción CMOD. Son realmente llamadas a módulos de función que incluyen un include Z que no existe (esta vacío), y que nosotros creamos y le damos contenido cuando creamos el proyecto de ampliación.  Vimos un ejemplo de exit de este tipo ampliando los campos del informe de partidas individuales de controlling (ver aquí).

• Tercera generación: BADIS. Usan instancias de ABAP Objects. Se invocan con CALL METHOD. Se crean con la transacción SE18 y se implementan con la transacción SE19. Sap nos deja disponibles crear la correspondiente implementación de la BADIS donde nosotros personalizaremos el sistema con nuestro código Abap. Vimos un ejemplo de Badis ampliando los campos de los informes de partidas de contabilidad (ver aquí). Tambien os recomiendo la entrada del blog Teknodatips donde se habla de la forma de localizar las badis.

Además, podemos mencionar otras posiblidades de ampliación del sistema que son:

• Business Transactions Events (BTE): se gestionan desde la transacción FIBF y son módulos de función que se llaman desde determinados puntos del código fuente, en determinados eventos. Podemos crear nuestros propios módulos de función y activar su llamada en dichos eventos.  Vimos igualmente un ejemplo de su uso en la ampliación de campos del listado de Partidas de FI (ver aquí).
• Enhancements de código: con los puntos de ampliación implicitos (disponibles en cualquier programa Abap en unos lugares determinados), podemos introducir nuestro propio código Abap sin que ello sea una modificación del estandar. Los enhancements son puglins dinámicos que sustituyen el código fuente, y que nos dan muchisimas posibilidades, aunque siempre se habrán de usar con la debida cautela. Vimos un ejemplo para modificar la selección de pedidos en el registro de facturas de compras (transacción MIRO), ver aquí. En la entrada del blog abap.es podeis visualizar los pasos a seguir para crear una enhacement del tipo implicito.

Como podeís ver, casi siempre Sap nos va a dejar una puerta para adaptar el sistema a nuestras necesidades, aunque quizás lo más complejo será identificar el método de personalización que podemos utilizar y localizarlo de entre las diferentes opciones disponibles.

• Actualizaciones Sap: al instalar notas o los parches, el programa puede volver a ser llevado al estandar y tendremos que ajustarlo para volver a incluir nuestros cambios. Puede incluso cambiar la lógica del programa, aspecto que nos obligará a volver a programar nuestra adaptación. Ademas, las modificaciones deberán de estar debidamente documentadas para facilitar la tarea de administrar el sistema.
• Upgrades de Sap: en un cambio de versión habrá que tener en cuenta todas las modificaciones.
• Incorrecto funcionamiento del sistema al tocar el comportamiento estandar de las aplicaciones. Solo sería conveniente modificar los informes que utilizar para extraer información del sistema, y así minimizar el impacto que supondría una alteración de la lógica de funcionamiento de los programas, tablas, etc.

De cara a evitar estas modificaciones, tenemos varias alternativas:

1. Creación de programas Z como copia de los estandar: identificamos el programa que queremos adaptar y lo  copiamos en un programa Z que podremos modificar sin ninguna restricción y sin ningún efecto sobre el estandar. Aunque siempre con las debidas precauciones, y una revisión regular del programa original por si hubieras cambios importantes en su funcionalidad que nos obligará a repetir la copia.
2. Uso de enhancements: es un concepto nuevo introducido por Sap en el lenguaje de programación Abap. Los enhacements son plugins dentro de los programas que podemos modificar para introducir nuestro propio código fuente. Sap no los considera una modificación del estandar. Ademas, no afecta a los upgrades o actualizaciones y podemos activarlos o desactivarlos según nuestras necesidades.

Vamos a centrarnos en el uso de los enhancements. Podeís ampliar información sobre ellos en el siguiente link. Basicamente, tenemos disponibles enhacements implicitos y explicitos.

Los implicitos siempre existen en todos los programas Abap en determinados lugares del código, que son:

• Al final de los include.
• Al final de las sentecias PUBLIC-, PROTECTED-, PRIVATE-SECTION de una clase.
• Al final de la parte de implementación de una clase( antes del ENDCLASS, que pertenece al CLASS … IMPLEMENTATION).
• Al final de una definición de Interface (antes del ENDINTERFACE).
• Al final de una definición de estructura  (antes de  TYPES END OF, DATA END OF, CONSTANTS END OF,y STATICS END OF).
• Al principio y al final de un procedimiento (FORM, FUNCTION, METHOD). Es decir, despues de las sentencias  FORM, FUNCTION, y METHOD, y antes de ENDFORM, ENDFUNCTION, y ENDMETHOD.
• Al final de CHAGING-, IMPORTING-, EXPORTING en la lista de parámetros de un metodo.

Esto significa que en todos esos lugares podremos  insertar nuestro código abap sin que ellos suponga una modificación del report (y sin pedirnos el sistema la consiguiente clave de modificación que hemos de registrar en la web de Sap).

Los explicitos son introducidos a conciencia en cualquier punto dentro de un programa con la sentencias ENHANCEMENT-POINT y ENHANCEMENT-SECTION. Los diferentes elementos que forman el enhancement se pueden agrupar y luego gestionar de una forma conjunta (para habilitarlos o no según nuestras necesidades). Podeís ampliar información sobre ellos aquí. Como añadir estas sentencias dentro del código si sería una modificación, lo podemos ver como una opción de cara a configurar el comportamiento de nuestros desarrollos Z según flags que nos permiten configurar la funcionalidad, y activarla/desactivar determinados comportamientos según nuestra necesidad.

Selección de pedidos de compra personalizada en el registro de facturas de proveedor (transacción MIRO).

En el ejemplo que vamos a plantear tenemos un requerimiento del cliente que nos pide que, al seleccionar los pedidos de compras contra los que se registran las facturas de proveedor a través de la transacción MIRO, podamos utilizar criterios de selección adicionales. También desean en la lista de resultados poder ver esos otros campos. Este requerimiento es debido a que los pedidos de compras se gestionan en un sistema externo a Sap y se interfasean de forma automática, existiendo una numeración de pedidos distinta a la existente en Sap.

Los pasos a seguir para implementar nuestro requerimiento son los siguientes:

1. Identificar dentro de la Miro, el report donde se hace la llamada a la selección de pedidos. Es un report externo a la transacción, que se llama RM08RL82.
2. Copiamos el report RM08RL82 al nuevo ZRM08RL82, y lo modificamos para que incluya tanto los nuevos criterios de selección en la pantalla de ejecución, como en la lista de salida. Al ser un Z, no estamos tocando nada del estandar.
3. En la transacción MIRO (modulpool SAPLMR1M), buscando el lugar donde se hace la llamada al report RM08RL82. La llamada se hace en el FORM rm08rl82_aufrufen dentro del include LMR1MF4S. Como tenemos un punto de enhacement al principio del FORM, lo creamos e introducimos ahí el código abap para que se llame a nuestro report en lugar del report estandar.

Activamos el cambio y de una forma relativamente sencilla hemos conseguido cubrir el requerimiento del cliente sin tocar el estandar o sin un desarrollo propio complejo.

En la entrada del blog abap.es podeis visualizar los pasos a seguir para crear una enhacement del tipo implicito.

NOTA IMPORTANTE: cualquier modificación del estandar es totalmente desaconsejable, y solo deberá ser llevada a cabo en situaciones excepcionales, realizada por programadores expertos y consultores que validen la implicación de los cambios que se vayan a realizar. Igualmente todo debera de ser debidamente documentado de cara a facilitar el mantenimiento del sistema, así como los procesos de actualización o upgrades de versión posterior.

En nuestro ejemplo, vamos a añadir algunos campos en la transacción de listado de pedidos de ventas (VA05). Para ello, accederemos al customizing desde la ruta Comercial –> Adaptación del sistema –> Inclusión de nuevos campos (sin técnica de condiciones) –> Nuevos campos para las listas de documentos comerciales –> Otros campos visual.para listas de documentos de ventas. Tambien podemos acceder con la transacción VOA01.

Los pasos a seguir son basicamente tres:

1) Campos autorizados (vista V_T180A): pulsando el botón campos permitidos, podemos ver los campos disponibles para el listado de pedidos. En el caso de que el campo deseado no se encuentre en la lista, lo añadiremos.

Crearemos un campo con la nomenclatura ZZ_NOMBRECAMPO, para que nunca colisione con los campos estandar de Sap. Es necesario que el campo se defina en esta tabla, ya que sino no lo podremos utilizar en los pasos siguientes de la configuración.

2) Inclusión del campo en la estructura VBMTVZ: accediendo desde la opción Ampliación de estructura –> Mejoras de cliente para: Posiciones de pedido para material, realizamos el mantemiento de la estructura VBMTVZ, donde incluiremos el/los campos que queramos que aparezcan posteriormente en la lista de pedidos.

3) Ajuste del include V05TZZMO donde se llenara el valor del campo: en esta sección escribiremos el código Abap para llenar los valores del campo. En este caso, el campo ya existe en la cabecera del pedido de venta (tabla VBAK) y nos limitaremos a moverlo a nuestro campo de cliente, pero en el caso de un campo que incluya información de otro lugar (cliente, materiales, etc) o un cálculo, lo podremos realizar sin problema con nuestro código Abap.

Es importante incluir el código en el lugar correcto (VBAK Cabecera de pedido, VBAP Posiciones de pedido, etc). Y tener en cuenta que hay campos que aunque esten en la estructura de datos, no tienen porque aparecer en el listado estándar disponibles, algo que es lógico teniendo en cuenta la cantidad de campos posibles que tiene el estandar.

Con este último paso, hemos terminado la configuración de la lista de pedidos y el nuevo campo ya estará disponible en la transacción VA05. Antes de que el usuario lo visualize en la lista, un pequeña consideración sobre el mantenimiento de las variantes de visualización en los informes comerciales:

El mantenimiento de variantes en los informes comerciales no esta habilitado por defecto, y solo se realiza cuando el usuario tiene en su perfil el parámetro SD_VARIANT_MAINTAIN (Authorization for variant maintenance) con el valor A. Es un mecanismo de protección para proteger las variantes y que cualquier pueda modificarlas.

Una vez ajustada la variante deseada, el usuario ya tendrá disponibles los nuevos campos.

El procedimiento descrito es válido también para ampliar el listado de facturas (transacción VF05), pero usando la transacción de configuración VOF01 (opción del custo Otros campos de visualización para listas docs.facturación, en la misma ruta que hemos indicado al principio).

Como bonus de esta entrada, si alguna vez teneis que ampliar los campos que aparecen en el pool de facturación (transacción VF04 o VF06), que es desde donde realizamos la facturación manual de pedidos y entregas, podeis utilizar el módulo de función RV_READ_INVOICE_INDEX. Esta se llama desde las transacciones VF04 y VF06 (facturación en procesos de fondo). En el final del código de esta función hay una llamada a la rutina END_MODIFICATION, que se encuentra dentro del include VV05HFZ2 y que nosotros podremos modificar para introducir nuestro propio código Abap, y el llenado de nuestros campos de cliente.

Previamente habrá que añadir los campos deseados en la estructura VKDFI, utilizando el include VKDFIZ. Con esta opción podemos superar las limitaciones del pool de facturación en cuanto a campos disponibles para ajustar el proceso de selección y validación de pedidos/entregas en la creación de facturas.

• Informes de partidas reales: transacciones KSB1 para Centros de Coste, KOB1 para Ordenes y  CJI3 para Proyectos.
• Informes de partidas planificadas: transacciones KSBP para Cecos, KOBP para Ordenes y CJI4 para Proyectos.
• Informes de partidas comprometido: transacciones KSB2 para Cecos, KOB2 para Ordenes y CJI5 para Proyectos.

El procedimiento se describe en la Nota Oss 325546, y nos permite añadir campos de cliente tanto en los informes de partidas abiertas reales, planificadas o de comprometido. Vamos a ver un ejemplo práctico utilizando las partidas abiertas reales de Proyectos, aunque tendremos la posibilidad de ampliar también el resto de informes.

Básicamente, hemos de utilizar la ampliacion COOMEP01 (transaccion CMOD/SMOD), seleccionando la exit especifica según el lugar donde queremos añadir la información, aunque habrá que realizar algunos pasos adicionales a este. Veamos en detalle un ejemplo:

En nuestra empresa quieren añadir campos adicionales al informes de partidas individuales de proyectos, para ver los siguientes valores:

• Nombre y Departamento del empleado que esta imputando horas a los proyectos.
• Nombre del Proyecto (descripción).
• Clase de elemento Pep y su descripción, para poder filtrar o subtotalizar la información por este concepto.

Los pasos a seguir son los siguientes:

Ampliación de la estructura KAEP_COAC.

A través de la transacción SE11, en la estructura KAEP_COAC, en el include CI_RKPOS, añadiremos todos los campos necesarios. Siempre seguir la nomenclatura ZZ_NOMBRECAMPO.

Una vez concluida la ampliación de la estructura, activaremos los cambios para que esten disponibles.

Proyecto de ampliación COOMEP01.

En este proyecto de ampliación Sap nos deja la puerta para incluir el código Abap con el que llenaremos los campos definidos en la estructura anterior. El proyecto de ampliación lo gestionaremos con la transacción CMOD. Para ello, creo el proyecto ZCO_PART CO: incluir nuevos campos en informes partidas individuales, y lo asigno la ampliación COOMEP01.

En la exit EXIT_SAPLKAEP_001, en el include ZXKAEPU01, introducimos el código fuente que va a leer de las diferentes tablas:

 IF cs_record-obart = 'PR'.
* Ampliar campos varios del proyecto.
* Descripcion del proyecto.
  CLEAR proj.
  SELECT SINGLE * FROM  proj
         WHERE  pspid  = cs_record-pspid.
  cs_record-zz_post1 = proj-post1.

* Clase de elemento Pep y su descripcion.
  CLEAR prps.
  SELECT SINGLE * FROM  prps
*       where PSPNR   = cs_record-objid.
         WHERE  posid  = cs_record-posid.
  cs_record-zz_prart = prps-prart.

  CLEAR tcj1t.
  SELECT  SINGLE * FROM  tcj1t
         WHERE  langu  = sy-langu
         AND    prart  = prps-prart.
  cs_record-zz_pratx = tcj1t-pratx.

* Nombre del empleado.
  IF cs_record-pernr IS NOT INITIAL.
    CLEAR pa0002.
    SELECT SINGLE * FROM pa0002 WHERE pernr = cs_record-pernr.
    CONCATENATE pa0002-vorna pa0002-nachn pa0002-nach2 INTO cs_record-zz_cname
       SEPARATED BY space.

* Departamento y descripcion de este.
    CLEAR pa0001.
    SELECT SINGLE * FROM pa0001 WHERE pernr = cs_record-pernr
       AND begda <= cs_record-budat
       AND endda >= cs_record-budat.
    cs_record-zz_orgeh = pa0001-orgeh.
    CLEAR t527x.
    SELECT SINGLE * FROM  t527x
           WHERE  sprsl  = sy-langu
           AND    orgeh  = pa0001-orgeh
           AND    endda  >= cs_record-budat
           AND    begda  <= cs_record-budat.
    cs_record-zz_orgtx = t527x-orgtx.
  ENDIF.
ENDIF.

A continuación activamos el programa y activamos el proyecto de ampliación.

NOTA IMPORTANTE: EL CÓDIGO ABAP SE EJECUTARA EN CADA LECTURA DE CADA PARTIDA INDIVIDUAL. ES IMPORTANTE QUE LOS ACCESOS A BASE DE DATOS ESTEN BIEN OPTIMIZADOS PARA NO PENALIZAR EL RENDIMIENTO DE LOS INFORMES.

Mantenimiento de la vista V_TKALV.

El último paso sera realizar el mantenimiento de la vista donde se controlan los campos que aparecen en el listado de las partidas, y que controla el uso de los catalogos (lo que nos permite seleccionar los campos para su visualización, hacer totales, etc). Para ello, desde la transacción SM34, accedemos al diálogo Datos para la estructura de campos, incluyendo los nuevos campos en la estructura KAEP_COAC.

Los campos siempre hay que añadirlos con Grupo de Campos K (Campos de cliente). En el caso de que la lectura del campo tenga alguna dependencia con otro campo (es necesario que ese campo este leido antes de hacer la lectura del siguiente),  habrá que completar la sección Dependencias de selección.

Por ejemplo, el campo ZZ_CNAME (Nombre del empleado), tiene dependencia del campo PERNR (Número de empleado), que ha de estar leido antes.

Una vez completada esta parametrización, el informe esta listo para ser utilizado. En alguna ocasión, hemos de resetear el buffer ALV para que nos aparezcan los nuevos campos. Esto se hace con el report BALVBUFDEL, tal y como se describe en la nota 122975.

Con esta configuración estamos ampliado la funcionalidad de los informes de partidas abiertas de Controlling, permitiendo más criterios de analisis al usuario final sin un gran esfuerzo de desarrollo.