Campos nuevos en equipos

lunes, 5 de marzo de 2012

Machine à vapeur Merlin

Esta semana tocaba seguir con webservices, sin embargo, no he tenido tiempo de acabar el artículo. En su lugar vuelvo a escribir sobre cómo ampliar transacciones estándar con campos propios de nuestro cliente. Esta vez, toca hablar sobre equipos y cómo añadir campos sobre ellos. Advierto que este artículo es algo denso y que para poder añadir estos campos debemos tener conocimientos tanto de parametrización como de programación de user exits.

En el ejemplo, nuestro cliente desea ampliar la información de sus equipos con los campos combustible, potencia y funcionamiento.


Parametrización

  • Configuramos el perfil de vista para el objeto técnico equipo. Esto sirve para activar nuevas pestañas en la transacción del equipo, ya que por defecto no existe ningua pestaña de datos de usuario visible sobre esta transacción.
IMG: Mantenimiento y servicio al cliente / Datos maestros en mantenimiento y servicio al cliente / Objetos técnicos / Datos generales / Configurar perfil de vista para objetos técnicos
    • Seleccionamos el perfil para el equipo (no para ubicación).
    • Marcamos actividad y disposición.
    • Añadimos un registro adicional del tipo 150, es decir, del tipo “datos de usuario”.



  • Actualizamos aquellos tipos de equipo que vayan a llevar los campos propios con el perfil de vista que hemos modificado.
IMG: Mantenimiento y servicio al cliente / Datos maestros en mantenimiento y servicio al cliente / Objetos técnicos / Equipos / Tipos de equipo / Actualizar tipo de equipo



User exit

  • Antes de crear la user exit tenemos que añadir los campos a una de las tablas de equipos. Yo los voy a crear bajo la tabla de equipos EQUI. Para ello amplío la tabla mediante el append CI_EQUI. Hacemos doble click sobre CI_EQUI y añadimos los campos y tipos de componentes. Si tenéis duda de cómo crear campos y tipos podéis acudir a un post anterior aquí.
Herramientas / Workbench ABAP / Desarrollo / SE11 – Diccionario ABAP


  • También creamos una serie de flags con el mismo nombre que los campos anteriores pero con tipo flag (caracteres de tamaño 1) bajo el append CI_EQUI_U. Busco la estructura CI_EQUI_U en el diccionario y la modifico.
Herramientas / Workbench ABAP / Desarrollo / SE11 – Diccionario ABAP


  • Una vez tenemos creados nuestros campos podemos empezar a crear nuestra ampliación user exit. Así que creamos un nuevo proyecto de ampliación de equipos. En mi caso utilizaré uno que ya tenía creado.
Herramientas / Workbench ABAP / Utilidades / Ampliaciones / CMOD – Gestión de proyectos
  • Al proyecto le añadimos la ampliación ITOB0001
  • Pulsamos el botón “componentes” y veremos que nuestra ampliación se compone de dos módulos de función (EXIT_SAPLITO0_001 y EXIT_SAPLITO0_002) y cinco pantallas diferentes (de la 1000 a 10004).


  • Entramos en cada módulo de función y activamos sus includes (ZXTOBU01 para la primera función y ZXTOBU02 para la segunda función). En estos includes escribiremos el código ABAP que dotará de información a nuestros campos.
  • Por otro lado, creamos la pantalla 1000 haciendo doble click sobre SAPLITO0 / 1000. En ‘atributos’ le damos una descripción y lo definimos como “subscreen”. Presionamos el botón “Layout” y añadimos nuestros campos en el screen painter.



  • Entramos en el include del segundo módulo de funciones y escribimos nuestro código ABAP. Con este código estamos diciendo a SAP que si el usuario escribe en uno de los campos que aparecen en la pantalla, los valores se deben transferir a la tabla de la base de datos EQUI correspondiente. Los campos de la estructura e_update_flags son los responsables de indicar que los campos han de transferirse a la tabla; los campos de la estructura e_update_data_eq se encargan de soportar la información que introduzca el usuario.
*&---------------------------------------------------------------------*
*&  Include           ZXTOBU02
*&---------------------------------------------------------------------*


e_update_flags_eq-zzcombu = 'X'.
e_update_data_eq-zzcombu  = ci_equi-zzcombu.


e_update_flags_eq-zzfunci = 'X'.
e_update_data_eq-zzfunci  = ci_equi-zzfunci.


e_update_flags_eq-zzpoten = 'X'.
e_update_data_eq-zzpoten  = ci_equi-zzpoten.


e_update_flags_eq-zzunida = 'X'.
e_update_data_eq-zzunida  = 'kW'.
  • Entramos en el include del primer módulo de funciones y escribimos también la parte del código ABAP que toca. En este caso el código ABAP le dirá a SAP que cuando se abra la transacción recupere la información de la tabla y la deje en los campos de la pantalla 1000.
*&---------------------------------------------------------------------*
*&  Include           ZXTOBU01
*&---------------------------------------------------------------------*
TABLES: ci_equi.


e_subscreen_number  = '1000'.


ci_equi-zzcombu     = i_data_equi-zzcombu.
ci_equi-zzcombu     = i_data_equi-zzcombu.
ci_equi-zzfunci     = i_data_equi-zzfunci.
ci_equi-zzpoten     = i_data_equi-zzpoten.
ci_equi-zzunida     = i_data_equi-zzunida.
  • Finalmente, activamos nuestra user exit en el menú Proyecto / Activar.

Resultado

Ya podemos lanzar la transacción de equipos y veremos que hay una nueva pestaña llamada “Datos adicionales 1”. En la pantalla aparecen nuestros nuevos campos.

Logística / Mantenimiento / Gestión de objetos técnicos / Equipo / IE02 – Modificar



Imagen inicial | zigazou76

5 comentarios:

  1. Hola!!, muy buenos todos tus artículos!!
    ¿Que diferencia hay si en vez de agregar estos campos genero clases y características?

    ResponderEliminar
    Respuestas
    1. Nunca he trabajado con ellas, pero a priori no me parece que haya problemas en utilizar la parametrización de clases y características. Sin embargo, yo siempre prefiero no usarlas. A los usuarios les es más engorroso introducir datos a través de clases y características que a través de una pantalla adicional con campos únicos. Por otro lado, a la hora de recuperar la información y mostrarla en informes, siempre me es más fácil hacerlo a través de campos únicos de tabla que tener que entrar a las tablas de clases y características, bastante más complicadas y que además dan tiempos de respuesta mayores.

      Eliminar
  2. Muy útil y bien explicado. Lo que echo a faltar es en el PBO de la dynpro hay que controlar si el campo de cliente es modificable o no, si no, al visualizar un equipo el campo sale como modificable.
    Yo he creado el campo v_activity_type en el include ZXTOBTOP y lo relleno con el valor de la variable global i_activity_type en el include ZXTOBU01. Después en el PBO de la dynpro hago un LOOP AT SCREEN y si v_activity_type = '3' pongo SCREEN-INPUT = 0 para los campos de cliente.
    Saludos

    ResponderEliminar
  3. Buenas noches excelente articulo, es posible que se puedan activar validaciones extras en estas características, como por ejemplo que si son dos fechas estas se validen entre si, una que debe ser siempre mayor a la otra, es posible también en estas características tener otras dependencias como una característica de ciudad y esta tenga información del país que pertenece.

    ResponderEliminar
    Respuestas
    1. Sí, es posible. Tienes que adaptar el código ABAP que incluyas en tu exit.

      Eliminar