Resumen. Opciones de personalización en nuestro sistema Sap.


En las últimas entradas del blog hemos utilizado las diferentes “puertas abiertas” que deja Sap en sus aplicaciones para que los clientes sean capaces de personalizar sus sistemas en aquellos aspectos en los que la parametrización no es suficiente. Cada uno de los metodos los hemos analizado con un ejemplo práctico para ver las posibilidades de cada uno de ellos. Vamos a hacer un repaso:

  • 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.
Anuncios
Esta entrada fue publicada en Abap, Sap Basis. Guarda el enlace permanente.

7 respuestas a Resumen. Opciones de personalización en nuestro sistema Sap.

  1. ignasi dijo:

    Excelente, gracias por tan buen resumen.

  2. Jaume dijo:

    Buen trabajo !!! Felicidades

  3. Pingback: User-exits, ampliaciones, badis,…: como localizarlas (II). « Notas y trucos SAP (Bitacora)

  4. Pingback: User-exits, ampliaciones, badis,…: como localizarlas (II). « Blog en pruebas

  5. Silvestre Navas dijo:

    Saludos, una consulta, qué efecto puede tener desarrollar un programa de cliente (Z) y construir para este programa una dynpro cuyo número sea igual al de una dynpro que utiliza un programa estándar SAP ?

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s