Truco 7. Uso de User-exits para verificaciones en datos maestros.


En muchas ocasiones necesitamos modificar el comportamiento del estandar de Sap para incluir verificaciones adicionales en los procesos. Por ejemplo, nos puede interesar incluir comprobaciones en los datos maestros (clientes, proveedores, materiales), realizar chequeos adicionales en cualquier otra transacción (contabilizaciones, registro de documentos de ventas o de compras, etc) o intervenir en la forma en que se comporta el sistema (por ejemplo, numeración en facturas o documentos de venta, generación de contabilidad, determinación de proveedor o stocks, calculo de condiciones de precio, etc, etc).

Para este tipo de casuísticas, Sap nos deja una puerta abierta a través de las Exits (concepto que se ha ido ampliando en las ultimas versiones con las Badis y los enhancements en el código). Ya entraremos más adelante en analizar como incluir verificaciones adicionales incluyendo estas últimas funcionalidades.

Ahora nos vamos a centrar en las Exits. En una entrada anterior del blog explicamos como, a través de un desarrollo Abap, localizar las exits que tenemos disponibles en una determinada transacción. También vimos un ejemplo de como configurar una exit que realiza verificaciones adicionales en el proceso de logon al sistema.

Además, en las notas OSS suele haber información sobre las ampliaciones disponibles, y también podemos buscar en la documentación de la transacción SMOD.

EJEMPLO PRACTICO: VERIFICACION ADICIONAL DE NIF DUPLICADOS EN LOS DATOS MAESTROS DE CLIENTES.

Queremos añadir una verificacion adicional en nuestro sistema para evitar que un cliente (con un numero de identificacion fiscal), se duplique en el sistema. Para ellos realizaremos los siguientes pasos:

1) Identificar la transacción y localizar las exits disponibles en la transacción.

El mantenimiento de datos maestros de clientes se realiza con las transacciones FD01 o XD01   (según si estamos dando de alta el cliente solo en finanzas o también en el módulo de ventas). Ejecutamos el report que os he indicado antes, introduciendo el nombre de la transacción, y el resultado es el siguiente:

Desde la misma utilidad accedemos a la transaccion SMOD, donde podemos ver los componentes de esta. Podriamos haber utilizado esta transacción para buscar las exits, tal y como vemos en la imagen. Los objetos en Sap se agrupan en paquetes, y sabiendo el paquete de una aplicación, podemos intentar buscar las ampliaciones disponibles.

Importante: cada exit esta definida de forma que en ella vamos a tener disponible una serie de variables, estructuras de datos o tablas que son las que podremos utilizar posteriormente en el código abap para realizar las diferentes verificaciones o acciones sobre los datos. Las exits son siempre un módulo de función (se pueden ver desde la transacción SE37), con sus correspondientes parametros de import (se reciben en la exit), export (se devuelven) y tablas de datos. La exit lleva un include a un programa Z que no existe y que nosotros crearemos para introducir el código abap propio dentro de el.

2) Creación de un proyecto de ampliación e inclusión de la ampliación localizada.

Creamos el proyecto de ampliación ZCLIENTE con la transacción CMOD, e incluimos en el la ampliación SAPMF02D. En el módulo de función asociado, EXIT_SAPMF02D_001, esta la llamada al include que hemos mencionado (ZXF04U01 ). Lo crearemos haciendo doble clic sobre el. La exit no estara activa en el sistema hasta que no activemos el proyecto de ampliación.

3) Desarrollo del código que implementa la validación.

En la estructura I_KNA1 estamos recibiendo los datos maestros del cliente (la parte general), donde se encuentra su nombre, dirección, datos fiscales, etc. En el código recibiremos estos datos y verificaremos contra la tabla KNA1, que no exista un cliente ya creado con el mismo NIF. En la verificación no se tendrán en cuenta registros de cliente con petición de borrado. El código de nuestra comprobación sería el siguiente:

*&---------------------------------------------------------------------*
 *&  Include           ZXF04U01
 *&---------------------------------------------------------------------*

 * Definición de la tabla maestro de cliente, contra la cual verificaremos.
 TABLES: kna1.
 DATA: lv_kunnr LIKE kna1-kunnr.

 *   Si el pais es ESPAÑA tiene que tener rellenado el NIF normal
 IF  i_kna1-land1 = 'ES' AND i_kna1-stcd1 IS INITIAL.
   MESSAGE e000(zfi). "Campo NIF obligatorio.
 * Chequeamos que no esté repetido el NIF.
 ELSEIF i_kna1-land1 = 'ES' AND i_kna1-stcd1 IS NOT INITIAL.
   CLEAR lv_kunnr.
   SELECT SINGLE kunnr INTO lv_kunnr
       FROM kna1
       WHERE kunnr <> i_kna1-kunnr
       AND   stcd1 = i_kna1-stcd1
 * Si el cliente tiene peticion de borrado no lo tiene que tener
 * en cuenta en la verificacion de nif duplicados.
       and LOEVM ne 'X'.
 * Fin Modif.
 *    Si encontramos un Cliente con el mismo NIF -> ERROR
   IF sy-subrc = 0.
     MESSAGE e008(zsistemas) WITH 'EL cliente' lv_kunnr 'tiene el mismo NIF'.
   ENDIF.
 endif.

La verificación es sencilla, pero podriamos haber incluido otras  como exigir valores obligatorios en campos según el valor de otros campos, actualización de tablas Z, interfases con otros sistemas, etc.

4) Verificación y pruebas. Puesta en productivo.

Activamos el proyecto de ampliación para probarlo en nuestro sistema de pruebas. Hacemos una simulación duplicando un cliente y el sistema nos muestra el siguiente mensaje al intentar dar de alta un nif duplicado:

La verificacion se realiza cuando vamos a grabar, al final de todo el proceso de alta de datos maestros. La verificación también es efectiva cuando estemos modificando los datos maestros existentes.

NOTA SOBRE USER-EXITS

En algunos módulos de Sap (como en Ventas), no todas las exits se gestionan deste las transacciones SMOD/CMOD. Algunas exits estan documentadas en el customizing y son simplemente includes de programa donde nosotros podemos incluir nuestro código (es una especie de modificación del estandar permitida por Sap). Tiene el incoveniente, respecto a los proyectos de ampliación, que se pierde el rastro de las que tenemos implementadas y es más difícil tenerlas documentadas. Ademas, es más fácil activar/desactivar una exit gestionada desde la SMOD (en las otras habrá que comentar todo el código para que no se ejecute si queremos paralizarla en determinadas situaciones, como por ejemplo, en cargas iniciales). En la imagen, se muestran las exits disponibles en el arbol de customizing, en el módulo de ventas.

Para terminar, os dejo algunos links donde se detallan algunas de las user-exits mas frecuentes existentes en los módulos de ventas de Sap (SD), gracias a Saptricks:

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

9 respuestas a Truco 7. Uso de User-exits para verificaciones en datos maestros.

  1. Pingback: Los números de 2012 « Notas y trucos SAP (Bitacora)

  2. PHILLIPS dijo:

    Roberto, un apoyo.
    Me podrías indicar un user exit que me permita activar el precio en moneda USD en la TX ME2L, ya que actualmente solo puedo ver el precio en PEN por el standard.

  3. CARLOS LOPEZ dijo:

    Roberto buenas tardes, existe algun User Exit que me valide en la Tx. MIRO el proveedor del Pedido de Comprar y No me deje ingresar uno distinto ?

  4. CARLOS LOPEZ dijo:

    Roberto buenas tardes, existe algun User Exit que me valide en la Tx. MIRO el proveedor del Pedido de Compras y No me deje ingresar uno distinto ?

    • Hola Carlos:

      Existe la BADI MRM_INVOICE_UPDATE. En el metodo PROCESS_AT_SAVE puedes realizar verificaciones en el momento de grabar la factura.

      Por ejemplo, hacer la verificacion del proveedor que comentabas.

      Un saludo.

  5. CARLOS LOPEZ dijo:

    Gracias Roberto, voy a revisarla

  6. alejandro dijo:

    Hola Roberto, apelo a tus conocimientos para consultarte si existe alguna exit para poder emitir un mensaje de warning durante la carga por MIRO de algunas facturas relacionadas con determinado grupo de artículos (Maestro del material). Desde ya, muchas gracias

    • Hola Alejandro:

      Hay un exit de las que se gestionan con las transacciones SMOD/CMOD:

      LMR1M001 Exit de usuario en la verificación de facturas logística

      Que puedes utilizar para realizar verificaciones antes de grabar la factura. Por ejemplo, yo he usado dentro de esta la llamada a EXIT_SAPLMRMP_010 (include ZXM08U16), para hacer controles de que cosas dejo que se contabilizen o no en la mIRO (en mi caso eran movimientos que incluian varias sociedades).

      Además, toda la información de la factura que se esta grabando esta en las tablas E_TRBKPV para la cabecera y E_TDRSEG para las posiciones (incluyendo los números de pedido), con lo que puedes hacer cualquier verificación a partir de esos datos o de los que puedas obtener a partir de ellos.

      Espero que te sea de utilidad.

      Saludos.

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