Cláusulas condicionales (requirements) en SAP:

Caso específico de un mensaje de texto para

pedido de compras.
Mediante la transacción VOFM Sap permite influír sobre algunos de los procesos
estándar de R/3 proporcionando la posibilidad de desarrollar lógica a medida (Forms
con coding) mediante una serie de objetos que se pueden definir en la transacción
comentada y que Sap llama “Cláusulas condicionales” (requirements en inglés) o
“Fórmulas” dependiendo del caso.

En este informe lo que se va a tratar es el caso específico de la creación de una cláusula

condicional para modificar la salida de las clases de mensaje en los pedidos de compras
como ejemplo, pudiéndose extrapolar su funcionamiento a los demás casos.

Imaginemos que para una misma clase de pedido de compras dependiendo del sistema
lógico de donde se cree nos interese mostrar uno u otro tipo de clase de mensaje
(ZNEU, ZBBP o ninguno en nuestro caso de ejemplo). Esto a priori es imposible
especificarlo mediante las opciones de configuración que proporciona SAP. Lo primero
que hemos de hacer es encontrar en la parametrización dónde se encuentra la
asignación de de la cláusula al elemento a controlar. En nuestro caso sería accediendo a
través de la NACE a los esquemas del pedido de compras llegando a:

La flecha roja indica los que hemos modificado ya que este informe se realizó a
posteriori.

Una vez tenemos ubicada su asignación podemos pasar a su creación mediante la

transacción VOFM. En nuestro caso la definición de la cláusula se realiza a través de los
siguientes pasos:
Cuando se realiza una entrada nueva en la tabla el sistema saltará con la pantalla para la
inserción de clave de modificación de objeto estándar. Esto es perfectamente normal y
es debido a que cuando se introduce una entrada aquí SAP está creando por debajo un
nuevo include con nomenclatura propia de SAP.
Cuando introducimos la clave correcta y grabamos, la entrada nos queda grabada en la
tabla y podremos comprobar que se habrá generado un objeto de tipo include con el
nombre que aparece en la imagen de arriba y transportable.

Ahora si se marca el form correspondiente y se hace clic sobre el segundo de los iconos
de la parte superior de la pantalla se accede directamente al include con la posibilidad
de modificarlo e implementarlo de forma que en nuestro caso particular queda:
Una vez tenemos implementado y activado el código del include se procede a marcar el
flag de Activo de la tabla de la pantalla que se muestra a continuación:
Para ello se elige la posición que interese y se marca donde indica la flecha.

Una vez hecho todo esto se podría asignar al customizing de la pantalla mostrada al
inicio (la de la transacción NACE) y ya la tendríamos implementada en el entorno de
trabajo.

ATENCION!!: Cuando se genera este nuevo include en el entorno de trabajo

automáticamente se asigna el include creado a otro include que en nuestro caso es el
RV61BNNN que a su vez es include de LV61BNNN. Pues bien, estas modificaciones
no son incluidas dentro de la orden de transporte y cuando se realiza posteriormente
el transporte a producción, el nuevo include no funciona de manera correcta (se puede
comprobar de manera fácil mirando que los includes que deberían contener nuestro
nuevo include, lo contienen en desarrollo pero no en producción). Para solucionar esto
es necesario lanzar el report estándar RV80HGEN en producción una vez se ha
transportado las modificaciones.
Si se busca mas información sobre el tema se puede consultar la nota OSS 327220.