En nuestro truco de hoy volvemos a temas más funcionales y vamos a hablar un poco de la transacción MD04.

Esta transacción es uno de los pilares fundamentales para el trabajo de los planificadores en un sistema Sap o de las personas que se encargan de los procesos de compra.

Básicamente, la MD04 nos permite, a partir de un material en un centro determinado, visualizar los elementos de planificación existentes en el momento actual.

Por ejemplo, al ejecutar la transacción podremos visualizar los stocks existentes en el centro, entradas previstas (solicitudes de pedido, pedido), ordenes de producción, ordenes previsionales, reservas, documentos de salida (pedidos de cliente, entregas), pedidos de traslado, etc.

Si un material es requerido para otro proceso (por ejemplo, es componente de la lista de materiales de un material que se fabrica o se utiliza como componente de subcontratación), también aparecerán las necesidades secundarias que son disparados por la necesidad de otro producto.

Igualmente, si en nuestro sistema introducimos necesidades planificadas desde el módulo de Producción, podremos verlas como un elemento de planificación.

Los diferentes necesidades aparecen ordenadas por fecha, está identificada su tipología por el campo “Elemento Planificación” (os recomiendo echar un vistazo a la ayuda del campo en cuestión).

La transacción MD04 nos permite navegar por los elementos (haciendo doble clic en ellos). Incluso permite realizar acciones (por ejemplo, nos permite crear un pedido a partir de una solped o crear una orden de producción a partir de una orden previsional). Por ejemplo, desde una solicitud de pedido

La transacción nos permite visualizar las necesidades de forma detallada o de forma agrupada por periodos (días, semanas o meses). Esto nos permite analizar de forma fácil periodos del futuro, detectando infracoberturas, problemas con los stock en determinados periodos, etc.

La transacción dispone de muchas utilidades, como el poder realizar filtrado en los elementos que se visualizan (hay que habilitar el filtrado pulsando el botón del filtro).

Además Sap nos deja ciertas “puertas abiertas” para realizar una personalización de la transacción, que es lo que os voy a contar en nuestro truco de hoy.

Transacciones adicionales en la barra de botones.

Podemos añadir, por parametrización, acceso directos a transacciones relacionadas por poder ser llamadas directamente cuando estemos dentro de la MD04.

La parametrización se realiza con los llamados “Perfiles de navegación”, desde la transacción OM0K, opción “Llamadas de transacción generales”. teniendo una limitación de 5 botones. Básicamente definiremos un perfil de navegación (hay unos estándar y podremos añadir los Z que deseemos).

Para cada botón, indicaremos la transacción que será llamada, pudiendo personalizar el icono asociado, pasar parámetros de memoria o filtrar la disponibilidad del botón según determinados valores del maestro del material (clase de aprovisionamiento, tipo de material, grupo planificación o característica de planificación).

Opciones adicionales en cada elemento de planificación.

Utilizando igualmente los perfiles de navegación, podemos añadir, para cada elemento de planificación, botones de navegación hacia otras transacciones.

Por ejemplo, si estamos en una solicitud de pedido, podremos añadir una llamada a Liberar la solicitud de pedido (ME54) o enviar un email al proveedor ( MDM2).

En la transacción OM0K seleccionaremos un Perfil de navegación y añadiremos las diferentes opciones en la sección “Llamadas transacción por elemento planificación”. Por ejemplo, en mi perfil para el elemento de planificación BA (Solicitud de pedido), hemos añadido las dos opciones indicadas (Liberar solped y Enviar email).

La forma de hacer accesibles los botones, tanto a nivel de barra de botones, como por elemento de planificación es seleccionando uno de estos perfiles cuando estemos trabajando con la MD04. Para ello, seleccionaremos la opción de menú Entorno –> Perfil de navegación –> Asignar.

Desde aquí podremos seleccionar el perfil de navegación que deseemos utilizar en cada momento o guardarlo como valor por defecto para el usuario con el que estemos trabajando.

Añadir columnas adicionales en la MD04.

Sap nos permite, mediante user-exit o Badi, añadir hasta 3 columnas adicionales en la transacción MD04. Puede ser útil cuando tenemos que añadir información extra en el informe que sea requerida por nuestros usuarios.

Podemos hacerlo a través de la CMOD (ampliación M61X0002), donde podemos llenar el valor de uno de estos 3 campos adicionales. Hay un ejemplo de implementación en el estándar.

Si preferimos utilizar las Badis, realizaremos una implementación de la badi MD_ADD_COL_EZPS (usando los metodos ACTIVATE_ADD_COLUMNS  y FILL_ADD_COLUMNS). Ver ejemplo de implementación en este link (gracias a saptutorial.org).

Desarrollos Z con información de la MD04.

Para finalizar, en ocasiones se nos hace necesario desarrollar un report Z que tenga la información de la MD04, pero con la opción de poder incluir varios materiales a la vez, filtrar por el tipo de elemento de planificación, etc. Es relativamente sencillo utilizando el módulo de función MD_STOCK_REQUIREMENTS_LIST_API. Aquí os pego un trozo de código con lo que haría falta.

* Pasamos la regla de seleccion ERGBZ

    CALL FUNCTION ‘MD_STOCK_REQUIREMENTS_LIST_API’
      EXPORTING
        plscn                    = plscn
        matnr                    = it_marc-matnr
        werks                    = it_marc-werks
      IMPORTING
        e_mt61d                  = wa_mt61d
        e_mdkp                   = wa_mdkp
        e_cm61m                  = wa_cm61m
        e_mdsta                  = wa_mdsta
*       e_ergbz                  = wa_ergbz
      TABLES
        mdpsx                    = it_mdps
        mdezx                    = it_mdez
        mdsux                    = it_mdsu
      EXCEPTIONS
        material_plant_not_found = 1
        plant_not_found          = 2
        OTHERS                   = 3.

Datos que devuelve:
  DATA:
    wa_mt61d TYPE mt61d,
    wa_mdkp  TYPE mdkp,
    wa_cm61m TYPE cm61m,
    wa_mdsta TYPE mdsta.

Tablas que devuelve:
  DATA:
*”  TABLES
    it_mdps TYPE TABLE OF mdps WITH HEADER LINE,
    it_mdez TYPE TABLE OF mdez WITH HEADER LINE,
    it_mdsu TYPE TABLE OF mdsu WITH HEADER LINE.

Se le pasa la información del material y centro (se hace una iteracion para los diferentes materiales y centros para los que se quiera obtener los datos).
En la tabla it_mdez está el detalle de los elementos que aparecen en la MD04, pudiendo completar la información devuelta por el estándar con cualquier otra información adicional que se quisiera mostrar.

Espero os sea de utilidad.

Bibliografía:

https://blogs.sap.com/2013/06/15/icons-for-frequently-used-transactions-in-md04/

https://vdocuments.mx/md04-add-new-columns.html

https://www.saptutorial.org/add-custom-column-in-sap-md04-tcode/

En nuestro truco de hoy vamos a hablar de los calendarios de SAP, como podemos utilizarlos en diferentes ámbitos y algún truco de programación para leer la información registrada en ellos.

Básicamente, estamos hablando de una funcionalidad transversal (utilizada en muchos módulos), que nos permite indicar los días que son hábiles o no para diferentes procesos.

Donde podemos utilizar los calendarios.

Algunos ejemplos de utilización de los calendarios son los siguientes:

• Calendario asociado a un centro: nos permite indicar los días que son hábiles para el centro, siendo utilizada la información en el cálculo de planificación de necesidades, programación de ordenes, etc.

• Calendario asociado a un puesto de expedición: asociado a un puesto de expedición nos permite indicar los días laborables en los procesos de preparación de pedido (se utilizará en la verificación de disponibilidad de los pedidos y en el calculo de la programación de los pedidos). En los puesto de expedición podremos afinar aún mas indicando horarios y turnos de trabajo.

• Calendario asociado a rutas: indicando un calendario en una ruta, podemos indicar los días en los que realmente trabaja la ruta, siendo tenido en cuenta para la planificación de la entrega.

• Calendarios de facturación: nos permite indicar, por cliente, los días que son hábiles para la emisión de facturas. Se utilizará para llenar la propuesta de fecha de factura en los pedidos de venta que creemos. Por ejemplo, si un cliente nos exige facturación mensual (último día de mes), podremos gestionar esta necesidad utilizando calendarios.

• Calendarios para la gestión de rappels de ventas: tanto en la parametrización de los rappels como en la definición de acuerdos se pueden indicar calendarios de rappels para indicar los días previstos de liquidación o para realizar la prolongación automática de acuerdos.
• Calendarios laborales para planificación de jobs: podemos utilizarlos igualmente cuando planificamos jobs en el sistema para indicar las fechas en las que se ejecutaran los procesos o evitar que se realicen en determinados momentos.

• Desarrollos a medida: los calendarios pueden utilizarse en desarrollos Z para reporting o controlar procesos. Por ejemplo, un calendario donde indicamos los dias de trabajo de los comerciales para hacer cálculo de previsiones y grado de previsiones cumplidas según los días de venta.

Configurando los calendarios.

La configuración de los calendarios se realiza utilizando la transacción SCAL. Hemos de distinguir 3 componentes en la definición de calendarios:

• Festivos: podemos predefinir los días festivos utilizando reglas y luego incluirlos en el calendario de festivos para que el cálculo de los festivos se haga de forma automática.
• Calendario de festivos: no es más que una recopilación de festivos. Los calendarios de festivos se asocian posteriormente a los calendarios de fábrica.
• Calendario de fábrica: el calendario de fábrica es el elemento que nosotros asignamos en la parametrización o funcionalidad, y consiste en un conjunto de días que se consideran hábiles según la definición realizada, a partir de días laborables en general, calendario de festivos y excepciones o reglas especiales.

Veamos un poco más en detalle cada uno de estos elementos.

Con la opción “Días festivos” realizamos la definición individual de los diferentes festivos que podemos tener en nuestro sistema. No es imprescindible utilizarlo, aunque si facilita la automatización del mantenimientos de los calendarios de fábrica.

Básicamente, al crear un festivo el sistema nos pedirá la definición de su tipología, teniendo disponibles 5 opciones.

En detalle:

• con fecha fija: se indica una fecha (mes y día) que siempre es festivo en un determinado ámbito. En este caso se puede determinar como se comporta el festivo si cae en un determinado día, por ejemplo, un domingo (con las opciones de garantía)

• con día fijo a partir de esta fecha: se indica una fecha y el día de la semana a partir de esa fecha que aplicará el festivo.

• Distancia Pascuas: para calcular los festivos asociados con la semana santa (que varían cada año). Se puede indicar un número de días antes del domingo de Pascua (por ejemplo, para calcular el jueves o viernes santo) o un numero de días a posteriori (por ejemplo para el lunes santo).

• Domingo de Pascua: idem del anterior, en este caso para identificar el Domingo de Pascual, que es variable cada año como hemos indicado.

• Festivo irregular: puede haber festivos que sean irregulares y que dependiendo del año aplican o no. Con esta definición de festivo, podemos definir la relevancia del festivo matizándolo con el año. Por ejemplo, en la ciudad de Alicante el día 25 de junio es festivo algunos años. Con este tipo de festivo podríamos definir esa casuística.

Además a cada festivo se le puede asignar una descripción, un texto breve y una clave de clasificación (para que sea más fácil relacionar los festivos asociado, por ejemplo a un país, categoría de festivo, religión, etc).

Una vez definidos los diferentes festivos, los agruparemos creando un “Calendario de festivos”. El calendario de festivos tiene un periodo de validez (año inicial y año final) y en el se enumeran los diferentes festivos asociados (igualmente indicando un intervalo de validez en la asociación de cada día festivo al calendario de festivos).

Con la opción Visualizar Calendario podríamos vez como quedaría la asignación de festivos en un calendario de fechas real.

Finalmente, procederemos a la creación del “Calendario de fábrica”. En la definición de un calendario de fábrica hemos de indicar es su periodo de validez, el calendario de festivos asociado (que habremos definido previamente) y los días que se consideran laborables.

La definición de días laborables dependerá si la empresa trabaja todos los días de semana, solo de lunes a viernes, etc (y del ámbito donde vayamos a utilizar el calendario). Una vez definido el calendario, ya podremos consultar su configuración con un calendario de fechas utilizando la opción Calendario.

El sistema nos mostrará un resumen por año con la cantidad de días laborables y festivos, pudiendo entrar a visualizar el detalle de cada año (apareciendo en naranja los días laborables y en verde los días festivos).

Si necesitamos definir reglas especiales para determinados días en un año, podemos realizarlo utilizando la opción “Reglas especiales”. Por ejemplo, para mi calendario de facturación mensual, donde solo el último día de cada mes es “laborable”, he definido reglas especiales para esos días, que me permiten indicar los días que son relevantes (el resto de días por el calendario de festivos asignado o por la definición de días laborables son no laborables).

Si no hubiera marcado el flag de “Dia labor.” estaría añadiendo con las reglas especiales días festivos o excepciones adicionales. Es otra manera más sencilla de definir los festivos de un años, aunque habrá que acodarse cada año de definirlos como excepciones.

Transporte de calendarios.

Respecto al transporte de los calendarios, aunque se puede realizar desde la SCAL de forma estándar, el transporte borra todos los calendarios existentes en el sistema destino, por lo que mi recomendación es realizar la configuración en cada sistema (abriendo el mandante con la transacción SCC4).

Este es el texto que muestra Sap cuando pulsamos la opción de transportar. Como podéis observar, no es nada tranquilizadora la forma en la que el estándar realizar dicho transporte.

Leyendo los calendarios en nuestros desarrollos.

Si necesitamos disponer de la información de los calendarios en nuestros desarrollos, es muy sencillo hacerlo utilizando diferentes módulos de función estándar.

Por ejemplo, con el MF HOLIDAY_GET, indicando el periodo que queremos analizar y el calendario de fábrica.

El sistema nos devuelve la lista de días que son no laborables (por ser festivos o días considerados no hábiles en el calendario de fábrica).

Otro módulo de función interesante es el DAY_ATTRIBUTES_GET, que nos permite obtener los parámetros para un día o un intervalo de fechas (si el día es laboral o no, si es un festivo, etc).

Si necesitáis ampliar información, os recomiendo la lectura de los links que se anexan a continuación.

Bibliografía.

https://blogs.sap.com/2016/03/20/step-by-step-getting-working-days-from-sap-calendars-by-universe-on-sap-erp/

https://blogs.sap.com/2015/03/10/significance-of-calendar-in-sap-logistics/

https://blogs.sap.com/2014/02/13/public-holiday-calendar-and-work-schedule-rules/

https://wiki.scn.sap.com/wiki/display/NWTech/SAP+Calendar+Master

En tiempo difíciles seguimos al pie del cañón compartiendo conocimiento. Las cosas se están poniendo muy feas en España, como en Italia y parece que va llegando a otros países. Así que cuidaros y no salgáis a la calle más que para lo estrictamente necesario. Como decía ayer un militar, cada persona que no sale es un virus menos que encuentra “huésped” para poder seguir viviendo y haciendo daño. Es un trozo de batalla ganada. Espero que estáis bien, de verdad.

En el post de hoy vamos a hablar de la forma de concluir pedidos de venta. Por diferentes circunstancias, uno o varias posiciones de un pedido de venta pueden no suministrarse o los servicios descritos en ellas no ser llevados a cabo. Por ejemplo:

• Roturas de stock: no tenemos disponibilidad de la mercancía. Tenemos problemas de suministro por parte de nuestros proveedores o en los mismos procesos de producción dentro de la compañía. Estos materiales puede que nunca se suministren o simplemente haya un retraso en la entrega hacia una fecha posterior.
• Productos obsoletos: en ocasiones cambian los catálogos de productos o servicios. Un pedido se registra con una referencia anterior, que será posteriormente sustituida en el pedido por un articulo o servicio diferente.
• Anulación del pedido: el cliente nos comunica la cancelación de un pedido que todavía no se ha suministrado.
• Cambios en los pedidos: el cliente nos comunica cambios en el pedido, posiciones que no desea que se suministren, corrección de errores, etc.

Seguro que se os ocurren muchos más ejemplos.En estos casos podríamos decidir eliminar las posiciones del pedido, incluso el documento completo, pero perderíamos la trazabilidad de las operaciones gestionadas con nuestro clientes. Para evitar esto, Sap nos proporciona el Motivo de rechazo (Reject reason en Ingles), para poder gestionar situaciones como estas.

El motivo de rechazo se gestiona a nivel de posición, teniendo disponible una actualización en masa dentro de la transacción VA01/VA02 para poder rechazar posiciones de forma colectiva.

Podemos parametrizar tantos motivos de rechazo como necesitemos para identificar cada posible situación que queramos tener identificada.

¿Por que es necesario rechazar las posiciones?

Las posiciones rechazadas no se van a continuar gestionando en el flujo logístico. Por tanto, no se realizará su entrega ni tampoco su facturación (incluso en posiciones no susceptibles de entrega como servicios, notas de cargo o abono, etc).

Si no utilizáramos un motivo de rechazo, los documentos se quedarían “abiertos” indefinidamente y nos molestarían en los diferentes procesos. Igualmente impedirían en el futuro tareas como las de archivado (borrado físico de los documentos de la base de datos).

Por ejemplo, un pedido en el que he facturado 4 posiciones, pero me he dejado 1 abierta, tiene este status en el flujo de documentos:

En cambio, si rechazamos la posición que no hemos podido servir al cliente, la situación sería esta:

El documento se da por concluido y ya no nos aparecerá como pendiente en nuestras transacciones estándar (VA05, VA05N, VA06) o en los informes Z que hayamos desarrollado en nuestra instalación.

Además, a nivel de tablas tenemos una forma fácil de consultar si en un documento hay posiciones rechazadas (tanto a nivel de cabecera, con la tabla de status VBUK, como a nivel de posición con la tabla VBUP).

Parametrización de los motivos de rechazo

Los motivos de rechazo se configuran desde la transacción OVAG o en la ruta de customizing Comercial –> Ventas –> Documentos de Ventas –> Posición documento ventas –> Definir motivos de rechazo.

Basicamente indicamos un código y su correspondiente descripción.

Ahora, en este punto, nos hacemos una pregunta. ¿Que ocurre con el importe de las posiciones rechazadas en un pedido? ¿Acumula al total del pedido?. La respuesta es: depende de como hayamos configurado el motivo de rechazo, en concreto el campo “Estad” en la configuración.

Si dejamos el valor en blanco, el importe si se acumula, aunque las posiciones estén rechazadas (esto no significa que se vaya a facturar). Esto podría darnos información sesgada en los informes o dar lugar a análisis incorrectos. Por ejemplo, en mi pedido:

La posición 10, rechazada, esta sumando su importe al valor neto del pedido. Por tanto, en la configuración de los motivos de rechazo nunca se debería de dejar el valor en blanco para evitar esto.

Los correcto sería utilizar uno de los dos valores siguientes en la configuración:

• X: no se acumula importe al valor neto del pedido. Pero si se puede añadir a los importes del sistema info de ventas (LIS/SIS).
• Y: no se acumula importe al valor neto del pedido ni tampoco a los importes del sistema info de ventas.

De esta forma, nos aseguramos que los importes de posiciones rechazadas no se suman al total del pedido.

En nuestro ejemplo, un motivo de rechazo con el valor X no incrementa el importe neto del pedido.

Espero que os sea de utilidad.

Bibliografía:

https://blogs.sap.com/2012/06/28/ignore-net-value-of-rejected-item-from-total-sales-order-value/

En nuestro truco de hoy vamos a hablar de la transacción MIGO y de como incluir chequeos propios en la transacción, cuando queramos realizar nuestras propias comprobaciones fuera del estándar.

¿Que es la transacción MIGO?

La transacción MIGO es una transacción enjoy diseñada para realizar los movimientos de material en el sistema (modulo MM). Vino a sustituir a un conjunto de transacciones especializadas en cada clase de movimiento que existían en versiones anteriores.

Por ejemplo, la MB01, MB1A, MB1B, MB1C, son algunas de las transacciones previas.

Transacción MB1A para realizar salidas de mercancía

Todas estas transacciones quedarán obsoletas con S4/HANA y ya no será posible utilizarlas mas.

Cuando Sap desarrolló la MIGO intento mejorar la experiencia de usuario y que la mayoría de operaciones relacionadas con gestión de stocks se pudieran realizar desde una única interfaz de usuario.

Transacción MIGO

La transacción es dinámica y varia su contenido según el tipo de operación  y la clase de movimiento de material que estemos realizando. Además, tenemos todos los campos disponibles en una única pantalla con diferentes secciones.

¿Como personalizar la transacción?

Mediante parametrización, se puede modificar el comportamiento de algunos campos, según cada clase de movimiento. Por ejemplo, podemos hacer un campo opcional u obligatorio.

Configuración de campos en la MIGO por clase de movimiento

Las parametrizaciones relacionadas con la MIGO las tenéis en la ruta: Gestión de materiales –> Gestión de stocks e inventario –> Parametrizaciones para transacciones Enjoy –> Parametrizaciones para movimientos de mercancia (MIGO).

Por ejemplo, también podréis hacer obligatorios campos a nivel de cabecera en la transacción.

Ademas, mediante programación podemos en la transacción MIGO añadir nuestro propios campos si fuera necesario. Para ello podéis utilizar la BADI MB_MIGO_BADI que permite realizarlo. Os dejo un vídeo de como hacerlo. En la sección de Bibliografia tenéis dos ejemplos más de personalización utilizando esta BADI.

¿Como incluir nuestras propias validaciones?.

Si lo que necesitáis hacer es añadir verificaciones adicionales en la transacción, la alternativa sería utilizar la BADI MB_MIGO_ITEM_BADI. Algunas consideraciones sobre esta BADI:

• La badi es llamada cuando una nueva linea es insertada en la MIGO o cuando una linea existente se modifica.
• Si los cambios se realizan en la cabecera, no se llama a la BADI si no hay cambios en las posiciones.
• Toda la información de la cabecera y de las posiciones es transferida a la BADI para que pueda ser utilizada para realizar las comprobaciones.
• En la BADI se puede ademas realizar la modificación del almacén o del texto de posición.

En mi ejemplo, estoy verificando que posiciones de pedido que se gestionan con entrega entrante no se contabilice la entrada de mercancía desde la MIGO, sino desde la VL32N.

Estos son los parámetros que se pueden gestionar en la BADI:

En la estructura ET_RETURN podemos pasar los mensajes que queremos que se devuelvan al usuario (E Error, W Warning, etc).

Cuando estoy en la transacción, al intentar hacer el movimiento de mercancía, se realiza la comprobación y se dispara el error:

Podríamos haber utilizado igualmente la BADI MB_CHECK_LINE_BADI método CHECK_LINE, pero a mi me parece más sencilla la implementación que os he mostrado. Podéis ver un ejemplo de implementación en este enlace de implementación.

Espero que os sea de utilidad.

Bibliografia:

https://blogs.sap.com/2013/06/14/how-to-create-a-custom-tab-for-migo-item-details/

Video: Add Custom Tab Screen in MIGO

http://saptechnical.com/Tutorials/ExitsBADIs/MIGO/screenexit.htm

BAdI MB_MIGO_BADI – In the middle of nowhere: http://scn.sap.com/docs/DOC-68084

https://blogs.sap.com/2018/11/21/adding-multiple-messages-in-migo-transaction-via-mb_check_line_badi/

En el libro “ABAP Development for Materials Management in SAP: User Exits and Badis” de Jürgen Schwaninger (Sap Press), tenemos ejemplos de código de la badi Ejemplos de código de la Badi MB_MIGO_BADI, para añadir campos de cliente en la transacción MIGO así como para realizar chequeos con el método MB_MIGO_ITEM_BADI (páginas 125 a 127). Os recomiendo la lectura de la versión parcial de este libro disponible gratuitamente.

En varias entradas anteriores del blog vimos varias formas de personalizar el maestro de clientes. 

• Chequeos personalizados:  usando la ampliación SAPMF02D (CMOD), podiamos añadir nuestra propias verificaciones en la creación o modificación de clientes. Por ejemplo, control de NIF duplicados, verificación de valores o chequeo de dependencias entre ellos, etc. Ver información completa en el enlace.

• Inicializar valores por defecto al crear un cliente: en una entrada posterior hablamos de la forma de poder dar valores por defecto en la creación de los clientes, utilizando la Badi CUSTOMER_ADD_DATA.   Utilizando el método PRESET_VALUES_CCODE podemos inicializar valores a nivel de sociedad y con el método PRESET_VALUES_SAREA podemos inicializar valores a nivel de organización de ventas. Ver información en el enlace.

Esto es muy útil, pues nos permite definir valores por defecto en la condición de pago, via de pago, grupo de tesoreria, etc, por ejemplo, al crear un cliente (por grupo de cuentas, por país, etc). En la badi tenemos disponible la información introducida hasta el momento por el usuario (KNA1, KNB1 o KNVV) y podemos hacer las inicializaciones deseadas.

Añadir campos adicionales en el maestro de clientes

Si lo que necesitamos es añadir nuestros propios campos en el maestro de clientes, podemos utilizar igualmente la Badi CUSTOMER_ADD_DATA, en combinación con la badi CUSTOMER_ADD_DATA_CS.  Con esta ultima gestionamos añadir las pantallas en la transacción, en combinación con la otra BADI donde gestionamos la gestión de los datos.

Os recomiendo la lectura del blog saptechnical.com , donde se explica paso por paso todas las tareas de programación a realizar para realizar la ampliación. En mi ejemplo, siguiendo las indicaciones, he añadido una nueva sección de datos (aparecerá un botón en la parte superior de la pantalla, debajo del titulo).

Al seleccionarlo, nos llevará nuestra pantalla de datos propios, donde incluiremos los campos necesarios.

En la Badis, con la ayuda de un abaper, incluiremos la lógica de comprobación de los datos así como el guardado en la base de datos (como una extensión de las tablas de cliente o en tablas Z).

En cualquier caso, antes de ampliar el maestro recomiendo utilizar los campos disponibles en el estándar (que son muchos), incluso utilizar el sistema de clasificación, que también nos permite definir campos a completar en el maestro sin necesidad de programar (utilizando las clases).

En la imagen podéis ver la asignación de una clase sencilla con dos características al cliente para indicar información adicional. Sin necesidad de programar y con búsquedas disponibles en el estándar por defecto. Hablaremos de esto en una próxima entrada el blog.

Verificación de clientes utilizando los mensajes estándar

Para terminar, como bien nos explica Anupa Wijesinghe en su blog, y para completar las posibilidades de personalización, existe una forma estándar de controlar algunas situaciones relacionadas con el maestro de clientes, sin necesidad de programar. En la ruta de customizing Logística en general –> Interlocutor comercial –> Clientes –> Control –> Modificar control mensajes para maestro deudores.

Existe una gran cantidad de mensajes que se pueden configurar, pero me han parecido especialmente interesantes los que nos permiten controlar la duplicidad de identificador fiscal ( mensajes 272 o 273) o la duplicidad de direcciones (que nos puede avisar de la duplicidad de un cliente, mensaje 145).

Para el ejemplo, he configurado el mensaje 145 como activado (tipo de mensaje I, se mostrará un pop-up). Al crear un cliente nuevo o modificar uno ya existente, si existen uno o varios clientes con la misma dirección (nombre, domicilio, etc), el sistema muestra un aviso y nos enseña la lista de los clientes con los mismos valores.

Una funcionalidad interesante, aunque limitada si queremos lógicas de comprobación más complejas. En ese caso, utilizaremos las opciones descritas anteriormente.

Espero que os sea de utilidad.

Bibliografía:

http://www.learnsaptips.com/2020/01/message-control-settings-for-customer.html

http://saptechnical.com/Tutorials/ABAP/XD01/XD01.htm

http://abaperitos.blogspot.com/2009/03/badis-programacion-abap.html

https://www.apprisia.com/blog/sap-abap/learn-how-to-enhance-xd02-in-5-simple-steps-2/

En una entrada anterior del blog hablamos del motivo de rechazo en los pedidos de venta y como gestionar las posiciones que no iban a ser servidas a nuestro clientes y sus implicaciones.

En nuestro truco de hoy vamos a hablar de otro tema relacionado con los pedidos de venta, en concreto sobre los bloqueos de Entrega y Facturación.

¿Para que valen los bloqueos?.

En los pedidos de venta disponemos de dos tipos de bloqueo de forma estándar (aparte del bloqueo de crédito, del cual hablaremos próximamente en nuestro blog): bloqueo de entrega y bloqueo de factura.

Bloqueo de entrega.

Se puede indicar tanto a nivel de cabecera como a nivel de reparto en las posiciones en el pedido de ventas. También en las entregas se puede indicar a nivel de cabecera. El bloqueo de entrega, dependiendo de su parametrización, nos puede impedir las siguientes cosas:

• Transferencia de necesidades: impide que se transfiera la necesidad de stock del pedido a la planificación para el documento o posiciones bloqueadas. Es muy útil para restringir que determinados documentos tenga impacto en la planificación y el aprovisionamiento (producción o compras).
• Creación de las entregas: si se asocia el motivo de bloqueo de entrega a la clase de entrega, el sistema dará un mensaje de error cuando intentemos crear una entrega a partir de un pedido que tenga asignado ese bloqueo.
• Aparición del documento en los pools de trabajo de las entregas (VL10X). Con esto evitamos que los operarios de almacén tengan estos documentos en sus pools de trabajo.
• Procesos de picking o de contabilización de mercancía: si el bloqueo está en la entrega, se impedirá realizar estas actividades.

• Generación de mensajes en la entrega: para evitar que se impriman formularios o se generen mensajes automáticos (tipo EDI o integraciones con otros sistemas, por ejemplo) (si el bloqueo esta en la entrega).

El bloqueo se pueden predeterminar a nivel de cliente, de forma que cualquier documento que creemos para un solicitante heredará el bloqueo de entrega indicado a nivel general o a nivel de área de ventas (transacciones XD01/XD02 o VD01/VD02).

Esto es útil para determinados clientes problemáticos para los que queremos evitar operaciones (problemas de pagos, verificación de documentación, aspectos legales). Ojo, la transferencia del bloqueo del cliente al pedido solo se realizará si se configura adecuadamente el motivo de bloqueo.

También podremos configurar los documentos de venta (transacción VOV8) para que se inicialicen por defecto con un motivo de bloqueo de entrega o de factura al crear un nuevo documento.

De esta forma, nos aseguramos que determinadas clases de documento ya nazcan por defecto bloqueados (por ejemplo, las solicitudes de cargo o abono, las devoluciones, que suelen ser documentos que han de ser autorizados por un responsable).

Bloqueo de factura.

Se puede indicar a nivel de cabecera y a nivel de posición en el pedido (también a nivel de cabecera y posición en la entrega). Este bloqueo impide realizar los procesos de facturación. Cuando intentemos realizar la factura de un pedido con bloqueo de factura, la creación de la factura no será posible y se mostrará un mensaje similar a este:

Como hemos indicado antes, se puede predefinir en el customizing que un pedido ya nazca con el bloqueo de factura por defecto. Resulta una forma muy sencilla de evitar que se facturen documentos por error que requieren una verificación adicional. También se puede indicar un bloqueo automático de factura por tipo de posición en la parametrización.

Indicando un bloqueo de factura en el cliente (datos de bloqueo), también podremos impedir que se creen las facturas de determinadas clases (ver sección de parametrización más abajo), si al cliente se le ha asignado uno en sus datos maestros.

Listado de documentos bloqueados.

Existen varios transacciones para consultar los documentos bloqueados. 

• VA14L: listado de documentos bloqueados para entrega. Nos permite visualizar el origen del bloqueo (cabecera, reparto de una posición, status de usuario o control de crédito).

• V23: documentos bloqueados para la facturación. Con un formato similar al informe anterior, podremos ver si el bloqueo esta a nivel de cabecera o posición, o viene determinado por el control de crédito o los status de usuario en el documento.

Parametrización de los bloqueos.

La parametrización de los bloqueos de entrega se realiza en la ruta de parametrización Logistic Execution –> Expedición –> Entregas –> Definir motivos de bloqueo en la expedición. La parametrización consta de dos partes:

• Definición de los motivos de bloqueo: en la opción “Entregas: Motivos/Alcance de bloqueo” creamos los motivos y como es la repercusión en un documento que tenga este bloqueo.

El significado de cada uno de los flags es el siguiente:

• • Bloqueo Pedido: si se marca, y un cliente tiene este motivo, será transferido automáticamente al pedido y se emitirá un aviso al crear o modificar el pedido.
  • Bloqueo necesidades: impide que se transfieran necesidades a la planificación para el pedido con este bloqueo.
  • Bloqueo Pool entregas: impide que un pedido con este bloqueo aparezca en el pool de entregas (se filtran de forma automática los motivos de bloqueo que tenga marcado este flag).

• • Boqueo impresión: impide que se generen los mensajes para entregas con este bloqueo.
  • Bloqueo Picking: si una entrega tiene este motivo asignado (recordemos que el motivo de bloqueo de entrega se transfiere desde el pedido al crear la entrega), no se permitirá realizar el picking.
  • Bloqueo Salida mercancías: ídem que en el punto 5, pero para contabilizar la salida de mercancía de la entrega.

• Repercusión del bloqueo según clase de entrega: en la opción ” Entregas: Bloquear” realizamos una asociación clase de entrega y motivo de bloqueo de entrega. Esto determinará que será imposible crear una entrega de la clase XX a partir de un documento de venta que tenga asignado los motivos de bloqueo indicados.

Para los bloqueos de factura, utilizaremos la ruta Comercial –> Facturación –> Documentos de facturación –> Definir motivos de bloqueo para la facturación. La parametrización consta igualmente de dos partes.

• Definición de los códigos de bloqueo: en la opción “Factura: Motivos de bloqueo” tenemos una parametrización sencilla donde solamente se definen los códigos de bloqueo y su descripción. Los bloqueos asignados a los documentos (tanto pedidos como entregas), serán automáticamente efectivos de cara a impedir la creación de la factura.

• Bloqueos por clase de factura: en la opción “Asignar clases de factura a motivos de bloqueo”. Con esta parametrización conseguimos que si el cliente tiene asignado el motivo de bloqueo para factura XX y va a crear una factura del YYYY, y este factura del tipo YYYY esta asignado en el custo al motivo de bloqueo, el sistema impedirá la creación de la factura. Con esta parametrización conseguimos que se impida facturar determinadas clases de facturas a un cliente que este bloqueado (aunque los documentos no estén bloqueados).

Control de modificaciones de los bloqueos por autorizaciones.

Hemos visto como funcionan los bloqueos, pero ¿que ocurre si cualquier usuario que tiene acceso a la transacción VA02 puede realizar la modificación del pedido y quitar o poner estos bloqueos?. En ese caso perdemos toda la justificación de utilizar los bloqueos y pierde sentido el control que queremos realizar.

La respuesta es que podemos evitar que cualquier usuario realice la modificación de los bloqueos (tanto establecerlos como eliminarlos), utilizando los objetos de autorización. 

Con el objeto de autorización V_VBAK_AAT (lo podéis consultar utilizando la transacción SU21, en la sección SD), podemos restringir, por clase de documento, si un usuario puede bloquear un pedido (tanto bloqueo de entrega como de factura) o si tiene autorización para eliminar el bloqueo.

Para mi ejemplo, he preparado un rol especifico para un usuario al cual le dejo crear pedidos, pero no le permito ni bloquear ni liberar documentos. He utilizado la transacción PFCG para crear el rol, dándole acceso a las transacciones de creación de pedidos (VA01/VA02/VA03) e indicando para el objeto V_VBAK_AAT los siguientes valores:

Vemos que la autorización se define por clase de documento, por lo que podremos realizar distintas estrategias según la clase de documento concreta (por ejemplo, los documentos de venta normal por un lado (TA), solicitudes de cargo a abono por otro (G2,L2), las devoluciones, etc).

Al asignar el rol al usuario, este intenta modificar un pedido existente y quitar el motivo de bloqueo de entrega, el sistema le mostrará el mensaje “Ud. NO está autorizado para desbloquear!”.

Lo mismo, en este caso, si el usuario intenta bloquear un pedido ya liberado, el campo de  Bloqueo esta cerrado y el usuario no podrá indicar un motivo de bloqueo.

Podemos consultar con la transacción SU53 los objetos de autorización verificados que han impedido al usuario realizar la acción (en este caso, para liberar necesitaba autorización a la actividad 43 para la clase de documento G2, pero carecía de ellos en los roles de autorización que tenía asignados).

Jugando con las actividades ’05 – Bloquear’ y ’43 – Liberar’ podremos montar los roles de autorizaciones con las acciones concretas que podrá realizar cada usuario. Por ejemplo, un backoffice que crea los pedidos tendrá seguramente autorización para crear documento y bloquearlos, pero nunca para quitar un bloqueo.

Un superusuario o responsable tendrá acceso a todas las actividades. Un responsable comercial quizás tendrá acceso a liberar determinadas clases de pedido, según su área de responsabilidad.

Otras maneras de gestionar bloqueos en los documentos de venta.

Si lo que necesitamos es establecer en un documento de venta bloqueos que sean supervisados o liberados por varios usuarios, la funcionalidad de bloqueo no será suficiente y tendremos que utilizar los “Esquemas de Status” asociados al documento.

Con esta funcionalidad podemos asociar al documento (a nivel de cabecera o para cada posición), una secuencia de estados. Resumiendo, los que nos permite SAP en este caso:

• Definir una secuencia de estados asociados al documento a posición.
• Definir la forma de hacer la transición de los estados hacia adelante o hacia atrás (anulación de la liberación).
• Controlar las acciones que se pueden hacer con los documentos en cada estado: facturar, entregar, crear un documento posterior.

• Delimitar que usuario puede asignar cada status: de esta forma solo el liberador podrá mover el documento a un estado determinado.

En una entrada anterior del blog explicamos en profundidad como configurar esta funcionalidad estándar y todos los detalles a tener en cuenta.

Al final quedo una entrada un poco larga, pero había muchos puntos que aclarar sobre el tema de hoy. Espero que os sea de utilidad.

Bibliografía:

Gracias como siempre a Anupa Wijesinghe por la información que comparte en su blog learnsaptips.com:

http://www.learnsaptips.com/2019/11/deactivate-sales-order-block-removal.html

https://saptricks.wordpress.com/2013/03/09/truco-48-liberacion-en-pedidos-de-ventas/

Si queréis saber más sobre autorizaciones os recomiendo la lectura de estos dos posts anteriores del blog:

https://saptricks.wordpress.com/2013/03/22/truco-49-autorizaciones-desde-el-modulo-de-organizacion-roles-de-usuario-con-pfcgi/

https://saptricks.wordpress.com/2013/03/24/truco-50-autorizaciones-desde-el-modulo-de-organizacion-ppocw-y-ppomw-y-ii/

https://saptricks.wordpress.com/2011/06/26/truco-14-analisis-de-autorizaciones-traza/

En nuestro truco de hoy volvemos al módulo de Gestión de Materiales (MM), y vamos a hablar de la transacción MIRO. Como sabéis, esta transacción es la función principal para el registro de facturas de proveedores, en escenarios en los que utilizamos los pedidos para gestionar nuestro procesos de aprovisionamiento.

Cuando no hay pedido, se podría registrar directamente la factura en Finanzas, utilizando la transacción FB60.

La transacción MIRO es una transacción Enjoy que tiene integradas en una única pantalla toda la funcionalidad necesaria para poder registrar nuestras facturas contra pedido.

Es una transacción nada sencilla y que suele dar muchos quebraderos de cabeza a los usuarios, por la cantidad de alternativas de funcionamiento que tiene. Además, nos permite gestionar los diferentes tipos de compras que permite el estandar:

• Compras a stock.
• Compras imputadas con o sin entrada de mercancía
• Compras de servicios
• Gestión de costes indirectos planificados o no planificados en los procesos de compra.
• Compras provenientes de otros módulos, como gastos de transporte (LE-TR) o de otros sistemas, como SAP Transport Management (TM).
• Gestión de abonos o cargos/descargos posteriores.

En nuestro post de hoy vamos a hablar de las opciones que nos deja Sap para poder personalizar la transacción y donde podemos “meterle mano”.

Exit disponibles.

Aunque os recomiendo utilizar las BADIs, existen gran cantidad de ampliaciones clásicas (CMOD) para poder personalizar la transacción. Son las siguientes:

• MM08R001 Liquidación facturación (verificación facturas convencional): nos permite intervenir en el proceso de liquidación de la autofacturacion (Sap lo llama ERS). Podemos modificar el estándar en el proceso de creación de las autofacturas a través de la transacción MIRO.
• MM08R002 Verificaciones de tolerancia: personalización de la verificación de tolerancias o desviaciones en el momento de grabar las facturas.
• LMR1M001 Transferencia de los datos de la cabecera del documento y de la posición de documento:  en esta ampliación podemos modificar la propuesta de imputación, añadir campos Z en la cabecera del documento o realizar chequeos en los datos de la factura antes de contabilizar. Esta exit sería la que usaríamos para añadir nuestras propias verificaciones.
• LMR1M002 Modificación de cuenta para la determinación de cuentas de EM/RF: nos permite modificar los criterios para la determinación de la cuenta de facturas pendientes de recibir. De esta forma, sobre escribimos los valores determinados por la parametrización (OBYC), clase de cuenta WRX.
• LMR1M003 Asignación de números en la verificación de facturas de Logística: la numeración en la MIRO es un único contador por parametrización. Con esta exit, podemos personalizar la numeración de las facturas (por ejemplo, por sociedad). En un post anterior del blog hablamos de esta exit.
• LMR1M004 Textos de la posición en documentos subsiguientes: en esta exit podemos modificar el texto de posición que se transferirá al asiento contable en finanzas, cuando contabilicemos la factura.
• LMR1M005 Modificar criterios para liberación de contabilización de documentos: la exit se llama cuando se realiza la liberación de documentos preliminares.
• RMVKON00 Facturación de material en consignación/pipeline: nos permite modificar la creación automática de la factura que se produce en los procesos de liquidación de consigna de proveedor o pipeline (transacción MRKO).
• MRMH0001 Liquidación autofacturación (verificación de facturas en Logística): podemos modificar el estándar en el proceso de creación de las autofacturas a través de la transacción MRRL (por ejemplo, para la fecha de la factura, referencia, etc).
• MRMH0002 Recepción de factura EDI (verificación de facturas en Logística): tratamiento de los IDOCS de entrada para la creación de facturas. En ellos podemos cambiar la determinación de la sociedad o el proveedor, los indicadores de impuestos, imputaciones o realizar modificaciones en los segmentos de los idocs.
• MRMN0001 Edición de mensajes: tratamiento de mensajes asociados a la verificación de facturas.

Es muy habitual utilizar estas exits. Yo casi siempre he utilizado la de la personalización de la numeración de las facturas, verificaciones adicionales o aquellas relacionadas con los procesos de autofacturación o liquidación de consigna (donde el estándar tiene muchas limitaciones).

Badis disponibles.

A continuación vamos a hablar de las badis disponibles para el registro de facturas, donde tenemos un abanico más amplio de temas a personalizar (os recomiendo la lectura de la nota 1156325). Algunas de las badis mas interesantes son:

• INVOICE_UPDATE: esta diseñada para ejecutar chequeos durante la entrada de la factura o la contabilización en la transacción MIRO. Solo se pueden añadir mensajes en el método CHANGE_AT_SAVE  y no se puede realizar ningún cambio en los datos de la factura.
• MRM_HEADER_CHECK:  podemos utilizarla para realizar chequeos adicionales en la cabecera o en las posiciones de la factura.
• MRM_HEADER_DEFAULT: nos permite definir valores por defecto al entrar en las transacciones de registro de factura. Por ejemplo, la clase de documento financiero a usar en la contabilización, texto de cabecera, fecha de documento, etc.
• MRM_MRIS_HDAT_MODIFY: nos permite cambiar algunos campos de cabecera en la contabilización de planes de facturación (ejecución de la transacción MRIS).
• MRM_MRIS_IDAT_MODIFY: idem que la anterior, pero los cambios son en las posiciones de la factura, al ejecutar la liquidación de planes de facturación.
• MRM_MRKO_HDAT_MODIFY: en la liquidación de consigna o pipeline, con esta Badi podemos cambiar el vendedor o la clase de documento contable que se utiliza en la contabilización al ejecutar la transacción MRKO.
• MRM_PAYMENT_TERMS: esta badi se puede utilizar para cambiar las condiciones de pago en la cabecera de la factura (campos que intervienen en el cálculo de la fecha de vencimiento, ZFBDT, ZBD1T, ZBD1P, …, ZLSPR).
• MRM_RELEASE_CHECK: en esta badi podemos incluir criterios de chequeo adicionales antes de la liberación de facturas bloqueadas para el pago.
• MRM_TOLERANCE_GROUP: nos permite personalizar los grupos de tolerancia utilizados en la verificación de la factura (normalmente hay un grupo de tolerancia que se asigna en el proveedor, en los datos de sociedad). Esta badi cambiaría el grupo de tolerancia por el que nosotros indiquemos.
• MRM_TRANSACT_DEFAULT: cuando entramos en la transacción MIRO, el sistema nos ofrece una seria de opciones por defecto (que se quedan guardadas para cada usuario en la tabla ESDUS). Esas opciones corresponden a los valores utilizados en la última ejecución de la transacción. Con la BADI, podemos cambiar los valores propuestos por el sistema, cambiando los valores para los campos “Actividad”, Tipo de documento de referencia, Variante de visualización, o si aparece abierto el Pool de trabajo para documentos preliminares o aparcados o la estructura de pedido (secciones que se pueden abrir y cerrar a la izquierda en la pantalla de la transacción).

• MRM_UDC_DISTRIBUTE: en el estándar, los costes indirectos no planificados que se introducen en la cabecera de la factura, se distribuyen de forma proporcional al importe entre las posiciones de dicha factura. Con esta BADI podemos definir nuestros propios criterios de distribución de los costes. En la imagen podemos ver como hace el estándar el reparto de un coste indirecto (100 Euros en el ejemplo), en base al importe de cada una de las posiciones de la factura. Con la BADI podríamos modificar la forma de hacer este reparto.

• MRM_ITEM_CUSTFIELDS: para gestionar los campos de cliente a nivel de posición en la factura.
• MRM_ERS_HDAT_MODIFY: utilizada en la liquidación de la autofacturación (transacción MRRL), para cambiar la cabecera de la factura.
• MRM_ERS_IDAT_MODIFY: utilizada en la liquidación de la autofacturación (transacción MRRL), para cambiar las posiciones de la factura.
• INVOICE_BW: ejecutada en la transferencia de datos a BW. Nos permite ajustar las estructuras de comunicación para la información que se envía al sistema de reporting.
• MRM_BLOCKREASON_DELETE_CUST: esta badi se llama en la transacción de desbloqueo de facturas (MRBR) y nos permite establecer criterios para anular los bloqueos de factura.
• MRM_INVOICE_UPDATE: nos permite establecer chequeos al modificar o borrar facturas en determinadas circunstancias (al planificar una factura para el procesamiento en proceso de fondo, al registrar facturas erróneas mediante entrada EDI o al borrar un documento).

Ejemplo práctico.

En nuestro ejemplo vamos a realizar una mejora en la verificación de facturas doble, utilizando la BADI MRM_HEADER_CHECK. Como sabéis, el estándar tiene una verificación que nos permite controlar que una factura no se contabilice varias veces. La funcionalidad se activa en los datos maestros del proveedor,a nivel de sociedad, marcando el flag “Verif. fra.dob” (verificación de facturas doble).

Asociada hay una parametrización, donde se indica, por sociedad, como queremos que se haga esta verificación (transacción OMRDC).

Por defecto, el sistema compara los siguientes valores: sociedad, proveedor, referencia, fecha del documento, importe y moneda. Son muchos campos a revisar que pueden determinar que no se encuentra una factura duplicada, cuando realmente si lo es. Si desmarcamos el flag en la parametrización de la imagen, ese criterio no se utiliza para buscar (sociedad, referencia o fecha factura).

Para mejorar la verificación, hemos implementado la badi MRM_HEADER_CHECK para que se compruebe que la factura (buscando por referencia), no se repita el mismo año para el proveedor (en otra fecha) o no se repita en otro año.

method IF_EX_MRM_HEADER_CHECK~HEADERDATA_CHECK.

  DATA wa_rbkp     TYPE rbkp.
  DATA lv_document_nr TYPE rbkp–XBLNR.
  DATA: lv_duplic(1),
       lv_text(30).

  clear lv_duplic.
  IF sy–tcode = ‘MIRO’.
    IF i_rbkpv–xblnr NE space and i_rbkpv–lifnr is not initial.
      lv_document_nr = i_rbkpv–xblnr.

* Miramos que la factura, usando la referencia, ya exista en el mismo año
* con otra fecha. Con la misma fecha ya lo habra buscado el estandar.
        SELECT SINGLE * into wa_rbkp FROM  RBKP
                      WHERE  GJAHR  = i_rbkpv–gjahr
                      AND    XBLNR  = lv_document_nr
                      AND    BUDAT  <> i_rbkpv–budat
                      AND    LIFNR  = i_rbkpv–lifnr.
        IF sy–subrc eq 0.
           lv_duplic = ‘X’.
           lv_text = ‘Existe en el año, otra fecha’.
        else.
* Miramos que exista en otro año.
           SELECT SINGLE * into wa_rbkp FROM  RBKP
                      WHERE  GJAHR  <> i_rbkpv–gjahr
                      AND    XBLNR  = lv_document_nr
                      AND    LIFNR  = i_rbkpv–lifnr.
           IF sy–subrc eq 0.
              lv_duplic = ‘X’.
              lv_text = ‘Existe en otro año’.
           ENDIF.
        endif.
        if lv_duplic = ‘X’.
           message W000(zsistemas) with lv_text
                                     wa_rbkp–BELNR
                                     wa_rbkp–GJAHR.
        endif.
   endif.
  endif.
endmethod.

En cualquier caso, la verificación es un warning que avisa el usuario de la duplicidad de la factura, mostrándole el documento donde se produce la “colisión” y el motivo:

Es un ejemplo rápido de como podríamos establecer este tipo de control al grabar las facturas. Lo tendríamos que mejorar y optimizar con la ayuda de un abaper y realizar un análisis mas en profundidad de las casuísticas a controlar.

Bibliografía.

Campos de cliente en la BAPIs de creación de facturas de compra: https://apps.support.sap.com/sap/support/knowledge/preview/en/2149315

Añadir campos Z en la transacción MIRO: http://wiki.sdn.sap.com/wiki/display/Snippets/Display+customer+fields+in+header+of+logistics+invoice+verification+transactions

Nota 1156325 – BAdIs in the Logistics Invoice Verification environment MIRO

Numeración de facturas en la MIRO personalizada: https://saptricks.wordpress.com/2014/08/16/truco-69-numeracion-de-facturas-personalizada-compras-miro-y-ventas-vf01vf04/

En las entradas publicadas en el blog normalmente hablamos de funcionalidad de la versión ECC del ERP de SAP (6.0 EHPX, antes llamado R3). Hace unos meses hablamos de los cambios más relevantes que nos podemos encontrar en el nuevo sistema S/4HANA y la forma de acceder a un sistema Cloud gratuito de demostración que ofrece SAP (ver post aquí).

Hoy vamos a dar un salto adelante y vamos a empezar a descubrir en detalle los cambios que nos encontraremos cuando decidamos migrar nuestro sistema al nuevo S/4HANA o cuando nos encontremos en un proyecto de implantación con la nueva versión.

En concreto, vamos a hablar de unos de los cambios más importantes y que más afecta a la parte de Gestión de Materiales (MM) o Ventas (SD), los Business Partners.

Antes de entrar en materia, os recomiendo leer y conocer las llamadas Simplification Lists. Es un documento donde Sap nos detalla toda la funcionalidad liberada en cada versión de S/4HANA. Allí se enumeran desde las transacciones que desaparecen en la nueva versión, cambios en los modelos de datos, nueva funcionalidad liberada o cambios respecto a las versiones anteriores, detalle de notas asociadas a cada punto, etc. La relacionada con la versión 1909 tiene más de 1000 páginas, todo un reto para entender todas las implicaciones a las que nos vamos a tener que enfrentar en un proyecto de migración o una nueva implantación.

Business Partner Approach

En las versiones anteriores manteníamos los datos de nuestros clientes o proveedores en diferentes transacciones (FKXX/MKXX/XKXX para proveedores o FDXX/VDXX/XDXX para clientes), cada una con sus respectivas tablas según el ámbito organizativo de los datos (LFA1/LFB1/LFM1 para proveedores, entre otras o KNA1/KNB1/KNVV para clientes). Ademas de otros objetos de negocio como podían ser unidades organizativas, personas, etc.

En S/4HANA se sustituye este enfoque y pasamos al objeto BUSINESS PARTNER como elemento centralizado donde se realizará toda la gestión de datos maestros asociados a los clientes y proveedores.

Con el nuevo enfoque tenemos un único elemento organizativo (el Business Partner), al cual le podemos asignar diferentes roles según la relación que tengamos con el en nuestra organización. Por ejemplo, un empresa con la que trabajemos estará creada una única vez, pero podrá desempeñar el rol de cliente, de proveedor, etc. Esto nos permite trabajar con datos compartidos y unificados (datos de direcciones, contacto, datos bancarios), así como datos específicos asignados a cada rol (cliente en finanzas, cliente en ventas, proveedor en finanzas, proveedor en compras).

Ademas, con la utilización de este elemento central se solucionan limitaciones que teníamos en el antiguo ERP como:

• Definición de varias direcciones, cada una de ellas con un uso concreto.
• Validez temporal de los elementos (direcciones, datos bancarios).

• Ampliación de la información disponible en los datos maestros (por ejemplo, identificadores fiscales según el país).
• Definición de múltiples relaciones con el mismo BP.
• Máximo grado de compartición de datos maestros y su reutilización.

En S/4HANA, las transacciones clásicas desaparecen y cuando las utilicemos, el sistema nos redireccionará a la transacción BP.

Usando el mismo BP, y asignándole los correspondiente roles, podremos tener un cliente para Finanzas (rol FLCU00 FI Customer) o para utilizar en el módulo de SD (rol FLCU01 Customer para ventas).

O un proveedor (roles FLVN00 FI Vendor para ser utilizando en Finanzas y el rol FLVN01 Vendor para los datos de compras).

Funcionalidad.

A nivel funcional, la nueva transacción BP es bastante diferente a las clásicas que utilizabamos en la versión anterior. Cuando vayamos a crear un nuevo interlocutor (cliente o proveedor), lo primero que hacemos es crearlo de forma general, indicando que vamos a crear una organización y el BP role “000000 Business Partner (Gen)”. 

Es algo parecido a la creación de datos generales (a nivel de mandante) para un cliente o proveedor (direcciones, identificación fiscal, cuentas bancarias, etc).

Importante: en el campo Grouping indicaremos el valor que determinará la numeración del objeto (internamente también determinará el grupo de cuentas que se utilizará para la creación del interlocutor).

A continuación, una vez grabados los datos y asignada la numeración, podremos pasar a la ampliación del interlocutor con los diferentes roles. Entraremos en la transacción de nuevo en modo Update e indicaremos el nuevo rol que vamos a crear. Por ejemplo, con el rol FLCU00 FI Customer, crearemos los datos de Finanzas.

Estos datos los tendremos a nivel de sociedad. Los mismo posteriormente si queremos crear las vistas de venta, con el rol FLCU01 Customer.

Los datos requeridos en cada una de las secciones pueden variar según el BP role seleccionado. De esta forma, habremos creado el cliente y lo tendremos listo para utilizar tanto en finanzas (FI) como en ventas (SD).

Implicaciones técnicas.

La primera sorpresa, aparte de los cambios en la funcionalidad más que evidentes, es a nivel técnico. Resulta que el uso de los BP no implica la desaparición de los antiguas tablas de datos de clientes y proveedores, que se mantienen a nivel técnico por requisitos de compatibilidad y funcionamiento de los diferentes módulos (MM,SD, etc).

Para mantener este funcionamiento y que todo sea totalmente transparente para el usuario, Sap ha desarrollado lo que llama el Customer Vendor Interface (CVI), que permite, de forma automática, mantener la información en las tablas clásicas a partir de la información introducida en los Business Partner. Toda una sorpresa.

Esto significa que, al dar de alta o modificar los datos existentes en un BP, automáticamente se actualizaran las correspondientes tablas de proveedores o clientes preexistentes.

A nivel de tablas, tendremos la información de los Business Parters en tablas BUTXX, pero seguiremos teniendo nuestras queridas KNA1, KNB1, KNVV o LFA1, LFB1 o LFM1.

El CVI requiere una parametrización para definir las equivalencias entre los BP Grouping (es el elemento que nos permite realizar la numeración de los business partners y que se indica al crearlos), con los grupos de cuentas que utilizábamos en las transacciones clásicas de R3 al crear un cliente o proveedor.

Habrá que alinear la numeración del BP definida a traves del Grouping con la numeración asignada en los Grupos de cuentas (esto puede ser un tema bastante complicado en una migración desde un sistema previo con miles de clientes o proveedores ya definidos).

En la parametrización de la integración, asignamos al “Grouping” utilizado en el BP, el correspondiente “Account group” (grupo de cuentas), utilizado anteriormente al crear los clientes. Tanto para clientes, como proveedores (ver imagen siguiente).

En el apartado de bibliografía os he dejado al documento HANA Cookbook Customer Vendor Integration (CVI), y el BP_Conversion_Activities_Document,  donde se explica en detalle esta integración y la forma de configurarla.

Nota: la misma herramienta CVI nos permite preparar el upgrade a S/4HANA, de forma que cuando creemos un cliente o proveedor de la manera tradicional, el sistema creará automáticamente el BP asociado (para el periodo de transición antes de la migración y como una tarea necesaria dentro de este proceso). Y ya tendremos realizado uno de los pasos a realizar en la migración de forma previa.

Autorizaciones.

Además, tendremos que ajustar todos nuestros roles de autorización para trabajar con los nuevos objetos. Se mantendrán las autorizaciones clásicas para la compatibilidad con el antiguo modelo de datos, pero a su vez tendremos que habilitar acceso a las funciones de la BP con los objetos:

• B_BUPA_GRP – Authorization Groups: podremos utilizar estar autorización para indicar que Business Parters podran ser editados por el usuario en base al valor del campo “Authorization Group” dentro de los datos maestros. Por ejemplo, a todos los BP que le hayamos puesto el valor “GROUP” (empresas del grupo), solo podran ser matenidos con los usuarios que tenga este objeto con dicho valor.
• B_BUPA_ATT – Authorization Types: utilizando esta autorización, podemos definir que BP pueden ser mantenidos por el usuario, dependiendo de los valores de determinados campos. En la parametrización definiremos los nombres de los “Authorization types”  y los campos que podrán ser utilizados para el chequeo.
• B_BUPA_FDG – Field Groups: con esta autorización indicamos que grupos de campos y con que actividades pueden ser gestionados por el usuario (visualizados o modificados).
• B_BUPA_RLT – BP Roles: con este objeto de autorización vamos a indicar que BP roles podrán ser editados por el usuario.

Como podéis comprobar, el irnos a S/4Hana no va a ser un camino fácil ni es un simple cambio de nombre. Vamos a prepararnos para muchos cambios.

Bibliografía:

BP and CVI in SAP S/4HANA System Conversion.

HANA Cookbook Customer Vendor Integration (CVI): configuración de la integración de BP y clientes/proveedores clásicos utilizando CVI.

2265093 – S4TWL – Business Partner Approach

SAP S/4HANA Business Partner and Customer / Vendor Integration

BP_Conversion_Activities_Document

01_TOP-Item_MD_Business-Partner-Approach_Version5.0

https://blogs.sap.com/2019/08/06/how-to-create-a-bp-business-partner/

https://blogs.sap.com/2019/09/20/intelligent-erp-sap-s4hana-1909-release/

En nuestro truco de hoy volvemos a temas básicos pero que pueden ser útiles en cualquiera de los módulos de Sap en los que estemos trabajando. A quién no le ha ocurrido que se ha puesto a modificar una tabla de parametrización y, justo antes de transportar, se ha llevado la sorpresa de que los sistemas no estaban alineados y los valores no están iguales en el sistema de desarrollo y el de productivo. Por ejemplo, debido a:

• Pruebas de parametrización realizadas en desarrollo para comprobar una determinada funcionalidad o testar algún posible cambio.
• Cambios realizados directamente en productivo por alguna urgencia o motivo justificado (está práctica deberíamos de evitarla siempre).
• Transportes de Sap (instalación de Hot Packages), que hayan podido alterar entradas de parametrización estandar.

Para esos casos, Sap nos proporciona una herramienta muy útil que nos permite comparar dos mandantes / sistemas y analizar las diferencias para poder actuar en consecuencia y dejar los sistemas nivelados.

Comparación de tablas de parametrización.

Si lo que queremos hacer es simplemente comparar los valores de una tabla de parametrización entre diferentes sistemas, accederemos a la transacción SPRO, opción de menú Herramientas –> Objetos Customizing –> Comparación de objetos. Esto nos llevará a la transacción SCMP.

Al entrar en la transacción, indicaremos la tabla de customizing a analizar y el nombre de la conexión que nos permitirá acceder al mandante / sistema con el cual queremos realizar la comparación.

En mi ejemplo, estoy revisando la tabla de Clases de documento de ventas (TVAK), comparando mi mandante de trabajo actual con el mandante estándar de SAP (mandante 000). Las conexiones se definen en la transacción SM59.

En la comparación podremos establecer filtros e indicar que el sistema solo nos muestra las diferencias o todos los valores. En el ejemplo, he indicado que solo se me muestren las diferencias.

Cuando las entradas de la tabla existen en los dos mandantes/sistemas, y hay diferencia, el programa muestra las dos entradas, marcando en amarillo los valores que tienen diferencias.

Cuando las entradas solo existen en uno de los mandantes/sistemas, se muestra en la primera columna el valor L o R para indicar en que sistema están los registros (que no se encuentran en el otro sistema).

En mi caso, todo lo que aparece con la L es parametrización Z que he creado en el mandante 050 y que no esta disponible en el mandante 000.

Comparación completa.

Si lo que queremos hacer es una comparación completa de la parametrización entre diferentes sistemas o de un conjunto de objetos de parametrización, entonces accederemos a la transacción SPRO, opción de menú Herramientas –> Objetos Customizing –> Cross System Viewer. Esto nos llevará a la transacción SCU0.

En los criterios de selección podremos elegir el tipo de comparación a realizar, seleccionando los elementos a comparar. En mi ejemplo, he seleccionado toda la parametrización relacionada con Facturación (componente SD-BIL).

A continuación, el sistema nos pide una descripción para la ejecución de la comparación, y la conexión del sistema/mandante remoto sobre el cual queremos realizar la comparación:

Finalmente lanzaremos el proceso (en visible o en fondo). El sistema realizará la comparación entre los dos sistemas y nos mostrará un monitor con las diferencias encontradas por objeto:

Para ver los valores concretos de diferencias, seleccionaremos el elemento a visualizar y pulsaremos el botón “Comparación”.

Otra opción interesante es el botón “Entorno IMG”. Seleccionando el objeto, nos muestra la ruta de parametrización asociada.

Nota: dentro de los posibles criterios para realizar la comparación, podemos indicar una orden de transporte, si elegimos la opción de comparación llamada “Lst.materiale Customizing/transporte”:

Esta opción puede ser muy útil para realizar la comparación con los objetos que se incluyeron en ese transporte concreto y para los cuales tenemos dudas.

Igualmente podemos indicar una lista de tablas/vistas si lo deseamos, en la opción “Selección manual”.

Como podéis ver, puede ser una herramienta muy útil para solucionar problemas en la parametrización o para adelantar a posibles inconsistencias o errores al transportar ordenes con cambios relevantes. Espero que os sea de utilidad.

Bibliografia.

https://blogs.sap.com/2012/03/28/how-to-compare-table-content-or-configuration-settings-with-a-remote-system/

Aparte de las novedades en el modelo de datos, funcionalidad o nuevas aplicaciones Fiori, S/4HANA viene con algunas nuevas herramientas muy útiles para los consultores. En este post vamos a hablar en concreto de las nuevas transacciones de búsqueda que Sap ha habilitado. Realmente estas herramientas son anteriores a S4 (ver nota 2002588), pero las herramientas están disponibles ahora en todos los sistemas.

Acceso central a funciones de búsqueda.

Con la transacción SE16T tenemos disponibles diferentes buscadores que nos permiten:

• • Búsqueda de objetos.
  • Búsqueda de transacciones.
  • Búsqueda de tablas.
  • Acceso a otras transacciones de búsqueda en tablas: SE16N, SE16H, SE16S y SE16SL.

Veamos  en detalle cada una de estas opciones.

Búsqueda de objetos.

Con esta funcionalidad, podemos crear listas de tablas / campos dentro de las cuales  realizar búsquedas de valores. Para usar esta funcionalidad, habremos de definir en primer lugar esta configuración.

En mi ejemplo, quiero buscar el código de un cliente en los diferentes documentos de ventas. Para ello he indicado las tablas VBAK, LIKP, VBRK y VBFA, enumerando los campos en los que estoy interesado en buscar.

Una vez definido este conjunto, podremos indicar un valor en el buscador y el sistema nos buscará en las tablas indicadas, mostrándonos el total de aciertos, pudiendo navegar al detalle de los registros encontrados.

Lo mejor de todo es la velocidad, con resultados instantáneos mientras vamos modificando el valor de búsqueda. Aquí se nota la mano de la base de datos HANA.

La flexibilidad de poder definir donde queremos buscar y el poder indicar diferentes tablas nos ofrece una potencia brutal para tareas de comprobación, análisis de errores, tareas de auditoria, etc. 

Búsqueda de transacciones.

Al seleccionar este buscador, indicaremos el nombre de la transacción a buscar o su descripción. El sistema nos buscara en la SE93 (tabla TSTC) y nos mostrará la lista de valores.

La búsqueda se puede afinar por idioma, realizando búsqueda exacto o con el valor de  alineado a la izquierda. Desde la lista de resultados podremos acceder directamente a las transacciones.

Búsqueda de tablas.

De forma similar al buscador de transacciones, tendremos en esta opción un buscador para encontrar tablas definidas en la base de datos.

Al igual que antes, indicaremos una cadena de búsqueda y el sistema nos devolverá la lista de tablas. Desde la lista de resultandos podremos navegar a la SE16N para ver en detalle el contenido de cada una de ellas.

Acceso a otras funciones de búsqueda.

Aquí es donde tenemos otras de las grandes novedades. Aparta del acceso a la conocida SE16N, de la cual no vamos a hablar, tenemos disponible nuevos buscadores con grandes novedades.

En la transacción SE16H, que es una evolución de la SE16N, tenemos disponibles nuevas opciones que nos permiten, ademas de las funciones existentes en la SE16N:

• Agrupar resultados: nos permite agrupar registros que tenga el mismo valor, añadiendo el sistema en los resultados un contador con el número de registros de cada valor. Para ello marcaremos el flag “Agrupar” en los campos que queramos que realicen la función GROUP en la consulta. En el ejemplo, he realizado una búsqueda en la tabla MARA, agrupando los resultados por Tipo de material y grupo de articulo. En los resultados puedo ver los registros totales por cada combinación de valores.

• Clasificación: indicar criterios de ordenación. Estos criterios no aplican en la salida de resultados, sino en el momento de lanzar la consulta a la base de datos.
• Uso de funciones de agregación: como máximo, mínimo o promedio.
• Definir join con otras tablas para obtener resultados juntando los registros de varias tablas. En nuestro ejemplo, hemos definido un join de la tabla MARA (maestro de materiales), con los datos de la vista de contabilidad (MBEW), indicando los criterios de selección para juntar en las dos tablas y los campos a recuperar de la tabla MBEW.

Cuando ejecutamos la consulta, en los resultados finales se muestran los campos seleccionados en los criterios de selección de la pantalla inicial, más los campos indicados en las tablas del JOIN.

Ademas, Sap ha añadido las transacciones SE16S y SE16SL que nos permiten realizar búsquedas masivas por valores en las tablas (ver nota 2002588 con ejemplos de su funcionalidad).

Por ejemplo, usando la SE16S he creado una búsqueda indicando el campo MATNR (número de material) e indicado un valor de búsqueda:

EL sistema me devuelve como resultado todas las tablas donde aparece el valor indicado en dicho campo:

Desde los resultados puedo navegar a la lista de resultados en cada tabla con la SE16H.

Bibliografia:

https://blogs.sap.com/2017/12/18/sap-s4-hana-offering-se16h-versus-se11se16nsqvi/

https://thinkdoforward.com/s-4hana-neue-coole-suchfunktion-se16t/

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

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

https://www.linkedin.com/posts/pranav-singh-0189b089_sap-s4-hana-offering-se16h-versus-se11se16n-activity-6756987868054396928-Ccln

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??).

• Truco 47. Proteccion de modificaciones de campos en maestro de clientes y proveedores.
• Truco 86. Proteger agrupaciones libres de clientes o proveedores por autorizaciones.
• Truco 79. Aprobación de modificaciones en campos sensibles del maestro de proveedores/clientes.

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.

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:

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

oy 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

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

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

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:

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 erroneos.

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.

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.

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

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/

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.