Truco 11. Uso de fields exits para verificaciones.


Para aquellos casos en los que queramos introducir validaciones en los campos de las transacciones estandar, y no tengamos disponibles User-exits, o queramos hacerlo de una forma mucho más sencilla, Sap nos ofrece una tecnología llamada Field-exits  o Exits de campo. Sap no recomienda su uso en la actualidad, pero nos puede ser útil en determinadas ocasiones y salvarnos de algo que otro apuro.

Por defecto, el uso de la Field Exits está deshabilitado en el sistema y hay que activarlo cambiando el parámetro de la instancia abap/fieldexit = YES (se mantiene con la transacción RZ10. El cambio del parámetro supone tener que reiniciar la instancia Sap). La field-exits se definen a nivel de elemento de datos y dynpro. Veamos un poco que significa cada uno de ellos:

  • Elemento de datos: son las entidades que utiliza Sap para definir los campos que forman las tablas o estructuras de la base de datos. Un elemento de datos contiene la descripción, información sobre el tipo de datos (cadenas de texto, numérico, fecha) e información adicional, como ayudas de búsqueda asociadas, parámetros de memoria, etc. Las tablas estandar de Sap utilizan los elementos de datos para definir los elementos que las forman, y es recomendable también hacerlo en nuestras tablas Z que creemos.

  • Dynpro: son las pantallas que forman cada una de las transacciones. Cada pantalla lleva asociada una o varias dynpros. Podemos acceder a identificar la dynpro que estamos utilizando en un momento determinado posicionandonos en un campo de la pantalla y pulsando la tecla F1 y a continuación el botón Información técnica. En los campos Programa y Nº Imagen tendremos identificada la pantalla que utiliza la transacción con la que estamos trabajando y también el elemento de datos. Ambos valores son los que necesitaremos para definir nuestra exit.

La creación de la field-exit va a consistir en definir un módulo de función (código abap encapsulado), que tiene la particularidad que solo tiene un parámetro de entrada (llamado INPUT) y uno de salida (llamado OUTPUT). Dentro la función podremos ademas ver el valor de otros campos de la pantalla con la función DYNP_VALUES_READ. Remarcar que dentro de la función no podemos utilizar determinadas sentencias Abap, como Break-point, Call Screen, Call Dialog, Call Transaction, Submit, Commit Work, Rollback Work o Message I (aunque si los mensajes de tipo S,E o W).

Los pasos para crear un field-exit serán los siguientes:

  1. Identificar en la transacción donde queremos introducir nuestro chequeo la dynpro y el elemento de datos donde realizaremos la verificación.
  2. Crear un grupo de función donde introduciremos el módulo de función que contendra nuestro código abap personalizado. Se realiza a través de la transacción SE80. También se podría utilizar un grupo de función existente.
  3. Crear el módulo de función con la transacción SE37. Le daremos el nombre FIELD_EXIT_XXXXXXXXX, donde XXXXXXXX será el nombre del elemento de datos que vamos a validar. En el módulo de función introduciremos el código de validación.
  4. Crear la field-exit y activarla a través del report RSMODPRF, que se ejecuta con la transacción SE38.

Como siempre, vamos a ver todos los pasos completos con un ejemplo práctico. En mi caso, quiero establecer una validación propia en el campo LICITACION que se introduce al crear petición de ofertas de compras (desde la transacción ME41). Este es un campo que nos permite gestionar y analizar de forma conjunta varias peticiones de oferta a proveedores, y realizar la comparación de precios y condiciones. Veamos uno por uno los pasos para configurar el sistema con nuestra propia validación.

1. Identificación de la dynpro y el elemento de datos donde insertar la verificación.

En nuestro caso, accedemos a la transacción ME41, donde se realiza la creación de las peticiones de oferta a proveedores. Nos posiciones en el campo licitación, y con F1 obtenemos el nombre del dynpro (SAPMM06E 0301) y el elemento de datos (SUBMI). Como la verificación también la queremos realizar al modificar las ofertas, comprobamos que en la transacción de modificación (ME42), también se utiliza la misma dynpro.

2. Creación de un grupo de función donde introducir el módulo de función para la validación.

El grupo de función es un contenedor de los diferentes módulos de función que vayamos creando. En este caso, lo vamos a llamar Z_SUBMI, y en el incluiremos todos los módulos de función de field-exits que definamos sobre el elemento de datos SUBMI. Lo creamos con la transacción SE80.

3. Creación del módulo de función.

Desde la transacción SE37 creamos el módulo de función FIELD_EXIT_SUBMI. Al crearlo se nos pide una descripción y el grupo de funciones donde lo queremos incluir. En nuestro caso, lo introduciremos en el grupo de funciones Z_SUBMI que creamos anteriormente. También podriamos crearlo directamente en el paso 4 (lo permite la utilidad).

Sap nos crea el módulo de función que tiene un único campo de entrada (INPUT), donde recibiremos el valor del campo de la dynpro, y un único campo de salida (OUTPUT), donde devolveremos al estándar el valor del campo. En nuestro caso, no vamos a modificar el valor del campo, solo lo vamos a validar, así que siempre asignaremos a OUTPUT el valor de INPUT para que todo quede igual para el usuario. El código de nuestra validación será el siguiente (es una verificación de que el formato de la licitación siga unas determinadas premisas):

FUNCTION FIELD_EXIT_SUBMI_0.
 *"----------------------------------------------------------------------
 *"*"Interfase local
 *"  IMPORTING
 *"     REFERENCE(INPUT)
 *"  EXPORTING
 *"     REFERENCE(OUTPUT)
 *"----------------------------------------------------------------------
 tables: T024.
 data: grupo like v_024-ekgrp.
 * El campo licitacion ha de seguir el siguiente patron
 *
 * YY-XXXZZZZ donde YY será el año
 *                  XXX el grupo de compras
 *                  ZZZZ el número de licitación
   if input+0(2) not between '00' and '99'.
      message e008(zsistemas) with 'Año incorrecto. Formato YY-XXXZZZZ'.
   endif.
   if input+2(1) ne '-'.
      message e008(zsistemas) with 'Introduzca licitación correcta' 'Formato YY-XXXZZZZ'.
   endif.

 * Validación grupo compras.
   grupo = input+3(3).
   clear T024.
   SELECT SINGLE * FROM  T024
          WHERE  EKGRP  = grupo.
   IF sy-subrc ne 0.
      message e008(zsistemas) with 'Grupo compras inexistente' 'Formato YY-XXXZZZZ'.
   ENDIF.
 ENDFUNCTION.

Es una verificación sencilla, pero nos da una idea de las posibilidades de la exit.

4. Creación y activación de la field-exit.

El último paso es asociar el módulo de función al elemento de datos y a la dynpro que hemos localizado antes. Para ello, accedemos a la transacción SE38 y ejecutamos el report RSMODPRF, que es el lugar donde se gestionan las exits de campo. Ejecutamos el report sin introducir ningún criterio de selección y se nos mostrarán las exits definidas. Para crear una nueva, seleccionaremos la opción de menú Exit de campo –> Crear e indicamos el elemento de datos con el que queremos trabajar. A continuación, nos aparecerá en la lista de exit, aunque sin ninguna dynpro asociada y sin activar.

La marcamos y pulsamos el botón Asignar prog/dynpro, y realizamos la asignación de la dynpro donde queremos que se utilice para validar. El último paso será activar la exit desde la opción Exit de campo –> Activar.

NOTA: una exit (módulo de función), se puede asignar a varias dynpros. Si queremos un código personalizado para cada dynpro, entonces tendremos que crear varias exits. Seguiremos la nomenclatura recomendada por Sap, FIELD_EXIT_ELEMENTODATOS_X, donde X será el numero de exit definida sobre el mismo elemento de datos (0 a 9, A a Z).

Una vez activada la exit, podemos seguir trabajando con la transacción de creación o modificación de ofertas. Al introducir un valor en el campo licitación, el sistema nos valida el campo conforme al código abap introducido en el módulo de función.

En el ejemplo, metemos un código de licitación que no cumple el patrón y el sistema nos devuelve error. Hasta que no introduzcamos un código correcto, no va a desaparecer el mensaje de error del sistema. Podriamos haber incluido mensajes de aviso en lugar de error, o incluso corregir los valores que ha introducido el usuario en determinadas ocasiones.

Anuncios
Esta entrada fue publicada en Sap Basis. Guarda el enlace permanente.

4 respuestas a Truco 11. Uso de fields exits para verificaciones.

  1. Pingback: Resumen. Opciones de personalización en nuestro sistema Sap. « Notas y trucos SAP (Bitacora)

  2. Greivin dijo:

    Roberto, excelente artículo. Pero tengo una duda, en los proceso de Upgrade, este tipo de exits ¿Causan algún tipo de problema con los programas estándar de SAP?

    Gracias.

    • Hola,

      en principio no tendrias que tener ningun problema en la migración, aunque, como siempre, habría que tenerlas documentadas y revisarlas despues de migrar.

      Tambien hacer hincapie, como digo en la entrada del blog, que es una tecnologia obsoleta y Sap la va eliminando. Eso hay que tenerlo tambien en cuenta.

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