Truco 124. Algunas cosas que deberiamos de conocer sobre las ordenes de transporte en SAP.

La orden de transporte es el elemento fundamental que nos permite «mover» la parametrización y los elementos de desarrollo o workbench (tablas, elementos de datos, dominios, programas, dynpros, clases, módulos de función, formularios, etc) desde el sistema de Desarrollo hasta los sistemas intermedios de pruebas (Test, Qas) y finalmente al sistema de Producción.

Es fundamental, aunque no seamos consultores técnicos, que tengamos unas nociones básicas sobre las ordenes y que también que seamos conocedores de los problemas más habituales que se producen con las ordenes por no gestionarlas correctamente.

Tipos de Ordenes.

Aunque existen otros tipos de ordenes (por ejemplo, los Hot Packages que utilizamos para las actualizaciones de SAP), normalmente un consultor o desarrollador trabaja principalmente con tres tipos de ordenes:

• Customizing: ordenes del tipo W, son las que utilizamos para registrar los cambios en la parametrización que completamos en el sistema de desarrollo. Normalmente, la parametrización corresponde con entradas en tablas o vistas de actualización, donde guarda la parametrización del sistema realizada a través de la transacción SPRO. Y es una configuración dependiente del mandante en el que estemos conectados.
• Workbench: ordenes del tipo K, son las utilizadas por los desarrolladores cuando realizar cualquier creación o modificación de los objetos de desarrollo (reports abap, clases, dynpros, formularios, objetos del diccionario de datos, ayudas de busqueda, cds, vistas, etc., etc.). Las ordenes de workbench registran objetos que son independientes de mandante. La parametrización de objetos que no depeden del mandante también se incluyen en ordenes de este tipo.
• Transporte de copias: nos permite realizar el transporte de objetos de desarrollo o parametrización, incluidos en otras ordenes, sin necesidad de liberar las ordenes originales. Por ejemplo, puede ser útil para probar un desarrollo en un sistema de test sin liberar la orden en desarrollo donde estamos realizando todos los cambios. También se puede utilizar con ordenes de parametrización.

Cuando creamos una orden del tipo Transporte de copias, la orden se crea vacía y nosotros a continuación seleccionamos los objetos que queremos incluir en ella para su transporte para la realización de pruebas (normalmente los objetos incluidos en uno o varias ordenes adicionales que todavia no hemos liberado).

Elementos de una orden.

Normalmente, en una orden veremos al menos el número de orden principal y una o varias tareas (asociadas a los diferentes usuarios que intervienen en un proceso de parametrización del sistema o de creación de objetos de desarrollo).

Tanto la cabecera como las tareas pueden incluir objetos, aunque lo habitual es que esten en cada una de la tareas.

Para que un usuario pueda incluir sus objetos en una orden de transporte, habrá que crear una tarea para el dentro de la orden. Es tan sencillo como acceder a la transacción SE09/SE10, seleccionar la orden, y con el botón derecho seleccionar la opción «Añadir empleado».

El sistema nos solicitará el identificador del usuario que queremos incluir y se creará una tarea para el dentro de la orden.

Modificar el titular de una tarea o de la orden.

En ocasiones, las ordenes de transporte o sus tareas estan asociadas a usuarios incorrectos (usuarios borrados o que dejaron la compañia). En las ordenes o tareas que no esten liberadas, podremos modificar el titular sin problema desde la transacción SE09/SE10, seleccionando el elemento y, desde botón derecho, opción «Modificar titular». Esto vale tanto para la tarea como para la orden en si.

Que ocurre cuando liberamos una orden.

Para liberar una orden de transporte, primero hemos de liberar todas las tareas incluidas en ella, con el menú contextual (botón derecho) o pulsando la tecla F9.

A continuación, repetiremos la acción con la orden propiamente dicha, momento en el nos aparecerá un dialogo indicando que se ha realizado la liberación de la orden.

En este momento, se escribe, a nivel de sistema operativo, en el directorio de transporte, dos ficheros que incluyen todos los elementos incluidos en la orden. Los ficheros que se escriben son los siguientes:

• Directorio data: fichero RXXXXXX.YYY, donde XXXXXX es el número de la orden y YYY el id de la instancia donde hemos realizado la creación de la orden. Es el fichero binario que incluye todos los cambios realizados.
• Directorio cofiles: fichero KXXXXXX.YYY, con el mismo significado. Es el fichero de control.

Conocer la existencia de estos ficheros nos puede ser de utilidad para mover, por ejemplo, un desarrollo o parametrización a otro sistema que no este conectado al sistema de transporte (por ejemplo, un sandbox o un sistema de pruebas autonomo).

Igualmente, es importante entender que es el momento de la liberación cuando el sistema accede a la base de datos y lee la parametrización o desarrollos realizados, y se guarda una copia de esos elementos a nivel de fichero. Y esa copia será la que se transmita al sistema destino cuando hagamos la importación con la transacción STMS. Si entendemos bien esto, nos evitaremos muchos problemas. Por ejemplo, yo puedo haber realizado una parametrización del control de copia en la facturación (transacción VTFL) y haberla incluido en una orden. Si un compañero, antes de liberar la orden, realiza otro cambio sobre la misma configuración, aunque la incluya en otra orden, cuando yo libere mi orden me llevaré los cambios de mi compañero. Algo parecido ocurrirá con objetos de desarrollo (workbench), aunque en ese caso Sap no nos deja tocar el mismo objeto en dos ordenes abiertas a la vez (en ese caso siempre se incluyen todos los cambios, aunque sean de diferentes usuarios, en la misma orden, con una tarea para cada uno de los usuarios).

Ver los objetos que conforman una orden.

Cuando accedemos al detalle de la orden o tarea (SE09/SE10), podemos ver la lista de objetos incluidos en ella con sus nombre técnicos.

Para hacernos una idea, podemos ver en la imagen un ejemplo de objetos de una orden de parametrización.

En esta otra imagen una orden de workbench, con los objetos de desarrollo incluidos.

Cada uno de los objetos incluidos en la orden tiene un nombre técnico, que se identifica con tres elementos:

• Id. Programa: normalmente veremos el valor R3TR, aunque cuando transportarmos traducciones de textos podremos ver el valor LANG o valores que nos indican comentarios.
• Tipo de Objeto: identifica el tipo de objeto que estamos incluyendo en la orden. Hay más de mil tipos de objetos diferentes.

Algunos de los tipos de objetos más habituales para un consultor funcional serán TABU (contenido de una tabla de parametrización), VDAT (vista de parametrización), TDAT, CDAT (cluster de vistas de parametrización), ACGR (roles de autorizaciones), etc.

• Nombre del objeto: el nombre que identifica al objeto incluido en la orden.

En la orden también puede aparecer el objeto de parametrización asignado a cada elemento de la orden (en el campo llamado Actividad IMG). Ademas para cada elemento incluido dentro de una orden, podremos ver, para los objetos asociados a contenido de tablas o vistas, los registros de datos asociados pulsando el icono de la Llave (Objeto con claves).

Es interesante conocer esto, pues lo que veamos en ese detalle serán los valores de configuración que realmente se van a transportar cuando liberemos la orden de transporte. Nos permite realizar chequeos o analizar problemas cuando algo ha fallado después del transporte de una configuración.

Fusionar ordenes.

Tanto en un proyecto como en las tareas de soporte habituales, es posible que hayamos creado varios ordenes de transporte donde hemos ido incluyendo elementos. Llegado el momento de gestionar el paso de los cambios a productivo, el disponer de varias ordenes puede ser confuso de cara a la importación de la orden en el destino (objetos dependientes, orden de la carga, etc).

Para evitar problemas, una solución puede ser el fusionar una o varias ordenes en una única orden, de forma que realizaremos el transporte completo de todos los objetos en un único «contenedor».

Para realizar la fusión de dos ordenes, usuaremos el menú contextual (opción «Fusionar ordenes»).

El sistema nos pedirá la orden origen y la orden destino (donde se realizará la fusión). La orden origen se eliminará una vez completado el proceso de fusión.

Esta opción se utiliza mucho en los proyectos cuando diferentes consultores han estado trabajando en la configuración con ordenes individuales y necesitamos incluir todos los objetos en la misma orden, dentro de las tareas de preparación de la subida de los cambios a productivo.

Incluir elementos de una orden en otra.

Además de la fusión de ordenes, otra opción muy útil es la de incluir en una orden de transporte objetos de otras. Esto lo realizaremos desde el menú contextual, con la opción «Incluir objetos».

Nos aparecerá un popup desde el cual dispondremos de diferentes opciones para incluir nuevos objetos en la orden:

• Objetos de una orden.
• Objetos de varias ordenes.
• Selección libre de objetos.
• Etc.

Cuando incluimos en una orden objetos de otra orden, podremos ver en la cabecera de la orden entradas de este tipo, que nos indican que se toman objetos de otra orden. Y estos objetos serán incluidos cuando liberemos la orden para el transporte.

De forma que vemos que realmente se esta guardando un «puntero» a la otra orden.

Incluir la ejecución de un programa tras el transporte de una orden.

Existen tareas de configuración del sistema, que pueden requerir la ejecución de un determinado programa una vez se transportan los cambios a los sistemas de test o de productivo. Por ejemplo, cuando creamos rutinas con la transacción VOFM (como rutinas de calculo de precio, condiciones, etc), una vez se pasan los cambios a productivo, hay que ejecutar el report RV80HGEN para la regeneración de los pools de programas y asi, de esta forma, la rutina puede ser utilizada en el sistema.

Si queremos evitar tener que hacer esta ejecución manualmente, podemos incluirla en la orden de transporte. Para ello, iremos a la orden de transporte (SE09/SE10), opción Modificiar, e incluiremos un nuevo objeto con los valores:

Cuando transportemos la orden al siguiente sistema, Sap ejecutará el programa indicado una vez completadas las tareas de importación de los elementos de orden.

Una forma fácil de no olvidarnos de tareas que son obligatorias, incluso puede valer para nuestros propios desarrollos.

Abrir una orden de transporte ya liberada.

Una orden de transporte ya liberada, ha generado ya los correspondientes archivos en el directorio de transporte (como hemos visto antes) y en principio no es posible volver asignar mas cambios en ella.

En el caso de que fuese necesario «revertir» la liberación de una orden, podriamos utilizar, desde la transacción SE38 el report RDDIT076. Indicaremos la orden de transporte y ejecutaremos.

Al acceder veremos la orden de transporte y sus tareas asociadas, con información de su estado. Una orden ya liberada estará en estado «R – Liberado».

Para volver abrir la orden, cambiaremos primero el status de orden, indicando el valor «D – Modificable». A continuación, repetiremos la acción para todas las tareas que incluya y grabaremos. Esta orden estará lista para seguir trabajando con ella e incluyendo objetos hasta que la volvamos a liberar, aunque será necesario modificar la orden con la transacción SE09/SE10 y eliminar el atributo EXPORT_TIMESTAMP, ya que sino no será posible volverla a liberar.

Nota: no se recomienda realizar esta tarea más que en casos excepcionales, por las implicaciones que podría tener incluir en una orden ya liberada (y puede que transportada), objetos nuevos y volver a realizar un ciclo completo de transporte sin verificar que pueda haber otras ordenes dependientes afectadas.

Borrar objetos o una orden.

En ocasiones hemos realizado pruebas en un sistema y hemos incluido cambios en una orden de tranporte, que finalmente no desearemos transportar a productivo.

Con cuidado, para no evitar inconsistencias, es posible borrar objetos de una orden desde la SE09/SE10. Buscaremos el lugar donde esta incluido el objeto, y pulsaremos la opción de modificar:

Una vez localizados los objetos a eliminar, los seleccionaremos y pulsaremos la opción de eliminar. De esta forma, estos objetos quedarán excluidos del transporte y no se moveran al sistema destino. Y como siempre, utilizar con mucho cuidado para no generar un problema cuando estamos intentando solucionar otro.

Buscar objetos en las ordenes.

Es muy habitual que se produzcan problemas cuando se transportan los cambios a productivo, tanto relacionados con customizing o objetos de desarrollo. Cuando ocurre esto, necesitamos una herramienta ágil para poder buscar los objetos en las ordenes y poder identificar cual es el problema que se ha producido.

Para ello, disponemos de la transacción SE03, que nos sirve de Menú para todas las tareas relacionadas con las ordenes.

En mi caso, voy a utilizar la opción «Buscar objetos en ordenes» para localizar las ordenes que han tocado una determinada tabla de parametrización.

Al seleccionar esta opción, nos aparece un report donde podemos indicar los objetos que queremos buscar y el ambito de la busqueda (tipos de ordenes, status de las ordenes, numeros de orden, fecha, usuario, etc).

Si tenemos un conocimiento mínimo de los objetos más habituales, podremos sacarle partido y encontrar el origen de problemas relacionados con el transporte. Cuando ejecutemos el informe, nos devolverá la lista de ordenes que cumplan las condiciones.

Problemas más habituales con las ordenes.

Por su propia forma de funcionamiento, las ordenes de transporte son una fuente continua de problemas, que normalmente se solucionan con unas buenas prácticas e intentando evitar determinadas cosas. Lo primero de todo, es entender dos cosas básicas:

• Ordenes de parametrización: los valores que se exportan a los ficheros de las ordenes de transporte son los que tienen las tablas de configuración en el momento de realizar la exportación de la orden. Esto significa que yo puedo haber realizado una parametrización y haberla incluido en la orden (tendra su correspondiente objeto con sus valores de claves). Pero otra persona puede posteriormente haber cambiado esa configuración y haberla introducido en otra orden. Cuando yo libere la orden, me llevaré los cambios de la otra persona, no los valores que yo «pensaba» que se habian incluido.
• Ordenes de workbench: normalmente, cuando transporte objetos de desarrollo, me llevaré el objeto de desarrollo completo en el momento de liberar la orden (por ejemplo, en un programa abap me llevo todo el código del programa).

Teniendo en cuenta estas dos cosas, algunos de los problemas más habituales son:

1. Transportes incompletos: no nos llevamos todas las ordenes necesarias, y nos dejemos objetos dependientes sin transportar. Esto se puede producir tanto en ordenes de custo como de workbench.
2. Secuencia de importación incorrecta: al importar las ordenes, no seguimos la secuencia correcta, lo que implica que se machaquen objetos con versiones anteriores, que al final dan como resultado que no tengamos en productivo/test la misma configuración que en el sistema de desarrollo. Normalmente volviendo a importar en el orden correcto se soluciona el problema.
3. Transportes incorrectos: porque no estamos llevando la configuración realizada por nosotros o nos estamos llevando cambios de otros consultores incluidos en una orden. Esto es muy habitual, y puede producir problemas muy graves, pudiendo producir un fallo en la funcionalidad del sistema de productivo por transportes incompletos o erróneos.
4. Transportes de calendarios o rangos de números: estos dos elementos son muy delicados y os recomiendo que ante que cualquier duda, consulteis a los consultores de Basis o los veteranos de vuestra empresa. Por ejemplo, los calendarios se transportan completos, si hay cualquier diferencia entre el sistema de DES y PROD, al transportar machacaremos la configuración de los calendarios (ver entrada del blog donde hablabamos de esto).
5. Ordenes de transporte antiguas: es muy habitual que en el sistema de desarrollo vayan quedando ordenes de consultores que pasaron por la empresa, pruebas que se fueron realizando, funcionalidad que nunca se llego a subir a productivo. Es importante tener controladas esta ordenes e incluso intentar hacer limpieza para evitar problemas o errores en el futuro.
6. Transporte de parametrización en desarrollo: algunas tareas funcionales, como la de abrir los periodos contables, es posible que el sistema nos pida orden de transporte en un entorno de desarrollo. Es importante no incluir estos cambios en una orden en la que estemos realizando parametrización, y lo incluyamos en una orden de las llamadas «No transportar». Asi también nos evitaremos algún susto.

Mi consejo, para evitar estos problemas, es intentar ser meticuloso y metódico, revisar bien las ordenes en caso de duda y sobre todo, disponer de unas buenas prácticas en la gestión del transporte de las que sean conocedores todas las personas que realizan cambios en nuestro sistema.

Bibliografía.

https://blogs.sap.com/2020/05/26/7-secrets-about-sap-transportation-request-that-every-functional-consultant-should-knows/

https://blogs.sap.com/2016/06/16/xpra-execute-abap-program-automatically-after-transport-request-import/

https://www.kodyaz.com/sap-abap/execute-abap-program-after-transport-request-import.aspx

Truco 123. Encontrar la ayuda de búsqueda asociada a un campo en cualquier transacción. Buscar cadenas en el código abap.

Hoy os voy a compartir un par de trucos más técnicos, que seguramente puedan ser de utilidad a la gente que hace desarrollos, aunque también a los consultores funcionales que estan preparando especificaciones para desarrollos a medida o ampliaciones del estandar.

Encontrar la ayuda de búsqueda asociada a cualquier transacción.

Empecemos con las ayudas de búsqueda. Como sabeís, en el estandar tenemos multitud de ayudas de búsqueda o matchcodes, que nos permiten buscar los valores de datos maestros, organizativos o de documentos cuando estamos realizando algún proceso funcional. Cuando nos posicionamos en un campo, pulsando F4 o el icono de acceso a la ayuda, el sistema nos muestra un dialogo con una o varias ayudas de búsqueda (ayuda compuesta), la cual nos permite filtrar en el elemento, localizar los valores y llevarnos uno o varios de ellos a la transacción en la que nos encontremos.

En muchas ocasiones, estas ayudas estandar no son suficientes y necesitamos ampliarlas con nuestras propias ayudas. En un post anterior en el blog, hablamos de como realizar esta tarea de ampliación. Ahi explicamos todos los pasos para hacerlo.

Truco 6. Ampliacion de ayudas de busqueda (Matchcode).

El principal problema con el que nos solemos encontrar para ampliar una ayuda de búsqueda estandar es localizar su nombre y encontrar el sitio donde «colocar» nuestra ayuda Z. En muchas ocasiones, es muy sencillo, y basta con pulsar F1 en el campo y mirar los opciones técnicas en el campo en cuestión.

Pero en la mayoria de ocasiones, esto no funciona y no es tan sencillo localizar la ayuda, para luego poder ampliarla a través de la SE11. Para esto, vamos a usar un truco realizando DEBUG, que hemos conocido gracias Arghadip Kar, un gran compartidor de conocimiento Sap.

El truco consiste en poner un punto de break-point en el módulo de función DD_SHLP_CALL_FROM_DYNP (transacción SE37). En mi ejemplo, he accedido a la transacción ME21N (creación de pedidos) y he realizado una búsqueda por el campo material.

El break-point lo he situado tras el perform DETERMINE_SHLP_OF_FIELD, en el modulo de función indicado. Y en ese lugar, en la variable SHLP_TOP-SHLPNAME tengo identificado el nombre de la ayuda de búsqueda.

En mi ejemplo, la ayuda se llama MAT1. Ya podré acceder a la transcción SE11 y realizar los pasos para ampliar la ayuda de búsqueda estandar. Normalmente, en las ayudas de búsqueda habrá ayudas de busqueda compuestas, y en una de ellas podremos añadir nuestras propias ayudas de búsqueda Z.

En mi ejemplo, he añadido una nueva de búsqueda para localizar materiales por tipo de material, excluyendo los materiales borrados o con un status general de centro (MSTAE) distinto de blanco.

La ayuda la creado a partir de la ayuda MAT1T_E y la he incluido en la ayuda compuesta MAT1T, que es la definida para hacer búsquedas por tipo de material.

Este procedimiento debería funcionar casi siempre, en caso contrario, ya os recomiendo solicitar ayuda a un Abaper para localizarla.

Buscar cadenas en el codigo abap. Transacción EWK1 y otras alternativas.

Para terminar, un truco muy rápido y útil que nos permite localizar en cualquier programa abap una determinada cadena, y que hemos conocido gracias a Enrique Higuero. Para ellos podemos usar la transacción EWK1.

Con una interfaz muy sencilla, indicaremos los programas en donde buscar (se pueden indicar caracteres comodin como el *), la cadenas que queremos encontrar y algunos parametros para ajustar la búsqueda. En la opción Ambito de búsqueda se pueden añadir mas lugares donde buscar.

Al ejecutar el programa, el sistema nos devolverá la lista de programas donde se localize la cadena. En mi ejemplo, estaba buscando «Hardcode» en el código para sustituirlo para una tabla de parametros y realizar una buena práctica de desarrollo.

Esta opción es similar a la que podemos realizar desde la SE38, una vez estamos dentro del código, con la opción Buscar.

Como curiosidad, indicar que la transacción EWK1 fue desarrollada por Sap como una herramienta para la migración al Euro. Ya ha llovido un poco desde eso, unos 20 años!!!!

Además, tenemos otras alternativas a esta transacción, que os detallo (pueden variar según la versión de Sap en la que nos encontremos):

• Report RKCTSEAR.
• Transacción CODE_SCANNER: es esta podemos hacer búsquedas trabajando tambien con los paquetes en los criterios de selección, tal y como veis en la imagen siguiente. Además nos permite excluir de la búsqueda a las lineas de comentarios o visualizar programas en los que no se encuentra el patron de búsqueda.

• Report RPR_ABAP_SOURCE_SCAN: es uno de los más completos para realizar búsquedas, y el que os recomiendo si quereis hacer búsquedas más complejas.

Bibliografía.

https://blogs.sap.com/2020/08/25/how-to-find-a-search-help-behind-a-transaction-code-in-sap/

Different ways to find any string or hard coded values in sap abap code.

Truco 122. Algunas utilidades para obtener información de tablas.

En el trabajo día a día con Sap como consultor funcional o técnico, es imprescindible tener un conocimiento mínimo del módelo de datos del sistema y conocer las tablas más importantes y sus relaciones. Eso nos permite, por ejemplo:

• Obtener información de los datos maestros o documentos ante cualquier requerimiento.
• Poder realizar comprobaciones de una forma rápida. Por ejemplo, despues de haber terminado unas cargas iniciales, comprobación de procesos de integración, analisis de incidencias, pruebas de nuevos desarrollos o cambios en la parametrización, etc.
• Preparar especificaciones para los desarrolladores, donde indicamos que chequeos o condiciones se han de cumplir en un determinado desarrollo.
• Conocer la lógica de funcionamiento de la aplicación y como los procesos funcionales se traducen en datos registrados en la base de datos.

En Intenert hay multitud de información sobre las tablas más importantes existentes en cada módulo y podeís encontrar sin problema entradas donde se enumeran con mayor o menor detalle las tablas de cada módulo o ambito funcional especifico (por ejemplo, MM, SD, etc.).

Pero siempre es útil conocer algunos otros pequeños trucos que nos permitan localizar las tablas estandar/Z u otros elementos, y que nos puedan sacar de algún apuro. Aquí los dejo.

Transacción SE16T. Encontrar las tablas de aplicacion sin conocer nada del sistema.

Hablamos hace tiempo de las nuevas transacciones SE16X y como utilizar la transacción SE16T para buscar tablas en el sistema.

Básicamente, seleccionamos la función de búsqueda de tablas e indicamos el concepto a buscar (pudiendo seleccionar búsqueda por texto o por nombres de campo).

El sistema nos devuelve la lista de tablas que cumplen las condiciones.

Vista DD03VV. Localizar tablas por campos, elementos de datos o dominios.

La vista DD03VV ( Vista de campos tabla – Sistema Info ) nos permite realizar la busqueda en el diccionario de datos por nombre de tabla, campo, elemento de datos o dominio. Yo la suelo utilizar para buscar las tablas Z en un sistema o localizar tablas de parametrización que se que utilizan un determinado elemento de datos o dominio.

Podemos consultarla con la transacción SE16N. En mi ejemplo, estoy buscando tablas Z que tengan el elemento de datos del centro (*WERK*). Es importante indicar la clase de tabla del tipo TRANSP para limitar los resultados de búsqueda a tablas de datos transparentes.

En los resultados obtengo toda la información para localizar las tablas que estoy buscando. Posteriormente podré acceder a la SE11 para ver la definición de las tablas y la lista completa de sus campos.

También puede ser interesante conocer la tabla DD03L, donde se guarda la información de los campos que contienen una tabla.

Tabla TCDOB. Obtener el objeto del log de modificaciones de una tabla.

El log de modificaciones de una tabla nos permite registrar los cambios que se realizan en los datos y luego poder consultarlos, normalmente desde las misma funcionalidad, de forma que podemos ver quien realizo los cambios, cuales fueron estos (valores anteriores/valores nuevos) y en que momento.

La información de modificaciones se registra en las tablas CDHDR y CDPOS. La primera tabla contiene un número de documento de modificación, estando en la CDPOS el detalle de los cambios, campo por campo. Los cambios se registran usando un identificador de objeto (código que identifica su tipología), el valor del objeto (el número del documento o datos maestro concreto) y un documento de modificación.

Recordad que podemos activar el log de modificaciones de una tabla estandar o una tabla Z desde las opciones técnicas en la transacción SE11 del diccionario de datos (siempre con los pertinentes chequeos con el equipo de desarrollo o basis para no provocar problemas de rendimiento en el sistema).

Cuando necesitamos obtener de forma másiva los cambios que se han realizado en un objeto, los más complicado es localizar el nombre del objeto (campo OBJECTCLAS), con el que se guardan los cambios en las tabla.

Para localizar este nombre de objeto, utilizaremos la tabla TCDOB, a través de la SE16N.

En mi ejemplo, estoy localizando la clase de objeto con la que se guardan los cambios en los Business Partners que creamos desde la transacción BP (tabla BUT000).

El objeto con el que se guardaran los cambios en el log de modificaciones será el BUPA_BUP. Con ese valor ya podremos atacar directamente las tablas para obtener la información requerida y visualizar los cambios realizados en los elementos objeto del análisis.

Obtener la vista de actualizacion para una tabla de parametrización.

Otra necesidad muy habitual es tener localizar las vistas de parametrización asociadas a una tabla. Es decir, tenemos la tabla donde esta la parametrización, pero no recordamos el lugar en la SPRO donde realizar los cambios.

Para esto, tenemos dos opciones desde la transacción SM30. Una vez en la transacción, indicaremos el nombre de la tabla (en mi ejemplo, la tabla T001 Almacenes en Gestión de Materiales) y:

1) Customizing: realiza una búsqueda en la configuración de sistema y nos ofrece una lista más o menos útil con los puntos de parametrización relacionados con la tabla.

2) Buscar diálogo de búsqueda: nos devuelve la vista de actualización de la tabla, que corresponden a los diferentes objetos de parametrización y que podremos acceder directamente desde la SM30.

Encontrar las tablas que son llamadas en un programa.

En ocasiones la cosa se complica y necesitamos saber las tablas estandar o de cliente que se utilizan en un determinado programa o transacción. En este caso, tenemos disponibles varias alternativas para localizar las tablas implicadas.

La forma más completa de obtener información es realizar una traza SQL utilizando la transacción ST05. Es importante activar la traza con la opción de filtro, ya que podemos colapsar el sistema con la traza si no se limitan el ámbito de este análisis.

En mi ejemplo, estoy haciendo la traza de un determinado usuario y con una determinada transacción.

A continuación realizaremos el trabajo funcional con el usuario filtrado (hemos accedido a consultar un pedido en la transacción ME22N y le hemos añadido una posición).

Al finalizar, desactivaremos la traza y procederemos a consultar los resultados de esta con la opción «Display Trace».

El sistema nos mostrará una lista de todas las tablas que ha ido leyendo durante la ejecución del programa

Existe otra alternativa para realizar traza con la transacción ANST_SEARCH_TOOL.

Al ejecutar, el sistema nos llevará a la transacción elegida, donde realizaremos la operativa deseada. Al concluir, volveremos a la ANST_SEARCH_TOOL, donde podremos ver la lista de resultados.

Seleccionando la opción de Tables, podremos ver la lista de todas las tablas utilizadas en la transacción, o solo las tablas de parametrización.

Encontrar las CDS asociadas a una tabla SAP.

Desde la transacción SE11, podremos localizar las CDS que se han creado utilizando la tabla, con la opción «Referencia de utilización», seleccionado el area de utilización «Data Definitions».

El sistema nos mostará la lista de DDL.

En el detalle podremos ver el nombre de la vista e información de su definición (es aconsejable utilizar Eclipe para ver la información completa).

Bibliografia.

http://thinkdoforward.com/sap-s-hana-diesen-datenbankview-solltest-du-dir-merken-dd03vv/

https://blogs.sap.com/2020/07/15/how-to-find-sap-table-by-just-knowing-nothing-about-sap-its-true/

https://blogs.sap.com/2020/07/24/how-to-find-change-document-object-from-table-name/

https://blogs.sap.com/2014/01/17/find-changes-logs-for-a-table-using-sm30/

https://blogs.sap.com/2020/08/25/how-to-find-a-search-help-behind-a-transaction-code-in-sap/

https://blogs.sap.com/2020/07/15/in-sap-how-to-find-a-table-behind-a-transaction-code/

Truco 121. Auditoria con la transacción ST13.

Hemos conocido gracias a Diego Muñoz una interesante herramienta de auditoria, que viene incluida en ST-A/PI (Servicetools for SAP Basis) y que podemos lanzar desde la transacción ST13. Al parecer, es una herramienta interna de Sap, relacionada con Solution Manager.

Básicamente, la herramienta dispone de una serie de informes predefinidos que nos permiten analizar el uso de procesos de negocio en el sistema. En mi caso, estoy en plenas pruebas funcionables de una migración de sistema a Rise Cloud Private y me ha sido muy útil para validar las pruebas realizadas por los usuarios en los diferentes módulos implantados y poder verificar los documentos creados.

Otros posibles escenarios en los que nos podría venir bien la herramienta:

• Verificación tras cargas iniciales de datos en un proyecto de implantación o un rollout.
• Auditoria de procesos.
• Verificación tras sesiones de formación o validaciones de nuevas funcionalidades o cambios en el sistema.
• Tareas de mantenimiento regular (por ejemplo, control de rangos de números).

Algunas de las cosas que podemos analizar son (lo más destacado):

• Compras: documentos/lineas de documento creadas, lineas de pedido sin flag de entrega completa o factura final, cambios en cabecera o posiciones de documentos, control de entrega temprano/tardio, lineas con cantidad recibida mayor que cantidad factura, pedidos sin referencia a contrato o documentos en un workflow activo/erroneo, uso de esquema de cálculo o condiciones de precio en documentos, etc.
• Ventas: documentos/lineas de documento creadas, pedidos abiertos, porcentaje de pedidos abierto, documentos incompletos, pedidos retrasados, documentos con bloqueo de factura, documentos sin lineas, documentos modificados, uso de esquema de cálculo o condiciones de precio en documentos, etc.
• Finanzas: numero de documentos contables creados, numero de posiciones creadas, cambios en documentos, documentos anulados, documentos contables por clase de documento o sociedad, partidas abiertos por cuenta de mayor/cliente/proveedor, documentos preliminares, activos sin contabilizaciones, documentos bloqueados para el pago, documentos sin metodo de pago, etc.
• Logistic Execution: entregas entrantes/salida creadas, entregas pendientes, entregas incompletas, documentos de transporte creados o en un cierto estado, cambios en documentos, etc.
• Maestros: cambios en el maestro de clientes o proveedores, uso de materiales, clientes o proveedores en documentos, alineación de la condición de pago en el maetro respecto a los documentos, etc.
• ……

Estos son solo algunos de los report de analisis que tenemos disponibles, pero como podeís ver, tenemos para analizar casi cualquier cosa que nos soliciten relacionada con nuestros procesos de negocio. En muchos de los informes podremos realizar filtros por fechas o por caracteristicas de los procesos de negocio (unidades organizativas, clases de documento, usuario), teniendo incluso la posibilidad de navegar a los documentos individuales o datos maestros.

Para utilizar la herramienta, accederemos a la transacción ST13, seleccionando el conjunto de reports llamado TBI_REPORTS y ya estaremos en el menú donde podremos realizar la auditoria en los diferentes módulos o procesos del sistema.

Tenemos areas de aplicación disponible en el monitor para todos los módulos y ambitos funcionales de Sap. Podemos acceder a los reports seleccionando el correspondiente Objeto de Monitorización, que corresponde a cada uno de los reports individuales (tenemos disponibles casi mil).

O bien indicando el Area de Aplicación, y a continuación el correspondiente report de análisis a traves de las llamadas Keyfigure, tal y como vemos en la imagen.

Ejemplo de analisis. Posiciones de pedido de compra creados en un periodo.

Accedemos al area de aplicación Sourcing & Procurement y seleccionamos el keyfigure 01 – Purchase order items created. En mi caso, quiero obtener las lineas de pedido de compra creadas en los últimos 30 dias (también podriamos indicar fechas).

 Procesamos y el sistema nos devuelve el total de posiciones creados, pudiendo navegar a continuación a los documentos creados:

Ejemplo de análisis. Rangos de números que han superado un determinado porcentaje de uso.

Para ello seleccionamos el area de aplicación Cross Application y el keyfigure 02 Max fill level for numer range interval. En mi caso, indico rangos de número que superen un determinado porcentaje.

El sistema me devuelve aquellos rangos que han superado el porcentaje indicado.

Ejemplo de análisis. Documentos de ventas con bloqueo de factura.

Seleccionamos el area funcional Sales y el keyfigure 09 – Sales documentos with billing block. En el ejemplo, indicamos documentos mas nuevos de 365 días. Y obtenemos como resultado el total de documentos bloqueados para la facturación, y en el detalle la información del documentos y sus status.

Ejemplo de análisis. Cambios en los datos de proveedores en un periodo.

En este caso, seleccionamos el area de aplicación Master Data Management y el keyfigure Changes to Vendor Master, indicando una sociedad y 365 de periodo.

El sistema nos devuelve la lista de cambios (total) y el detalle de los campos modificados (valor anterior/valor nuevo, campos modificado, fecha de la modificación, usuario, etc).

Estos son solo algunos ejemplos de las cosas que podemos auditar con la transacción ST13. Como mínimo, conocerla y tenerla en cuenta para esas comprobaciones u obtenciones de información que a veces son tan tediosas, y para las que tenemos que llegar a conocer la estructura de tablas de sap y el diccionario de campos si no tuvieramos esta herramienta disponible.

Nota: en la misma transacción hay otros monitores interesantes. Nos ha llamado la atención el llamado TABLE_ANALYSIS, que nos explica como usar Arghadip Kar en los blogs de Sap, así como otro disponible para analizar cambios en los programas Abap.

Bibliografía:

https://www.linkedin.com/posts/diego-mu%C3%B1oz-l%C3%B3pez-4a06a665_st13-activity-6955094048428687360-ZoPf?utm_source=share&utm_medium=member_desktop

https://blogs.sap.com/2020/08/22/how-to-do-table-counts-for-multiple-tables-at-one-go/

https://blogs.sap.com/2015/12/02/backoffice-tools-change-analysis-abap-in-st13/

2971611 – ST-A/PI 01U: Customizing error in «Purchase Orders» key figures (S/4 HANA)

2197502 – BPMon/BPA: How to test & execute data collection manually in ST13: TBI_REPORTS

https://go.support.sap.com/kpicatalog/?sap-language=EN

Truco 120. Transacciones para la gestión de IDOCs. Nuevo monitor WLF_IDOC, la «navaja suiza» de los Idocs.

En los últimos años, los Idocs me han perseguido por todos las empresas en las que he trabajado. En un mundo cada vez más interconectado, los idocs son un elemento fundamental para gestionar las comunicaciones de entrada / salida con sistemas propios o externos, tales como:

• Operadores logísticos: envio de pedidos, entregas, recepción del picking, documentos de transporte, etc.
• Comunicaciones EDI: envio/recepcion de pedidos, entregas, confirmaciones de pedido, facturas. Para nuestra comunicaciones con clientes o proveedores.
• Ecommerce: envio de materiales, precios, recepción de pedidos, confirmaciones, envio de albaranes, facturas, etc.
• Portales internos: portales de comerciales, portales de proveedores, sistema CRM, etc.
• Retail: integraciones con terminal punto de venta (POS), integraciones con sistema CAR, etc.
• Distribución de datos maestros o documentos entre sistemas SAP (Ale).

Solo por poner algunos ejemplos.

Como la mayoria de vosotros conoceis, los Idocs son unos documentos electrónicos intermedios que nos permiten realizar el intercambio de información, con una estructura normalizada, que siempre incluye los siguientes elementos.

• Registro de control: un unico registro donde se indica quien envia, el destinatario, tipo de mensaje, tipo base, puertas, etc.
• Registros de datos: estructura jerarquica, con uno o varios registros, donde se detalla toda la información del documento. Podemos tener diferentes tipos de segmentos, cada uno con su estructura de datos y con repetición (por ejemplo, posiciones de un documento) y anidación de segmentos en forma jerarquica. Por ejemplo, una factura recibida de un proveedor, con sus diferentes segmentos de cabecera (fechas, interlocutores, identificadores de documentos) y detalle de posiciones.

• Registros de estado: uno o varios registros en donde se historifican los diferentes estados por los que van pasando el idoc, pudiendo incluir informacion asociada a cada estado (log de errores, información de documentos creados, etc).

En un entorno así, con sistemas cada vez más interconectados, necesitamos herramientas para poder monitorizar y gestionar los problemas más frecuentes que se producen con los idocs. Hasta la fecha, y según la mania de cada uno, utilizabamos las siguientes transacciones:

Monitor de Idoc. Transacción WE02

Es una de las transacciones más usadas por los consultores que gestionan idocs (a mi personalmente me gusta más la BD87). Nos muestra los idocs seleccionados organizados en carpetas según Entrada/Salida, Tipo de Mensaje y Status. Nos permite de una forma más o menos rapida ver lo que se ha procesado correctamente, lo que esta pendiente o lo que esta erroneo. Y desde allí realizar el analisis de los sucedido.

Desde el monitor podemos acceder a los idocs individuales para visualizar o modificarl si es necesario (desde el segmento de control o en un segmento de datos, opción Registro de datos –> Visualizar/Modificar) o ver el contenido completo del idoc con la opción Visualización de datos.

El monitor no permite relanzar el procesamiento de idocs erróneos, pero si nos permite una opción muy interesante. Seleccionando un nodo, y con la opción Lista de segmento especial, indicamos el segmento que queremos visualizar y nos muestra el contenido de ese segmento en todos los idocs seleccionados.

Una opción muy interesante para analizar de una forma rápida el contenido de un grupo de idocs o para realizar comprobaciones.

Monitor de Idoc. Transacción BD87.

Este monitor ha sido hasta hoy mi preferido. Basicamente, se diferencía de la WE02 en la forma de mostrar la información y en las acciones que se pueden realizar con los idocs.

A nivel de formato de visualización, me gusta que de un vistazo podemos ver lo estados de los idocs, lo que ha ido bien, lo que esta pendiente o erroneo. De una forma rápida.

Desde la visualización inicial podemos:

• Realizar filtrado de los idocs.
• Reprocesar los idocs erroneos o procesar idocs en estado inicial.
• Navegar a la lista de idocs.

En este listado podremos acceder a los idocs individuales (y realizar las mismas operaciones descritas en la WE02 a nivel de cada documenbto individual), visualizar las vinculaciones (si un idoc ha creado un documento, desde aqui podremos ver el numero de documento asociado y navegar hasta el), ver información de status y el texto explicativo (interesante para ver el detalle de los errores), etc.

Busqueda de contenido en idocs. Transacción WE09.

Pero que ocurre cuando necesitamos encontrar un idoc por su contenido. Podriamos intentarlo con las tablas donde se guarda la información, que son las mismas para todos los tipos de idocs ( EDID4 / EDIDC / EDIDS ). Pero tenemos otra opción con la transacción WE09, donde podemos indicar uno o varios segmentos y los valores a buscar en un campo determinado.

El monitor hace un barrido por los idocs que cumplan las condiciones de seleccion generales indicadas y busca en sus segmentos los valores introducidos.

Desde la lista de resultados podremos navegar al idoc, modificarlo, ver su contenido completo (igual que en la visualización individual de la WE02 o BD87).

Cambio estado de idocs. Report RC1_IDOC_SET_STATUS.

Cuando necesitemos cambiar el status de un idoc, por ejemplo para dar por concluidos documentos erroneos o cuando necesitemos inicializar el estado de alguno de ellos, podemos utilizar el report abap RC1_IDOC_SET_STATUS.

El report nos permite indicar uno o varios idocs a actualizar, el estado actual y el estado destino, pudiendo realizar una ejecucion en test antes de hacerlo en real.

Herramienta de test. Transacción WE19.

Esta herramienta es muy util cuando estamos montando una nueva integración utilizando Idocs y queremos probar con datos «inventados». También nos puede valer para replicar idocs erroneos y modificar su contenido. A diferencia de las transacciones vistas hasta ahora, donde solo podiamos modificar el contenido de los segmentos existentes, en la WE09 podemos añadir o quitar segmentos tambien, lo que puede ser muy útil para solucionar determinados tipos de errores.

Indicaremos el idoc que queremos utilizar como modelo y realizaremos la edición de los segmentos, modificando los valores en segmentos existentes, añadiendo o quitando estos, copiando un segmento como un segmento nuevo, etc. Desde la misma herramienta se puede lanzar la creación y el procesamiento del idoc editado al sistema (tanto idocs de entrada como de salida al exterior).

Visualizar formato de idocs. Transacción WE30.

Esta es otra de mis favoritas, no orientada a monitorizar los idocs existentes, pero si para obtener información de las estructuras de los diferentes tipos de idocs que podemos gestionar en nuestro sistema.

En el ejemplo, el tipo base ORDERS05, que podremos utilizar tanto para enviar pedidos a nuestros proveedores, como para recibir pedidos de nuestros clientes.

La transacción nos muestra la estructura del idoc, con sus diferentes segmentos, la jerarquia de ellos y los campos componentes de cada segmento si vamos navegado en el arbol.

Documentacion de Idocs. Transacción WE60.

Con esta utilidad podemos obtener documentación referente a los idocs en diferentes formatos como HTML, XML, DTD o C. Muy util cuando tenemos que pasar documentación «a la otra parte» de la información que le vamos a enviar a través d elos idocs.

Transacción WLF_IDOC.

Gracias a Isa Bodur hemos conocido la transacción WLF_IDOC, la verdadera navaja suiza de los idocs, donde vamos a poder hacer casi todo lo que hemos descrito anteriormente desde un único lugar. El monitor fue introducido por Sap hace ya algún tiempo (EhP5 SP10 / EhP6 SP07), yo al menos lo he conocido recientemente.

Esta nueva transacción dispone de una pantalla inicial de selección con diferentes pestañas, incluyendo los criterios habituales de selección (fecha con la opción de mayor o igual, hora, tipo de mensaje, interlocutores, status, usuario, etc), mas la búsqueda por el contenido de los idocs (como la WE09), con ademas la opción de sustituir valores (ojo a esta opción).

Incluye un modo supervisión que nos permite planificar un job para realizar chequeos relacionados al procesamiento de los idocs. También nos permite, usando la ultima pestaña de los criterios de selección programar el procesamiento en segundo plano para procesar IDocs con el estado 30 (saliente) o 64 (entrante).

Una vez ejecutado el informe, nos aparecerá un informe ALV con toda la información posible de los idocs que cumplan los criterios de selección (tenemos disponibles todos los campos relacionados con un idoc).

Opciones de navegación.

Desde la lista de resultados, podremos:

• Tenemos disponibles todas las opciones clásicas de un informe ALV: filtros, ordenación, exportación a excel, envio de email, gestión de variantes, etc.
• Visualización del contenido del IDOC, es un formato mucho mas amigable que las transacciones clásicas. Se muestran tres secciones con la lista de los segmentos, el resumen de status con toda la información y el detalle de campos del segmento seleccionado.

Al seleccionar un segmento en la parte izquierda, en la parte derecha inferior veremos todos los segmentos del mismo tipo (por ejemplo, posiciones de un documento). Esta opción es super útil para poder ver todos los nodos que se repiten en diferentes posiciones del documento.

• Acceso a la visualización clasica del idoc, haciendo doble click en el Status. Desde esta opción tenemos disponible la modificación del segmento de cabecera o de los segmentos de datos, tal y como teniamos en la WE02/BD87.

• Visualización del log de aplicación, en el caso de que exista uno relacionado con el procesamiento del idoc (como si llamaramos a la transacción SLG1).

• Visualización de documentos enlazados: podremos obtener los enlaces a otros idocs, datos maestros o documentos creados en el sistema, incluyendo la navegación a ellos con doble clic.

• Navegación al formato del Idoc (como si entraramos a la transacción WE30), desde la columna Tipo Base.
• Navegación a los acuerdos de interlocutor, puertas, etc utilizados en cada uno de los idocs.

Ademas de todo esto, tenemos disponibles las siguientes opciones de tratamiento:

• Modificación del idoc: Si hemos completado la parametrización que permite modificar los segmentos o campos del idoc, podremos realizar la modificación directamente de los campos en el visor de los segmentos (sin necesidad de realizar la tediosa navegación segmento por segmento que realizabamos en la WE02/BD87).

• Procesamiento del idoc: la misma opción que tenemos disponible en la BD87, teniendo disponibles tres modos de ejecución.

• Cambio de vista de visualización, pudiendo pasar, para los idocs seleccionados en el alv, a una visualización similar a la WE02.

• Enviar Idoc via RFC: nos permite enviar un idoc a otro sistema, indicando una conexión Rfc. Muy util para pasar idocs de un sistema productivo a un sistema de desarrollo, por ejemplo.
• Comparación de dos idocs: podemos seleccionar dos idocs del mismo tipo y el sistema nos hace una verificación segmento por segmento, indicando los valores diferentes.

• Modificación del registro de control del idoc: como indicamos más adelante, esta opción solo esta disponible en el modo experto. Pero es una forma mucho más rapida de modificar el segmento de control que la que tenemos ahora en la WE02/BD87.

• Copiar idoc y borrar un segmento: podemos crear un idoc nuevo, borrando un segmento definido.
• Modificación del status del idoc: como si realizaramos la ejecución del report RC1_IDOC_SET_STATUS. La modificación se puede realizar a uno o varios documentos seleccionados.

A tener en cuenta.

En un sistema productivo (mandante marcado como tal en la transacción SCC4), alguna de las funciones de la WLF_IDOC estan restringidas. En concreto:

• Cambio del registro de cabecera de los idocs.
• Cambio del status de idocs.
• Copiar un idoc y borrar un segmento.

En ese caso, para perfiles de usuario avanzados, podemos hacer disponibles estas opciones con el parametro WLFIDOC_NEW_EXPERT = X. Al modo experto se accede ejecutando la funcion &EXPERT una vez estamos en la transacción.

Además, hay un tema importante respecto a la modificación de los idocs. Al contrario de la WE02 / BD87, donde podiamos modificar cualquier segmento de un documento, en la transacción WLF_IDOC tendremos que parametrizar que segmentos y que campos son modificables desde la transacción (si queremos realizar la modificación directamente en el visor de idocs).

La parametrización de modificación se encuentra en la SPRO, ruta Componentes Multiaplicaciones –> Monitor Idoc –> Especificar parametrizaciones de actualización de Idoc. Podemos indicar por tipo de mensaje, los segmentos editables (se podrá indicar que se pueden modificar todos los campos de un segmento o enumerar los campos editables).

Si no queremos realizar esta configuración, podremos realizar también la modificación del idoc navegado a la visualización clásica de los idocs (tal y como hemos indicado) o cambiando a la vistas clasicas desde la WLF_IDOC.

Ha sido una grata sorpresa descubrir esta transacción y poder, por fin, hacer todo desde el mismo sitio y de una forma mucho más sencilla y completa. ¡¡¡Felicidades Sap!!!

Bibliografia:

WLF_IDOC: Die Zauber-IDoc-Transaktion, die die WE02, WE09 und BD87 alt aussehen lässt.

Swiss knife for idocs: WLF_IDOC transaction

Truco 119. Gestión de jobs técnicos con la transacción SJOBREPO.

Seguimos descubriendo las novedades que nos trae S/4HANA en lo referente a la gestión de Jobs, en este caso, los jobs técnicos que estan presentes en cualquier instalación Sap y que son fundamentales para un correcto funcionamiento del sistema.

En las versiones anteriores, la gestión de los jobs técnicos la realizaban los consultores de Basis desde la transacción SM36, utilizando la opción Jobs estandar, donde iban realizando la planificación de los diferentes procesos técnicos de administración del sistema.

Sap nos indica en la nota 16083 – Standard jobs, reorganization jobs, alguno de los reports recomendados para estas tareas. Por ejemplo, tenemos tareas para la reorganización de jobs, de ordenes de spool o batch inputs, recolectores de estadísticas, workflows, etc. Dentro de las tareas de configuración de un sistema nuevo o de mantenbimiento de uno existente, estos jobs han de estar correctamente planificados para que el entorno funcione sin problemas.

Teniendo en cuenta lo descrito por Sap en esta nota (y otras notas relacionadas que la actualizan o los componentes que estamos utilizando en nuestro sistema), el consultor BC realizaba la configuración de los jobs en el mandante correspondiente y con la frecuencia recomendada por Sap segun la tipologia de cada proceso.

Asi, por ejemplo, en mi sistema tengo un proceso diario que ejecuta el report RSPO0041 que borra las ordenes de spool mayores de 30 dias. Esto permite liberar espacio en la base de datos y que tablas donde se guarda esta información no tengan un crecimiento demasiado grande.

Cambios en S/4 HANA

A raiz de lanzamiento de los productos S4/Hana Cloud, Sap desarrollo una herramienta para la ejecución de los jobs técnicos, de una forma automatizada, sin necesidad de la intervención externa de un administrador. Dada la utilidad de esta herramienta, Sap decidio liberarla también a los sistema On-Premise, donde la tenemos disponible.

Podemos acceder a la herramienta desde la SM36, opción Repository de Jobs. O bien directamente desde la transacción SJOBREPO. Al entrar en esta opción, podemos observar un monitor donde hay un repositorio con todos los jobs técnicos e información del estado de planificación de los procesos en nuestro sistema.

Estas definiciones de los jobs ha sido creadas por los desarrolladores de Sap como objetos de workbench del tipo R3TR JOBD (ver nota 2581518). Ademas, podremos crear nuestras propias definiciones de jobs utilizando un namespace de cliente sin ningún problema.

Desde el monitor podremos realizar tareas como:

• Visualizar los jobs activos en un momento determinado.
• Visualizar los atributos de los diferentes jobs técnicos: programa y variante de ejecución, frecuencia y recurrencia, etc. No se deberían de realizar cambios en estos valores, ya que al tratarse de un objeto de desarrollo, estaríamos tocando un objeto Sap (modificación del estandar). Para ver la documentación asociada a un job, entraremos en el detalle, seleccionando la opción Goto -> Documentation.

• Activar / Desactivar localmente los jobs, sobreescribiendo la configuración por defecto.
• Cambio de los parametros de frecuencia de ejecución de los jobs.

• Visualización de estadísticas de ejecución de los jobs.

Se podrá igualmente cambiar el usuario que se utiliza en la planificación de los pasos de los jobs con la transacción SJOBREPO_STEPUSER o desde el mismo monitor. Por defecto se utiliza el usuario SAP_SYSTEM (si no existiera en el mandante, se usaría el usuario DDIC).

El job R_JR_BTCJOBS_GENERATOR se ejecuta periodicamente y se encarga de realizar la revisión y planificación de los jobs existentes en el monitor (usando como tiempo de frecuencia de ejecución el parámetro del sistema rdisp/job_repo_activate_time, que normalmente son 60 minutos ).

Con el report R_JR_UTIL_1 podremos ver el estado del monitor y realizar cambios en el.

En la nota 2190119 – Background information about SAP S/4HANA technical job repository tenemos un documento donde se explican en detalle algunas de las opciones del nuevo monitor.

Nota: si se quiere cancelar la planificación de un job técnico, no será suficiente con hacerlo desde la transacción SM37, también habrá que hacerlo en la SJOBREPO. Si no lo hicieramos, el job R_JR_BTCJOBS_GENERATOR volvería a planificarlo en su próxima ejecución.

Si quisieramos crear la definición de un job técnico propio, o cambiar la variante estandar asociada un job de sistema, crearemos nuestras propias definiciones de Job en un rango de nombres de cliente usando la SE80.

En la nota 3236399 – FAQ – Technical Job Repository (SJOBREPO) estan las referencias a las diferentes notas en las que se enumeran los jobs técnicos disponibles según la versión de Sap en la que nos encontremos. Es importante, pues según la versión de S4 se van modificando los elementos disponibles.

Bibliografia.

https://xiting.com/en/transaction-sjobrepo-the-new-sap-s4hana-technical-job-repository/

Batch jobs tips & tricks: www.saptechnicalguru.com/batchjobs/

Activación del monitor: https://itsiti.com/how-to-activate-sjobrepo-in-s-4hana/

S4HANA standard batch jobs

https://blogs.sap.com/2015/12/22/bye-bye-standart-jobs-function/

https://blogs.sap.com/2017/10/17/implementing-technical-jobs-in-s4hana/

Notas OSS:

16083 – Standard jobs, reorganization jobs

2190119 – Background information about SAP S/4HANA technical job repository

2744380 – Technical Job Repository: Using a different report variant for job scheduling

2581518 – Jobs in the Technical Job Repository (SJOBREPO)

2731999 – Assign custom step user for Technical Job Repository (SJOBREPO)

2499529 – Disable / Enable Job Repository scheduler

3236399 – FAQ – Technical Job Repository (SJOBREPO)

Videos:

Truco 118. Gestion de Jobs con aplicaciones Fiori.

Seguimos revisando los cambios que tenemos disponibles en S/4HANA y nos encontramos con alguna novedad en lo que respecta a la gestión de los Jobs.

Anteriormente, planificabamos nuestros jobs desde los reports en el momento de su ejecución o utilizando la transacción SM36. Posteriormente, podiamos consultar su estado de ejecución, resultados o logs desde la clásica SM37, pudiendo realizar también cambios en su planificación o pasos desde este mismo lugar. Estas transacciones podemos seguir utilizandolas, tanto si utilizamos Sap Logon, Netweaver o desde Fiori.

Pero tenemos algunas novedades al respecto. Ahora en Fiori disponemos de varias aplicaciones para realizar las gestion de los jobs:

• Application Jobs: nos permite realizar todas las tareas de consulta de los logs de ejecución de los jobs, spools asociados si existen y los estados de los trabajos. Aquí no veremos los jobs planificados desde la SM36/SM37.

Desde la misma aplicación podemos ver el detalle de los pasos de cada job y sus parámetros de ejecución. En la imagen podeis ver un ejemplo de un job de creación de facturas de ventas.

Igualmente, desde aquí podremos realizar la creación de nuevos jobs. A diferencia a la SM36, solo podremos utilizar las plantillas de jobs que hayamos definido previamente, como veremos a continuación.

Podeís ver la información de la app Fiori en este link.

• Application Jobs Template: nos permite realizar la definición de las plantillas de jobs que luego podremos utilizar en la aplicación Application Jobs. Información de la app Fiori aquí.

En la aplicación veremos los template de jobs del tipo Global, que no podremos modificar, y que se definen en la transacción SAPJ, que explicaremos a continuación.

Los template que creemos directamente desde esta transacción tendran el origen del tipo Compartido o Privado (indica que lo podrán utilizar todos los usuarios o solo el usuario que lo haya creado), pero siempre tendrán que utilizar un «Job Catalog» para definir los diferentes pasos de la plantilla de job. Esos tipos de Job se definen igualmente en la transacción SAPJ.

• Transacción SAPJ: es la transacción central de configuración de los tipos de jobs que vamos a poder planificar en las apps descritas. Sap nos entrega un catalogo de jobs predefinido, aunque podremos crear nuestras propias entradas, incluso para jobs sobre desarrollos Z.

En esta transacción, ademas de añadir las Entradas de Catálogo, también podremos crear los Template de jobs del tipo Global que usaremos en la definición de los jobs, como hemos visto antes.

Por ejemplo, tenemos una entrada del Catalogo de Jobs para lanzar la facturación de ventas llamado BILLING_DOCUMENT_RUN.

En la definición del catalogos definiremos los parametros que se podran indicar en la ejecución del proceso y que estaran del programa o clase como parametros de entrada.

En los blogs de Sap, Vijay Chintarlapalli nos explica paso a paso todo lo necesario para definir una nueva entrada del catálogo. Puede ser útil analizar con un abaper como estan creados los programas de otras entradas para definir los jobs de nuestros propios desarrollos.

Una vez creado el Catalogo, se definirá la correspondiente Plantilla o Template. En la imagen el template para el job de creación de facturas (BILLING_DOCUMENT_RUN).

Estas plantillas o las creadas desde la app Application Jobs Template serán las que nos permitan realizar la planificación de los Jobs.

Tenemos disponibles por Estandar cientos de Templates para la realización de todo tipo de procesos, especialmente en el módulo de Finanzas. Por ejemplo, ejecución de amortización de activos fijos, compensación, cambio de periodos, procesos de facturación o impresión de facturas, etc.

Nota: los jobs planificados desde la nueva App de Fiori si son visibles en la transacción SM37, pero desde allí no se puede realizar ninguna modificación del job.

Las aplicaciones, tal y como se indica en la documentación de Fiori, están disponibles en el catalogo SAP_BASIS_TCR_T.

Ejemplo práctico: Creación de un job de Amortización de Activos Fijos

Accederemos a la aplicación Application Jobs y pulsaremos el icono para crear un nuevo proceso en fondo.

1) En primer lugar introduciremos la Plantilla de Job a utilizar, dentro del catalogo disponible en el sistema. En nuestro caso, seleccionamos Contabilización de amortizaciones. Tenemos disponible un buscador para localizar la plantilla deseada.

2) Indicaremos un nombre al job.

3) Opciones de planificación: si es una ejecución puntual o periodica. En el caso de ejecución periódico, los valores de periodo.

4) Parametros de ejecución del proceso: en nuestro ejemplo, la sociedad, ejercicio, periodo y tipo de ejecución (test en este caso).

Realizamos la planificación del job y analizamos los resultados de su ejecución.

Igualmente hemos podido observar que hay diferentes aplicaciones predefinidas en Fiori, sobre todo en Finanzas, que llaman a la app Application Jobs, pasandole como parametros el o los templates que se podrán utilizar para la planificación de los trabajos.

Como veis, van cambiando cosas en nuestro sistema SAP y conviene estar al tanto para poder gestionarlo. Todo pinta a que estamos en una transición que ira cambiando el modelo anterior hacia un funcionamiento como el que hemos explicado en este post. Vamos a una herramienta donde no hay que conocer los nombres de los programas y sus programas para planificar los jobs, sino un catalogo de tareas bien definida que podemos planificar desde la herramienta, en la que los usuarios podrán ser autonomos de los usuarios técnicos.

¿Que pensais vosotros?

Bibliografía:

Activate Job Template in S4 Hana

https://blogs.sap.com/2019/07/06/s4-hana-schedule-and-monitor-application-related-jobs./

Ayuda de SAP: Defining Job Catalog Entries in ABAP

2947448 – Scheduling a Background job for a Fiori-based app

https://answers.sap.com/questions/669356/how-to-activate-job-template-to-fiori-app-in-s4-ha.html

Truco 117. Cambio de periodos contables de forma automática.

En nuestro sistema SAP podemos gestionar varios tipos de periodos abiertos, que son los que nos permiten realizar operaciones en unas fechas determinadas, no pudiendo realizar contabilizaciones fuera de los periodos que están habilitados. Mas concretamente, tenemos tres tipos de periodos:

• Periodos logísticos: se gestionan, a nivel de sociedad, con la transacción MMPV y nos permiten contabilizar los movimientos relacionados con gestión de stocks, registro de facturas de compras (MIRO), valoración de materiales, etc. Solo es posible contabilizar en una rango de dos periodos (meses), normalmente el mes en curso y el mes anterior. Con la transacción OMSY se pueden consultar los periodos actualmente abiertos en cada sociedad.

• Periodos contables (FI): se gestionan, a nivel de variante de periodos contables, con la transacción OB52. Podemos tener una o varias sociedades asignada a una variante de periodos contables. El control se puede realizar por tipologia de cuentas (Deudor, Acreedor, Activos, Cuentas de Mayor, Cuentas de Material), teniendo la posibilidad de gestionar periodos para los usuarios normales o para usuarios administradores mediante autorizaciones (hablamos de ello en una entrada anterior del blog).

• Periodos controlling: se gestionan con la transacción OKP1, a nivel de sociedad de Controlling, Ejercicio, Periodo, Versión y Tipo de contabilización (Real o Plan). En esos niveles, podemos indicar para los diferentes tipos de operaciones, si esta permitido o no el realizar contabilizaciones en la contabilidad de costes.

En condiciones normales, un usuario avanzado se encarga de gestionar los periodos y de realizar la apertura y cierre de cada uno de ellos. Por ejemplo, es habitual en la gestión de periodos contables de FI, el restringir la contabilización en las cuentas de IVA para evitar contabilizaciones en periodos ya reportados a las autoridades, tal y como vemos en la imagen siguiente.

Nota aclaratoria: la gestión de los periodos contables va relacionada con el ejercicio fiscal que gestione la empresa, no teniendo porque coincidir con el año natural (según el sector, puede haber ejercicios que van de febrero a enero, abril a marzo, etc).

¿Como automatizamos el cambio de ejercicio?

Periodos Logísticos

Para los periodos lógisticos, es tan sencillo como como utilizar el report RMMMPERI, que es el que se llama cuando ejecutamos la transacción MMPV. En este report podemos introducir la sociedad para la que queremos realizar el cambio y el periodo a entrar. Aunque tenemos una opción mucho más flexible, introduciendo la fecha del periodo que queremos abrir (lo que nos evita tener que conocer la configuración de periodos fiscales del sistema). De esta forma, indicando la fecha del primer dia del mes del nuevo periodo, el sistema hará el cambio sin ninguna complicación.

Para ello, crearemos un job con la transacción SM36, indicando al job una periodicidad mensual, con ejecución el primer día de cada mes (por ejemplo, a las 00:01 de la madrugada).

Añadiremos un paso con el programa RMMMPERI, donde habremos creado una variante con los parametros correspondientes (sociedad, diferentes flags marcados, etc) y para el campo de la fecha, utilizaremos una variable dinámica del tipo Fecha del día.

De esta forma, el proceso se ejecutará el día 1 de cada mes (por la periodicidad del job), y se abrirá el periodo lógístico correspondiente a ese dia por la variable dinamica indicada en la variante del job. Con la transacción SE38 podemos mantener las variantes asociadas al programa y realizar la configuración deseada de los parametros de ejecución de este.

Como indicabamos antes, con la transacción OMSY podremos comprobar que el cambio se haya realizado correctamente.

Periodos contables

Para realizar el cambio de los periodos contables, podremos utilizar los reports RFPERIOD_OPEN y RFPERIOD_CLOSE. En este caso, podremos utilizar igualmente un job para planificar el cambio, pero la cuestión es un poco más complicada, pues tenemos que indicar los valores de año y periodo, y no tenemos variables dinámicas disponibles para poder hacerlo.

En ese caso, tendriamos varias opciones para automatizar el proceso:

• Desarrollo a medida que cree el job correspondiente llamando al programa RFPERIOD_OPEN, llenando los parametros de selección con los valores necesarios para realizar la apertura o cierre de los periodos. En la lógica del programa podremos tener en cuenta la sociedad, que ejercicio fiscal tiene, etc, para poder enviar los valores correctos para realizar el cambio.
• Planificar un job, usando las variables que tiene Sap definidas en las tablas TVARV/TVARVC. Estas variables se actualizan ejecutando el programa RVSETDAT o manualmente con las transacciones STVARV o STVARVC. Aquí podriamos añadir nuestras propias variables Z y actualizarlas con un programa Z o manualmente, con la lógica deseada.

Primero actualizariamos las variables y luego planificariamos un job, indicando en la variante del report RFPERIOD_OPEN, las variables para el ejercicio/s y periodo/s a abrir o cerrar.

Un poco más complejo pero tenemos una solución más o menos sencilla para realizar el proceso.

Periodos de controlling

Para realizar el cambio de los periodos de controlling, utilizaremos el report RKCOOKP1. La problemática es la misma que la descrita en el punto anterior, así que podremos utilizar la misma solución para indicar los periodos que vayamos a abrir o cerrar usando las variables de sistema o un desarrollo a medida.

Y siempre teniendo en cuenta las implicaciones de esta configuración y que ha de ser consensuada y gestionada con los departamentos financieros o de controlling.

Os recomiendo la lectura del documento de Sanjeev Kumar donde se explica en detalle todos los pasos para realizar la automatización que acabamos de describir.

Espero os sea de utilidad. Encantado de volver a publicar en el blog despues de tanto tiempo.

Bibliografía.

Automate Period opening in SAP – Sanjeev Kumar

Gestion de dos periodos contables abiertos en Finanzas

 

Truco 116. Navegación en el flujo de documentos de Venta en S/4HANA.

Hoy os voy a explicar un truco muy rápido que he conocido gracias a Isa Bodur (os recomiendo la lectura de su blog llamado thinkdoforward.com ).

Hace algún tiempo hablamos en el blog sobre el flujo de documentos en ventas, las opciones de parametrización y como podíamos utilizar la transacción IW72 para consultarlo para varios documentos a la vez.

Pero vayamos al grano. Una de las cosas más incomodas cuando estamos consultando este historial es la forma de navegar por los documentos. 

En primer lugar, hay que posicionarse en la linea a la que queremos navegar (por ejemplo, la factura). Y a continuación pulsar la opción «Visualizar documento» para que Sap nos lleve al correspondiente documento (pedido, entrega, factura, documento de material, etc).

Pues después de tantos años, alguien debió de darse cuenta de esto y ahora tenemos  la opción de una navegación inmediata haciendo doble clic en la linea correspondiente. Para ello, basta con incluir el parámetro DOCFLOW_DCLICK_NAVI con el valor X en los datos de cada usuario el sistema.

La opción esta disponible desde 2018 (consultar la nota 2631700, tanto en R3 como en S/4HANA).

Ademas, hay más buenas noticias. Tenemos otros parámetros interesantes que nos van a facilitar la vida y nos permiten:

• Transacción VA05/VF05/VF15…: cuando hacemos doble clic y navegamos a las documentos, lo hacemos en modo modificación. Con el parámetro DISPLAY_SDOC_RE_NAVI podemos forzar a la que navegación sea en modo visualización (ver nota 2761156 ).

• Transacciones VF01/VF02/VF03: con el parámetro VF_PREVIEW podemos hacer que aparezca un botón que nos permite realizar la visualización de los mensajes asociados a la factura ( ver nota 2633052 ). Esto es una gran ayuda de cara a realizar la impresión de mensajes o simplemente la visualización previa.

• Transacción VFX3: con el parametro VFX3_ENH_VKO permitimos la selección por varias organizaciones de ventas en la liberación de facturas para contabilidad (ver nota 2663048).
• Transacción VF04: con el parámetro VF04_ENH ampliamos los criterios de selección en el pool de facturación teniendo disponibles los campos Oficina de Ventas y Creado por (ver nota 2658557).
• Transacción VF04: con el parametro VF04_SEL podemos predefinir por usuario las clases de factura que se van a tratar en el pool de facturación (ver nota 2650026).

Nota: es posible que según el nivel de Hot Packages de nuestro sistema estas opciones no estén disponibles o en otros casos sean enhacements que haya que activar aplicando la correspondiente nota. Os recomiendo la lectura de detallada de las notas asociadas a cada parámetro para ver en que versión están disponibles o cuales son los pasos para activarlos.

Igualmente, os recomiendo la lectura del blog dan852.com donde nos explican otros parámetros relevantes en el módulo de ventas.

Bibliografia.

https://www.dan852.com/overview-available-user-parameters-sap-sd/

https://saptricks.wordpress.com/2016/02/21/truco-78-flujo-de-documentos-en-ventas/

S/4HANA SD-Belegfluss – Jahrzehntelange Lücke endlich geschlossen

 

Cambios más relevantes en el modulo de Ventas (SD) en S/4HANA. Modelo de datos y Condiciones de precio (1/3).

Cuando alguien me pregunta sobre son los cambios más relevantes con los que se va a encontrar al pasar a S/4HANA, suele responderle que, dependiendo del módulo, los cambios son más o menos importantes. Y que es fundamental irnos a las Simplification List donde se explica con todo detalle el alcance de los cambios, modificaciones en los modelos de datos, nuevas transacciones o transacciones que quedan obsoletas, cambios en la funcionalidad, etc. Y es importante tener en cuenta que no tenemos por que esperar una revolución en la funcionalidad, seguramente la mayoría de cosas que conocemos y hemos utilizando durante tantos años siguen estando ahí y simplemente se ven afectadas por pequeños cambios o ajustes. Y si es posible que algunas funcionalidades complementarias se vean sustituidas por nuevos componentes a los que Sap ha decidido darles continuidad en contra de otros que van a quedar obsoletos y serán eliminados.

En las próximas tres entradas del blog vamos a hablar de algunos de los cambios más relevantes que nos encontraremos en el módulo de Ventas (SD) si venimos desde R3 y vamos  a dar el salto a S/4HANA.

Básicamente, aparte de los cambios tecnológicos y la aparición de las aplicaciones Fiori, alguno de los cambios en lo que a ventas respecta son:

• Simplificación en el modelo de datos. Cambios en el modelo de datos de Pricing.
• Cambios en la gestión de los acuerdos de Rappel.
• Cambios en la gestión del Control de Crédito.

Veamos en detalle cada uno de ellos.

Simplificación en el modelo de datos.

Tal y como se explica en las notas 2267306 y 2198647, el diccionario de datos ha sido rediseñado, incluyendo los siguientes cambios.

• Eliminación de las tablas de status VBUK y VBUP: en R3, disponíamos de dos tablas centralizadas donde podíamos consultar el estado de los documentos de venta (VBAK/VBAP), entregas (LIKP/LIPS) y facturas (VBRK).

En S/4HANA, estas tablas han sido eliminadas y los correspondientes campos han sido movidos a las correspondientes tablas de cabecera y lineas de los documentos.

De esta manera, conseguimos incrementar el rendimiento del sistema, pues:

• Podremos tener el estado de los datos de cabecera o posición de un documento con un único select a la base de datos.
• Las vistas que contienen información de la cabecera/posición de los documentos y los estados se pueden contruir sin necesidad de una condición JOIN (por ejemplo, VBAKUK, LIKPUK, LIPSUP)

Ademas se han realizado cambios en otras tablas:

• Tabla de flujo de documentos (VBFA): la tabla ha sido optimizada para reducir su crecimiento y mejora su rendimiento, con un cambio en la clave de la tabla.

• Tipo documento comercial (campo VBTYP): el campo ha sido ampliado de 1 a 4 caracteres (pasando del elemento de datos VBTYP al VBTYPL).

• Eliminación de redundancias en las tablas de indice de documentos: En R3, estos objetos eran tablas de la base de datos que guardaban información redundante de los documentos para optimizar accesos. En S/4HANA estas tablas han sido eliminadas y pasan a ser vistas CDS, son accesibles directamente desde ABAP.

Por si no las conocíais, estas vistas nos permite acceder a un conjunto limitado de las tablas de ventas de una forma mucho más rápida:

• • VAKPA: Pedidos por funcion de interlocutor.
  • VAPMA: Posiciones de pedido por material
  • VLKPA: Entregas por función de interlocutor.
  • VLPMA: Posiciones de entrega por material.
  • VRKPA: Facturas por función de interlocutor.
  • VRPMA: Posiciones de factura por material.
    
    

Cambio en el modelo de datos de Pricing.

Aquí tenemos unos de los grandes cambios que se ha realizado a nivel técnico, tal y como se explica en las notas 2267308 y 2220005.  Por entrar en contexto, en las versiones anteriores de Sap los cálculos de precios que se realizaban en los documentos (tanto en compras como en ventas), se almacenaban en la famosa tabla KONV.

Allí teníamos almacenadas todas las condiciones de precio con sus valores según la definición de los esquemas de cálculo realizada por parametrización.

En S/4HANA, esta tabla desaparece y es sustituida por la tabla PRCD_ELEMENTS, con la que tendremos que familiarizarnos a partir de ahora. Básicamente, se han realizado cambios en varios campos y ampliado longitudes, con el objetivo de dar más flexibilidad en el ámbito del cálculo del precio.

Pero ademas, tenemos otros cambios importantes que sin son realmente relevantes y nos permite aumentar la flexibilidad y opciones de configuración de la técnica de condiciones:

• Longitud de campos mejoradas para permitir mayor flexibilidad en el pricing y la técnica de condiciones:
  • Secuencias de acceso: el numero de accesos posible a tablas de condición se ha incrementado de 99 a 999.
  • Número de tablas de clientes para condiciones: se han duplicado, con lo que será díficil quedarnos sin tablas de cliente para la definición de condiciones de precio. Recordemos que son las tablas que podemos definir entre los rangos 501 y 999 o 9AA y 9VV.
  • Eliminación de campos redundantes en la tabla de cabecera de condiciones de precio (KONH): el campo VAKEY  que se construye con la clave de las tablas de condición ha sido eliminado de todas las cabeceras de las tablas de condición (KONH, NACH, KOND3, KONDN o KONHM). Esto reduce el tamaño de las tablas o problemas al cambiar las tablas de condición. Idem con el campo VADAT.

• •  Longitud de la clave de las tablas de condición ampliada: en R3 teníamos una limitación de 100 caracteres al definir la clave de las tablas de condición (tablas AXXX, donde XXX es el número de tabla de condición). En S/4HANA tendremos disponibles 255 caracteres y no tendremos nunca un problema de longitud.

Para entenderlo, la suma de la longitud de los campos que indicábamos como clave al definir las tablas de condición nunca podía superar la longitud de 100 caracteres. Eso podía tener limitaciones en determinadas circunstancias si estábamos utilizando muchos campos. Con la nueva longitud esa limitación desaparece al disponer de 255 caracteres.

Como veis, muchos cambios técnicos pero que en principio son solo mejoras y son totalmente transparentes para los usuarios.

En los próximos posts veremos otros cambios que si tienen realmente implicación en la funcionalidad disponible para el usuario final con respecto a lo que tenían anteriormente. Espero que os sea de utilidad.

Bibliografía:

Haz clic para acceder a SIMPL_OP2020.pdf

https://archive.sap.com/documents/docs/DOC-70833

https://blogs.sap.com/2016/05/19/simplification-item-simplified-data-model-in-pricing-and-condition-technique/

https://launchpad.support.sap.com/#/notes/2267308