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.

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.

Publicado en Abap, Formacion | Etiquetado , , , , | Deja un comentario

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/

Publicado en Abap, Formacion, S/4HANA, Sap Basis | Etiquetado , , , , , , , | 1 Comentario

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://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

Publicado en Formacion, Productividad, Sap Basis | Etiquetado , , , , | Deja un comentario

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.


Publicado en Formacion, Productividad, S/4HANA, Sap Basis | Etiquetado , , , , , , , , | 3 comentarios

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/

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:

Publicado en Formacion, S/4HANA, Sap Basis | Etiquetado , , , , , | Deja un comentario

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

Publicado en Formacion, S/4HANA, Sap Basis | Etiquetado , , , , | Deja un comentario

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

 

Publicado en Formacion, Sap FI, SAP MM | Etiquetado , , , , , , | 2 comentarios

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

 

Publicado en Formacion, S/4HANA, Sap SD | Etiquetado , , | 2 comentarios

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

Publicado en Formacion, S/4HANA, Sap SD | Etiquetado , | 3 comentarios

Truco 115. Control de autorizaciones para los Business Partners (BP) en S/4HANA.


Como vimos hace unos meses, la  gestión de clientes y proveedores utilizando la función de Business Partner es uno de los cambios mas importantes introducidos por SAP en S4/HANA. En un post previo hablamos de lo que este cambio significaba tanto a nivel funcional, de modelo de datos y técnicamente (compatibilidad con las funciones anteriores).

En nuestro truco de hoy vamos a ver en detalle como podemos controlar mediante autorizaciones las acciones que los usuarios podrán hacer sobre los BP. Al final, el objetivo es limitar que los usuarios pueden modificar determinados clientes/proveedores o restringir la visualización o modificación de campos o grupos de campos.

Para ellos disponemos de tres alternativas que van desde un enfoque más general (limitar directamente cualquier modificación en uno o varios interlocutores), controlar los accesos según el valor de determinados campos hasta mas enfocadas a proteger la modificación de grupos campos (por ejemplo, evitar la modificación de datos bancarios, identificadores fiscales, etc).

Veamos en detalle las tres opciones.

Grupos de autorizaciones.

Con esta opción, utilizando el objeto de autorización B_BUPA_GRP, definimos los grupos que deseemos a través de la opción de parametrizacion SPRO, ruta Componentes Multiaplicaciones –> Interlocutor comercial central –> Interlocutor comercial –> Parametrizaciones básicas –> Gestión de autorizaciones –> Actualizar grupo de autorizaciones.

Una vez creados los grupos, los asignaremos en los interlocutores en el momento de crearlos o al modificarlos, en la función Interlocutor General (000000), pestaña Datos de Control.

De esta manera, clasificamos a los interlocutores desde el punto de vista de las autorizaciones.

Posteriormente, crearemos los roles asignando el objeto de autorización B_BUPA_GRP, y aquí es donde indicaremos para cada grupo, si el usuario podrá realizar cualquier acción sobre los clientes, o solo visualizar o tiene restringido totalmente el acceso.

Finalmente, tras asignar los roles, el usuario solo podrá visualizar o modificar los grupos para los que haya sido autorizado. De una forma general, sin entrar al detalle de campos especificos.

Clases de autorizaciones.

Con esta opción, gestionada a través del objeto de autorización B_BUPA_ATT, podemos crear grupo de interlocutores usando los valores de uno o dos campos del maestro. Por ejemplo, puedo utilizar los valores del campo PAIS para determinar que usuarios podrán modificar o visualizar  los datos de los interlocutores.

En primer lugar, como trabajo de parametrización, hay que crear las clases de autorización y asignarles los campos por los que vamos querer crear los grupos de autorización. Lo haremos en la ruta Componentes Multiaplicaciones –> Interlocutor comercial central –> Interlocutor comercial –> Parametrizaciones básicas –> Gestión de autorizaciones –> Actualizar clases de autorización.

 

Tiene la limitación de que solo se pueden incluir dos campos en cada grupo, aunque tendría que ser suficiente.

Una vez creados los grupos, crearemos los roles de autorización asignando la autorización según el valor de los campos indicados en la clase de autorización. En mi ejemplo, he creado un rol para dar autorización a los clientes cuyo país es Francia.

Cuando el usuario intenta acceder a un interlocutor que no corresponde con este país, el sistema se lo impide.

Es decir, utilizando los valores de un campo del interlocutor, creamos grupos y podemos controlar con la autorización quien puede visualizar o modificar los componentes de dichos grupos. Una opción muy interesante y mucho mas afinada que la general de utilizar el grupo de autorización visto en el punto anterior (en realidad no nos obliga a indicar un dato adicional como en ese caso, sino que utilizamos los propios valores del maestro de interlocutores). Y nos da una flexibilidad que no teníamos hasta ahora para controlar las modificaciones en los interlocutores.

Grupos de campos relevantes para autorizaciones.

Con esta última opción, utilizamos los grupos de campos que ya tiene definidos SAP para construir las diferentes pantallas de los business partners. Cada campo de la BP esta asignado a un grupo de campos.

Los grupos de campos se pueden consultar en la transacción BUS2.

Para cada uno de ellos se puede ver el detalle de los campos que lo conforman:

Quizás lo más complejo en este caso sea localizar el grupo exacto que nos va a permitir controlar sobre el campo o campos que queramos restringir.

En este caso, las autorizaciones se gestionan con el objeto B_BUPA_FDG. Se requiere un paso previo de parametrización, que consiste en activar el control de autorizaciones para el grupo elegido.  Lo haremos en la ruta Componentes Multiaplicaciones –> Interlocutor comercial central –> Interlocutor comercial –> Parametrizaciones básicas –> Gestión de autorizaciones –> Especificar grupo de campos relevantes para autorización.

En mi ejemplo, he activado la verificación de autorizaciones en el grupo 0009 Datos Bancarios. A continuación he creado un rol y dado acceso solo a visualizar a los usuarios que lo tengan asignado.

 

Los usuarios restringidos pueden visualizar los datos bancarios de los interlocutores, pero no tienen acceso a modificarlos. Como vemos en la imagen, aun estando en modo actualización, los campos de ese «grupo» nos aparecen grisados y no podremos cambiarlos.

Esta opción es igualmente útil, pensada para las listas de campos agrupados en el estándar bajo el concepto «Grupos de campos».

Nota: las autorizaciones clásicas relacionada con clientes y proveedores se siguen manteniendo en S4/HANA por cuestiones de compatibilidad.

Funciones similares si aun seguimos en R3.

Para los que seguís trabajando con R3, os dejo entradas previas del blog donde tratamos temas similares con las transacciones clasicas (XD??, XK??, FD??, FK??, MD??, MK??).

Bibliografia.

https://blogs.sap.com/2020/02/25/sap-business-partner-hide-field-visibility-and-authorization-to-bp-groups/

Sap Business Partner Security – Ayuda de Sap.

Publicado en Formacion, S/4HANA, Sap FI, SAP MM, Sap SD | Etiquetado , , , | Deja un comentario