Truco 110. Ampliación del maestro de clientes. Configuración de mensajes estándar para chequeos.


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.

truco7_3

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

Truco110_img1

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

Truco110_img5

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

Truco110_img6

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

Truco110_img7

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.

Truco110_img2

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

Truco110_img3

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.

Truco110_img4

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/

 

 

Publicado en Abap, Formacion, Sap FI, Sap SD | Etiquetado , , , | Deja un comentario

Truco 109. Verificaciones de cliente en la transacción MIGO


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.

Truco109_img1

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.

Truco109_img2

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.

Truco109_img3

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.

Truco109_img4

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

Truco109_img6

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:

Truco109_img5

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.

https://s3-eu-west-1.amazonaws.com/gxmedia.galileo-press.de/leseproben/2504/373_ucg.pdf

 

 

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

Truco 108. Motivo de rechazo en pedidos de venta.


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.

Truco108_img1

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:

Truco108_img6

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.

Truco108_img7

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/

 

Publicado en Formacion, Sap SD | 2 comentarios

Truco 107. Trabajando con calendarios en SAP. Calculo de dias.


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.
Asignación de calendario a centro (transacción OX10)
  • 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.
Asignación de calendario a puesto de expedición (transacción OVLZ)
  • 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.
Definición de rutas en el customizing (transacción 0VTC)
  • 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.
Asignación de calendario a cliente en los datos de ventas (transacción XD02)
  • 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.
Utilización de calendario para restricciones de ejecución al crear un job
  • 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).

Definición de 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.

Definición de un calendario de fábrica

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

Resultado de la ejecución del módulo de función HOLIDAY_GET

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

Resultado de la ejecución del módulo de función DAY_ATTRIBUTES_GET

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

Publicado en Formacion, Sap Basis, SAP MM, Sap SD | Etiquetado , , , | 2 comentarios

Truco 106. Personalización de la transacción MD04 (Lista de necesidades).


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/

Publicado en Abap, Formacion, SAP MM, Sap PP | Etiquetado , , , , | 2 comentarios

Truco 105. Envío de email con resultados de un ALV.


En nuestro truco de hoy inauguramos una sección donde propondremos típicos ejemplos prácticos de necesidad funcional y como solucionarlos, incluyendo en muchos casos elementos de programación Abap.

Empezaremos con un ejemplo clásico donde necesitamos que un report Z envie por email los resultados calculados y que en modo interactivo se muestran en un ALV. Por ejemplo, en una ejecución del programa en fondo queremos que se envíen los resultados a uno o varios usuarios. O incluso el mismo usuario que esta viendo los resultados de forma interactiva quiere enviar la información a otro usuario de la empresa o un contacto externo (cliente o proveedor).

Para nuestro ejemplo, partimos de un desarrollo Z que nos permite listar información de pedidos de compra.


En el informe añadiremos en los criterios de selección del programa añadiremos un campo para poder introducir los destinatarios de email donde queremos enviar los resultados del ALV ( Select-options: so_email for adr6-smtp_addr. )

Y un botón para que el usuario, cuando lo desee, pueda lanzar el envío del correo electrónico que contendrá como anexo una excel con la información.

Ahora, la parte más compleja. La programación necesaria para convertir la tabla interna que estamos utilizando en el ALV en una hoja excel, construir el correo electrónico y enviarlo a los destinatarios.

Básicamente, utilizamos los siguientes elementos de programación:

  • Clase cl_salv_bs_tt_util: nos permite convertir una tabla interna a formato excel.
  • Clase cl_bcs: para gestionar el envío del correo.
  • Clase cl_document_bcs: para crear el correo, indicar asunto y texto, anexar excel, etc.

En mi programa, he creado un FORM que se ejecuta cuando el usuario pulsa el botón de enviar correo, que se llama lanza_envio_mail.

Desde allí se llama a send_email donde se hace todas las operaciones técnicas de convertir la tabla interna a un xls (form f_build_email_data ) y la construcción del correo electrónico.

FORM lanza_envio_email.
* miro si la tabla de emails esta vacia, intento meter el email del user
  DESCRIBE TABLE so_email LINES lv_num_emails.
  IF lv_num_emails = 0.
    SELECT SINGLE adr6~smtp_addr INTO so_email-low
         FROM usr21
           INNER JOIN adr6
              ON  usr21~addrnumber = adr6~addrnumber
             AND usr21~persnumber = adr6~persnumber
                 WHERE bname = sy-uname.
    IF sy-subrc EQ 0.
      lv_num_emails = lv_num_emails + 1.
      so_email-sign = ‘I’.
      so_email-option = ‘EQ’.
      APPEND so_email.
    ENDIF.
  ENDIF.
  IF lv_num_emails > 0.
* Construimos el catalogo para poder hacer la excel.
    CALL FUNCTION ‘LVC_FIELDCATALOG_MERGE’
      EXPORTING
        i_structure_name       = ‘ZME2L’
      CHANGING
        ct_fieldcat            = gt_fieldcat
      EXCEPTIONS
        inconsistent_interface = 1
        program_error          = 2
        OTHERS                 = 3.
    PERFORM modify_fieldcat.
* Constuimos el correo desde la tabla interna.
    PERFORM send_email.
  ENDIF.
ENDFORM.

*&———————————————————————*
*&      Form  SEND_EMAIL
*&———————————————————————*
*       text
*———————————————————————-*
*  –>  p1        text
*  <–  p2        text
*———————————————————————-*
FORM send_email .
  DATA:
    lt_binary_content TYPE solix_tab,
    lv_size           TYPE so_obj_len,
    r_mail            TYPE ace_generic_range_t,
    st_mail           TYPE ace_generic_range,
    lv_count          TYPE char2,
    lv_var            TYPE char8.
  FIELD-SYMBOLS: <fs_mail> TYPE any.
  REFRESH: lt_binary_content.
  CLEAR: st_mail, lv_count, lv_var.

* Construye el objeto binario de la excel a partir de la tabla interna
  PERFORM f_build_email_data CHANGING lt_binary_content
                                       lv_size.
  DATA: v_rundate        LIKE sy-datum,
        v_runtime        LIKE sy-uzeit,
        timestamp(20),
        lcl_send_request TYPE REF TO cl_bcs,
        lcl_document     TYPE REF TO cl_document_bcs,
        lv_subject       TYPE so_obj_des,
        lt_main_text     TYPE soli_tab,
        lv_text          TYPE soli,
        lv_filename      TYPE sood-objdes,
        lv_mailto        TYPE adr6-smtp_addr,
        lcl_recipient    TYPE REF TO cl_cam_address_bcs,
        lv_sent_to_all   TYPE os_boolean.

*–Run Date and Run Time
  v_rundate = sy-datum.
  v_runtime = sy-uzeit.
*  CONCATENATE v_rundate v_runtime INTO timestamp.
  WRITE sy-datum TO timestamp MM/DD/YYYY.
  TRY.
* ——– create persistent send request ————————
      lcl_send_request = cl_bcs=>create_persistent( ).

* ——– create and set document with attachment —————

* ASUNTO CORREO
      CONCATENATE ‘Informe de pedidos’  ‘ Fecha:’ timestamp
      sy-cprog sy-sysid INTO lv_subject
      SEPARATED BY space.

* Texto de correo (cuerpo del mensaje)
      CONCATENATE ‘En el Excel anexo se detallan los pedidos pendientes’
      ‘en el sistema.’ INTO lv_text SEPARATED BY space.
      APPEND lv_text TO lt_main_text.
      APPEND text-001 TO lt_main_text.
      APPEND text-003 TO lt_main_text.
      lcl_document = cl_document_bcs=>create_document(
      i_type = ‘RAW’
      i_text = lt_main_text
      i_subject = lv_subject ).                             “#EC NOTEXT

* Añadimos la excel al mensaje, poniendo nombre al fichero
      CLEAR: lv_subject.
      CONCATENATE ‘Pedidos’_’ v_rundate
      v_runtime ‘_’ sy-sysid INTO lv_filename.
      CALL METHOD lcl_document->add_attachment
        EXPORTING
          i_attachment_type    = ‘xls’
          i_attachment_subject = lv_filename
          i_attachment_size    = lv_size   “im_size
          i_att_content_hex    = lt_binary_content. “im_tab ).

* add document object to send request
      lcl_send_request->set_document( lcl_document ).

* ——— add recipient (e-mail address) ———————–
* create recipient object

*      Añadimos los destinatarios al correo
      LOOP AT so_email.
        lv_mailto = so_email-low. “ls_recipient-low.
        lcl_recipient = cl_cam_address_bcs=>create_internet_address( lv_mailto ).

* add recipient object to send request
        lcl_send_request->add_recipient( lcl_recipient ).
*        CLEAR: ls_recipient.
      ENDLOOP.
* Send now
      lcl_send_request->set_send_immediately( ‘ ‘ ).
* Outbox
      lcl_send_request->send_request->set_link_to_outbox( ‘X’ ).
* ———- send document —————————————
      lv_sent_to_all = lcl_send_request->send( i_with_error_screen = ‘X’ ).

      COMMIT WORK.

      IF lv_sent_to_all IS INITIAL.
        MESSAGE i500(sbcoms) WITH lv_mailto.
      ELSE.
        MESSAGE s022(so).
      ENDIF.

* ———— exception handling ———————————-
* replace this rudimentary exception handling with your own one !!!
*    CATCH cx_bcs INTO lcl_bcs_exception.
*      MESSAGE i865(so) WITH lcl_bcs_exception->error_type.
  ENDTRY.
ENDFORM.

FORM f_build_email_data  CHANGING p_lt_binary_content
         TYPE STANDARD TABLE
                             p_size TYPE so_obj_len.
  DATA: e_xstring TYPE xstring.
  DATA: mt_fcat     TYPE lvc_t_fcat,
        ms_fcat     TYPE lvc_s_fcat,
        st_fieldcat TYPE slis_fieldcat_alv.
  DATA: mt_data       TYPE REF TO data.
  DATA: m_flavour TYPE string.
  DATA: m_version TYPE string.
  DATA: mo_result_data TYPE REF TO cl_salv_ex_result_data_table.
  DATA: mo_columns  TYPE REF TO cl_salv_columns_table.
  DATA: mo_aggreg   TYPE REF TO cl_salv_aggregations.
  DATA: mo_salv_table  TYPE REF TO cl_salv_table.
  DATA: m_file_type TYPE salv_bs_constant.
  DATA: out_length TYPE i.
  FIELD-SYMBOLS <tab> TYPE ANY TABLE.

  CLEAR: e_xstring, ms_fcat, st_fieldcat, m_flavour, m_version,
         mo_result_data, mo_columns, mo_aggreg, mo_salv_table,
         m_file_type, out_length, mt_data.
*  REFRESH: it_fieldcat[].

*-It_final here is the final itab same parameter you pass in
* your alv grid
  GET REFERENCE OF gt_eban INTO mt_data.

*-Move your field catalog to mt_fcat make sure to populate
*-ms_fcat-seltext, because it can be that in your field cat the headings

*-are in seltext_l or seltext_m or seltext_s
  LOOP AT gt_fieldcat INTO ms_fcat.  “st_fieldcat.
*    MOVE-CORRESPONDING st_fieldcat TO ms_fcat.
*    MOVE: st_fieldcat-seltext_l TO ms_fcat-seltext.
    APPEND ms_fcat TO mt_fcat.
    CLEAR: ms_fcat, st_fieldcat.
  ENDLOOP.

  IF cl_salv_bs_a_xml_base=>get_version( ) EQ if_salv_bs_xml=>version_25 OR
     cl_salv_bs_a_xml_base=>get_version( ) EQ if_salv_bs_xml=>version_26.

    mo_result_data = cl_salv_ex_util=>factory_result_data_table(
        r_data                      = mt_data
        t_fieldcatalog              = mt_fcat
    ).

    CASE cl_salv_bs_a_xml_base=>get_version( ).
      WHEN if_salv_bs_xml=>version_25.
        m_version = if_salv_bs_xml=>version_25.
      WHEN if_salv_bs_xml=>version_26.
        m_version = if_salv_bs_xml=>version_26.
    ENDCASE.

    m_file_type = if_salv_bs_xml=>c_type_xlsx.
    m_flavour = if_salv_bs_c_tt=>c_tt_xml_flavour_export.

    “transformation of data to excel
    CALL METHOD cl_salv_bs_tt_util=>if_salv_bs_tt_util~transform
      EXPORTING
        xml_type      = m_file_type
        xml_version   = m_version
        r_result_data = mo_result_data
        xml_flavour   = m_flavour
        gui_type      = if_salv_bs_xml=>c_gui_type_gui
      IMPORTING
        xml           = e_xstring.
  ENDIF.

  CALL FUNCTION ‘SCMS_XSTRING_TO_BINARY’
    EXPORTING
      buffer        = e_xstring
    IMPORTING
      output_length = out_length
    TABLES
      binary_tab    = p_lt_binary_content.

  MOVE: out_length TO p_size.

ENDFORM.                    ” F_BUILD_EMAIL_DATA

El resultado el correo enviado podría ser algo parecido a esto, donde podemos personalizar en el código la información del asunto, texto del correo, nombre del fichero anexado, etc.

Con el fichero excel anexado con la información del ALV, todo construido con un desarrollo más o menos sencillo.

Espero que os sea de utilidad.

Bibliografia:

Gracias a Ralph Vincent Ferraren por su aporte en la Wiki del SCN de SAP:

https://wiki.scn.sap.com/wiki/display/ABAP/Send+an+Internal+Table+as+an+excel+attachment+via+email

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

Truco 104. Transporte de traducciones de textos entre sistemas.


En nuestro post de hoy vamos a hablar de como realizar el transporte este sistemas de las traducciones que podemos gestionar en los diferentes elementos de Sap (con un ejemplo concreto de traducción de un formulario Smarform).

Como todos sabéis, Sap es un sistema multilenguaje que nos permite trabajar con diferentes idiomas

Normalmente, los idiomas de logon están limitados según los países en los que utilicemos nuestro sistema Sap (por ejemplo, Español, Ingles, Alemán, Italiano, Francés), pudiéndose ampliar los idiomas disponibles con la instalación de los correspondientes paquetes de idioma.

Cuando tenemos disponibles varios idiomas, Sap nos permite traducir los diferentes elementos para que aparezcan en el idioma correspondiente cuando el usuario se conecta al sistema utilizando dicho idioma.

En la imagen, un ejemplo sencillo de traducción del campo “Lista de precios”. Al seleccionar la opción “Traducción” en las transacciones de parametrización, podemos seleccionar el idioma correspondiente e indicar el texto asociado al valor en el idioma deseado.

Esta parametrización queda registrada en la correspondiente orden de transporte, incluyendo los valores de traducción asociados al idioma correspondiente.

Sap nos facilito el trabajo al crear su sistema incluyendo en casi todos los objetos de parametrización una tabla paralela de textos (T189T en este caso), donde se pueden introducir las descripciones en los diferentes idiomas disponibles.

Cuando estamos trabajando con elementos de programación, la cosa se complica un poco más. En los programas Abap podemos traducir los textos de los elementos de selección, atributos del programa, textos de cabecera, etc, sin problema.

Si estamos trabajando con formularios, sabéis que podemos tener diferentes idiomas de comunicación con nuestros clientes o proveedores, y podemos gestionar los mensajes para comunicarlos con ellos en sus idiomas (o de forma general en ingles).

En nuestro truco de hoy nos vamos a centrar en como traducir un formulario (por ejemplo, un smartform) y luego como utilizar la herramienta de transporte de traducciones entre sistemas.

Partimos del supuesto que tenemos un formulario con la tecnología smartform ya creado para los pedidos de compra y nos piden traducirlo a un nuevo idioma objetivo.

Para ello (dada que la opción de Traducción no esta disponible directamente en la transacción Smartforms), accederemos a la transacción SE63 y seleccionaremos la opción de menú Traducción –> Objetos Abap –> Otros textos explicativos.

A continuación, seleccionaremos la opción FS Formularios y estilos –> SSF SAP Smart Form (tal y como vemos en la imagen superior). Finalmente indicaremos el nombre del formulario y el idioma fuente y destino para la traducción (siempre partimos de un idioma base sobre el que realizaremos la traducción al idioma destino).

Al pulsar tratar iremos realizando la traducción de los diferentes textos, pudiendo ver en la parte superior de la imagen el texto en el idioma origen y en la parte inferior los textos traducidos, asociados a cada etiqueta. Nos fijaremos en las etiquetas de cada texto para ver su descripción en Ingles(en este ejemplo), e introducir la correspondiente descripción en Español en la parte inferior, con el correspondiente formato asociado a cada uno de los textos.

Conforme vayamos traduciendo los textos, al activar, estos aparecerán en el formulario cuando el idioma de comunicación con el proveedor (en este caso es un pedido de compra), sea el idioma traducido.

Nota: si estáis trabajando con formularios ADOBE, la opción de traducción si esta disponible en la transacción SFP (donde se programan los formularios), aunque realmente nos llevará igualmente a la transacción SE63 (en la opción FS Formularios y estilos –> PDFB Formularios basados en PDF).

Una vez terminada la revisión de todos los textos, tendremos que realizar el transporte de las traducciones. Como habréis observado, el sistema no nos ha preguntado en ningún momento la orden de transporte en la que incluir.

Para poder realizar el transporte, utilizaremos la transacción SLXT (que ejecuta el report RS_LXE_RECORD_TORDER).

Indicaremos los siguientes valores:

  • (1) Idioma objetivo (destino) que queremos transportar.
  • (2) Descripción que se asociará a la orden de transprote.
  • (3) Tipo de orden: seleccionar la opción Orden de workbench.
  • (4) Fecha de tratamiento: para hacer la selección, fecha en la que hayamos hecho la traducción del formulario.
  • (5) Tipo de objeto: SSF en el caso de formularios Smartform.

Se nos generará la correspondiente orden de transporte donde tendremos incluida toda la traducción de los textos del formulario.

Una vez pasada la orden al sistema destino, podremos utilizar sin problema el formulario en el idioma correspondiente.

La herramienta SLXT esta disponible para transportar traducciones de otros elementos, no solo de los formularios (ver bibliografía, donde se muestra un ejemplo de traducción de la transacción IW32).

¡Feliz lectura!

Bibliografia:

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

Truco 103. Obtener valores de clasificación de objetos en SAP.


En nuestro truco de hoy volvemos a temas más técnicos, en concreto, vamos a hablar del sistema de Clasificación.

La clasificación es un componente transversal de Sap que esta disponible en diferentes elementos y que nos permite definir nuestro propios valores de clasificación en elementos tan diferentes como el maestro de materiales, clientes o proveedores; elementos de la gestión documental; definición de estrategias de liberación en solicitudes de pedido o pedido; lotes, equipos, avisos, etc. La clasificación también se utiliza en los materiales configurables, de cuyas posibilidades hablaremos próximamente en el blog.

Algunas de las categorías de clase existentes en SAP

Quien no ha tenido la necesidad de añadir criterios adicionales de clasificación en un material o el maestro de clientes o proveedores. La utilización del sistema de clasificación es la opción estándar, sin necesidad de realizar ampliaciones de las pantallas estándar o reutilizar campos que están definidos para otros objetivos.

En la imagen siguiente podéis ver un ejemplo de utilización de la clasificación en el maestro de materiales (categoría de clase 001).

Podemos tener disponibles diferentes clases según la naturaleza de nuestros materiales y asignarlas a estos, informando los correspondientes valores de clasificación. Lo bueno de utilizar esta funcionalidad es que tendremos disponible la búsqueda de los elementos de forma estándar utilizando las ayudas de búsqueda por la clasificación, así como las transacciones CL30N o CL31.

Incluso tenemos la transacción CLMM que nos permite realizar modificaciones en masa de los valores de clasificación.

Otro lugar muy frecuente donde se utiliza la clasificación es en los lotes (categoría de clase 023), donde podemos guardar las propiedades concretas de un subconjunto de stock, de acuerdos a sus propiedades físicas, analíticas, etc.

Para utilizar el sistema de clasificación, habremos de crear en primer lugar las características (transacción CT04). Cada característica puede ser del tipo CHAR, CURR, Numero, Fecha u Hora. Los valores de estas características pueden ser listas de valores indicados en la característica (o en una tabla de verificación), un módulo de función, valores libres (por ejemplo para un numero o una fecha), intervalos, varios valores a la vez, etc.

Una vez definidas las características, crearemos la clase utilizando la transacción CL02, indicando en la categoría de clase el valor correspondiente al ámbito donde se va a utilizar, así como las características relevantes para esa clase.

En nuestro truco de hoy vamos a hablar de la forma de leer la información de clasificación en nuestros desarrollos Z o en las adaptaciones al estándar que realicemos.

Básicamente, disponemos de varios módulos de función que nos permiten obtener toda la información de clasificación de nuestros objetos.

CLAF_CLASSIFICATION_OF_OBJECTS

Es uno de los módulos de función clásicos para leer la clasificación sin necesidad de acceder a las diferentes tablas (AUSP, KSSK, KLAH, etc).

  1. CALL FUNCTION ‘CLAF_CLASSIFICATION_OF_OBJECTS’
  2. EXPORTING
  3. classtype = ‘023’ “Categoria de clase
  4. features = ‘X’ “Leer características
  5. language = ‘S’ “Idioma
  6. object = w_l_object “Objeto. Por ejemplo, el material (ceros a la izda)
  7. objecttable = ‘MCH1’ “MARA,MARC,MCH1 o tabla relevante
  8. t_class = t_lclass “Tabla con la clase leida
  9. t_objectdata = t_objectdata “Tabla con los valores de clasificacion leidos
  10. EXCEPTIONS
  11. no_classification = 1
  12. no_classtypes = 2
  13. invalid_class_type = 3
  14. OTHERS = 4.
  15. IF sy-subrc = 0.
  16. endif.

Por ejemplo, para realizar la lectura de la clasificación de un material (categoría de clase 001), utilizaremos los siguientes parámetros:

En la tabla T_OBJECTDATA obtendremos los valores de clasificación encontrados.

Este modulo de función tiene un pequeño inconveniente, que para los valores CHAR, se recupera el valor de la descripción del valor de la característica en el idioma indicado, y no el valor neutral o del codigo. Por eso es recomendable utilizar el siguiente módulo de función.

La ventaja es que todos los valores de clasificación se devuelven en una única tabla interna.

BAPI_OBJCL_GETCLASSES

Con esta BAPI leeremos todas las clasificaciones de un tipo asociadas al objeto, sin necesidad de indicar la clase a leer. Básicamente, indicaremos:

  • OBJECTKEY_IMP: la clave del objeto para el que vamos a leer la clasificacion (por ejemplo, para el material indicaremos 18 digitos, con el número del material lleno con 0 a las izquierda (000000000000000043); para un lote MMMMMMMMMMMMMMMMMMLLLLLLLLLL; etc).
  • OBJECTTABLE_IMP: tabla asociada al objeto. Por ejemplo, MARA para materiales, KNA1 o LFA1 para clientes o proveedores, MCH1 para lotes, EQUI para equipos, etc).
  • CLASSTYPE_IMP: la categoria de clase que estamos buscando.
  • READ_VALUATIONS: siempre con el valor X, sino no lee los valores de características en la clasificación, solo la asignación a la clase del objeto.
  • LANGUAGE: idioma para las descripciones de los valores

Podéis utilizar la transacción SE37 en modo test para comprobar el funcionamiento de los módulos de función:

Los valores de clasificación será devueltos en tres tablas, según el tipo de dato de cada una de las características:

  • ALLOCVALUESCHAR: características del tipo alfanúmerico (CHAR).
  • ALLOCVALUESCURR: características del tipo CURRENCY.
  • AALOCVALUESNUM: características del tipo NUM, DATE o TIME.

Relacionados con este módulo de función disponemos de otros, como el BAPI_OBJCL_CREATE o BAPI_OBJCL_CHANGE que nos permiten crear los valores de clasificación o modificarlos desde un desarrollo.

VB_BATCH_GET_DETAIL

Si estais trabajando con la clasificación en los lotes, recuperar la información de clasificación es muy sencillo utilizando el módulo de función VB_BATCH_GET_DETAIL. Aquí simplemente habrá que indicar el material, el número de lote y centro, marcando el flag GET_CLASSIFICATION en la llamada.

En la tabla internat CHAR_OF_BATCH tendremos los valores de clasificación encontrados:

Bibliografia:

Algunas entradas relacionadas con el tema.

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

Truco 102. Primer contacto con S4/HANA. Sistema de demo gratuito.


Supongo que muchos de vosotros, que todavía trabajáis con el “viejo” SAP R3 (ECC), tenéis curiosidad sobre los cambios que implica el nuevo ERP y os gustaría tener contacto con un sistema de este tipo y poder experimentar que cosas nos esperan cuando dentro de poco en vuestra empresas migréis al nuevo S4/HANA (en principio hay tiempo hasta el 2025) o quizás participéis en un proyecto de implantación de la nueva versión.

En nuestro truco de hoy vamos a hablar de los cambios más importantes que suponen S4/HANA y la forma de conseguir acceso a un sistema de demo en la nube.

Podemos decir que S4/HANA es la nueva generación del SAP Business Suite, con una evolución tecnológica basada en dos pilares principales:

Base de datos In Memory.

Dejamos de poder utilizar cualquier base de datos (Oracle, SqlServer, DB2, etc) para trabajar exclusivamente con la base de datos de SAP, que también se llama HANA. Con esta tecnología, toda la información se encuentra en memoria, dando un salto exponencial a nivel de velocidad de acceso a los datos, abriendo un abanico de capacidad de proceso, análisis o comunicación con otros sistemas que antes no eran viables con la tecnología de las bases de datos tradicionales.

Las tablas en HANA están basadas en columnas (no en registros como en las bases de datos tradicionales). Esto produce un acceso mucho más rápido (solo los columnas relevantes necesitan ser leídas en las querys).

Igualmente se realiza una mayor compresión de los datos y operaciones de proceso en paralelo. Esto nos permite disponer de capacidades analíticas en el ERP.

A esto se le unen otras mejoras como que desaparecen las tablas agregadas (que se calcularan en tiempo real) o que se ha rediseñado el esquema de base de datos (que comentaremos más adelante).

Mejora de la experiencia de usuario con Fiori.

Como todo no podían ser mejoras técnicas, también ha priorizado el desarrollo de una nueva interfaz de usuario utilizando Fiori (lo que no significa que no tengamos disponible el clásico Sapgui o Netweaver para acceder a nuestras transacciones de toda la vida).

El usuario dispone en su interfaz Fiori de Tiles o cuadros de aplicación para acceder a las transacciones fiorizadas (o convertidas), que pueden incluir también información analítica.

Sap ha desarrollado multitud de aplicaciones Fiori para los diferentes procesos de negocio, dejando la puerta abierta para que sus clientes y partners desarrollen sus propias aplicaciones Fiori (ver documento https://experience.sap.com/documents/sap-fiori-ux-overview.pdf )

Para que os hagáis una idea, así “suena” la aplicación Fiori para crear pedidos de compra.

O una aplicación de finanzas con capacidades analíticas donde podemos ver las partidas abiertas de cliente por fecha de vencimiento.

O un informe de stock para un material, desde el cual podemos lanzar directamente movimientos de material sin necesidad de acceder a otra aplicación (ver la parte inferior de la imagen, donde están las operaciones que se pueden lanzar desde la consulta de stocks).

Toda una revolución en la interfaz de usuario a la que ya le hacia falta una modernización después de tantos años.

Rediseño de las tablas en la base de datos.

Aprovechando el cambio tecnológico de la base de datos, Sap ha realizado un rediseño total de la estructura de tablas, reduciendo el número de estas, eliminando tablas de agregados, etc.

La compatibilidad con las tablas antiguas se mantiene utilizando vistas, para que en nuestros desarrollos podamos seguir utilizando las tablas clásicas.

Para que os hagáis una idea sin profundizar demasiado:

  • Ventas: desaparecen tablas de status, índices.
  • Gestión de stocks: todas las tablas de stocks se simplifican en la tabla MATDOC. En la nota 2206980 se explican los cambios más relevantes en las tablas de este módulo.
  • Contabilidad: se unifican las tablas de finanzas y controlling.
  • Desaparecen las tablas de agregados y sus valores se calculan en tiempo real a partir de las tablas de movimientos.

Otros cambios importantes.

Aunque la lista de cambios a nivel funcional podría ser muy larga, aquí os dejo algunas de las cosas que más me ha llamado la atención:

  • Clientes/proveedores: desaparecen las transacciones clásicas de clientes (XD??,FD??,VD??) o proveedores (XK??,FK??,MK?). Todos los interlocutores se gestionan ahora de forma centralizada usando la transacción BP.
  • Gestión de mensajes: podemos decidir continuar con la clásica gestión de mensajes via NAST o usar la nueva funcionalidad mucho más completa basada en BRF+ (ver nota 2228611).
  • Gestión de almacén con ubicaciones: desaparece el módulo WM y ahora se integra en Hana el sistema EWM, que anteriormente se vendía como un producto separado. Toda una revolución. EWM incluye aplicaciones de radio frecuencia estándar, gestión de operaciones en el almacén, etc.
  • ATP: cambios importantes en la verificación de disponibilidad.
  • Material Ledger: uso obligatorio de este componente para la valoración de los materiales.
  • Determinación de fuente de aprovisionamiento en MM: cambia la lógica y se simplifica el uso del libro de pedidos (ver enlace).
  • MRP:  cambios importantes en el cálculo de la planificación de necesidades. Optimización del proceso con el MPR Live. Ver enlace: https://blogs.sap.com/2015/03/15/mrp-on-hana-whats-new/.

Para ayudarnos a ver la implicación de los cambios, transacciones que quedan obsoletas, nuevas funcionalidades, etc., Sap ha creado la “Simplifications list“, donde se detallan todas estas cosas, junto con acceso a las notas OSS relevantes en cada ámbito.

https://help.sap.com/doc/f45c88b65643403d97682484273216d0/1809.000/en-US/SIMPL_OP1809.pdf

Como veis, nos va a tocar volver a aprender lo aprendido, cambiar el chip en muchos temas y al fin y al cabo reciclarnos. Aunque sin olvidar que al fin y al cabo estamos en un producto de SAP y muchas cosas serán iguales o parecidas a las que ya conocíamos.

Sistema de Demo gratuito via Cloud.

Si tenéis interés en empezar a andar el camino, o por los menos investigar sobre lo que nos espera, Sap ofrece una versión trial de S4/HANA Cloud para que podamos empezar a conocer el producto y nos hagamos una idea de sus nuevas funcionalidades. Podéis acceder a ella en el enlace siguiente:

https://www.sap.com/products/s4hana-erp-cloud.html

Una vez registrados, tendremos acceso durante un mes a un sistema limitado de pruebas via Cloud (solo están disponibles algunos de los Tiles de la versión completa). El acceso se puede ir renovando para continuar durante más tiempo.

Como funcionalidad interesante de la trial, tenemos unos Guided Tours que nos muestran mediante un asistente alguna de la funcionalidad más importante.

Por ejemplo, el asistente para el proceso “Sales Accounting Overview”.

En otra de las secciones tenemos acceso a vídeos donde se habla de los diferentes módulos y cambios más importantes.

La versión trial va siendo mejorada continuamente y ampliándose las transacciones disponibles, con lo que es una buena opción para iniciarnos.

Enlaces de interés.

Para terminar, os dejo un recopilatorio de algunos enlaces de interés relacionados.

Algunos vídeos interesantes:

Algunos enlaces donde se explican algunas de las características más importes de S4:

Espero que os sea de utilidad.

Publicado en Formacion, S4/HANA | Etiquetado , , , | 2 comentarios

Truco 101. Problemas conocidos en las estrategias de liberación de Compras.


Recibo con frecuencia consultas sobre problemas relacionados con las estrategias de liberación en compras (módulo MM). Voy a intentar hacer un resumen de los problemas más habituales y la forma de solucionarlos. En primer lugar vamos a enumerar algunos de ellos:

  • ¿Se puede utilizar más de una clase para definir las estrategias de liberación a nivel de los pedidos?.
  • ¿Que pasa cuando tenemos más de una moneda en los procesos de compra y como afecta esto a las estrategias de liberación?.
  • ¿Los valores de clasificación en las estrategias de liberación se transportan entre sistemas dentro de las ordenes de transporte?.
  • ¿Que ocurre cuando borramos las estrategias de liberación, pero no borramos los valores de clasificación?.
  • ¿Tenemos alguna forma de chequear las inconsistencias dentro de las estrategias de liberación?.
  • ¿Que ocurre cuando definimos estrategias de liberación utilizando valores que están en las posiciones de los documentos y los valores difieren entre una posición y otro dentro del mismo documento?.
  • ¿Que ocurre cuando un documento ya esta liberado y se modifica?
  • ¿Se puede definir criterios en las estrategias de liberación Z o propios del usuario, fuera de los estándar?
  • ¿Porque un usuario puede liberar documentos a los que no tendría que tener acceso?.

Estos podrían ser alguno de los problemas más comunes (seguro que hay más), vamos a ver que hacer en cada caso.

1. Clase para las estrategias.

Cuando definimos las estrategias de liberación, en primer lugar creamos un grupo de liberación al que asignamos la clase donde hemos definido las características que utilizaremos en nuestras estrategias (ver la entrada del blog donde hablamos de la forma de configurar las estrategias).

Sap solo permite utilizar una clase. Si intentamos crear un grupo de liberación con otra clase, el sistema nos muestra este mensaje de error al grabar.

Por tanto, no es posible. Esto es importante, porque la clase que definamos para la liberación de documentos de compra (pedidos, contratos, ofertas), solpeds o hojas de entrada de servicio tendrá que tener todas las características necesarias para poder utilizarla en todos los escenarios posibles.

2. Varias monedas en los procesos de compra.

En las estrategias de liberación solemos utilizar el valor neto del pedido como criterio para realizar la definición de estas, requiriendo diferentes liberadores según los importes del documento. Este valor lo tenemos en el campo GNETW en la estructura de intercambio para las estrategias.

Cuando nosotros creamos un pedido, el sistema toma la moneda de la cabecera del documento y la convierte, utilizando el tipo de cambio, a la moneda de la sociedad donde estemos creando el pedido. Finalmente, Sap convierte este importe a la moneda de la característica en la estrategia de liberación (si fuera diferente). En el caso de trabajar con diferentes monedas, tendremos que tener esto en cuenta.

El estándar no soporta el trabajar con varias monedas. Cuando creamos la característica para el importe, le hemos de indicar una moneda (transacción CT04).

Ante esto, para el caso de estar en un sistema con sociedades diferentes que trabajan con varias monedas, tenemos varias alternativas disponibles:

  • Modificar el comportamiento estándar del sistema utilizando la exit EXIT_SAPLEBND_002 (ampliación M06E0004).
  • Elegir una moneda como referencia y crear las estrategias haciendo todas las conversiones de importes a esa moneda (por ejemplo, si trabajamos con EUR y USD, yo mis estrategias las defino en EUR). Cuando entre un pedido de la sociedad en USD, se convertirá el importe a EUR y se determinarán las estrategias según este importe. Esta suele ser la forma habitual de trabajar.
  • Crear dos características para los importes, uno para la moneda EUR y otro para la moneda USD. Tener en cuenta que en todas las estrategias habrá que informar los valores de las dos características.

En este, la condición de la característica del importe que no corresponde a la moneda de sociedad se tendrá que cumplir siempre. Con esta alternativa puede ser complicado configurar el sistema si tenemos más de 2 monedas.

Gracias a Arminda Jack por su explicación de las posibles alternativas en el SCN: https://wiki.scn.sap.com/wiki/display/ERPSCM/Multiple+Currencies+in+PO+Release+Strategy(incluyendo ventajas e inconvenientes de cada alternativa).

3. Transporte de la parametrización de las estrategias de liberación.

Cuando configuramos las estrategias de liberación, los valores de parametrización (tablas T16FK, T16FV, T16FS, T16FC and T16FG ) son incluidos en la orden de transporte. Pero no así los valores de clasificación que indicamos en nuestra estrategia. Igualmente, si hemos creado una clase nueva o las correspondientes características, estas tampoco serán transportadas.

Esta información tendremos que replicarla en cada sistema, una vez transportada la correspondiente orden de transporte (la clase y las características las crearemos antes del transporte). Es posible automatizar el traspaso de los valores de clasificación utilizando ALE. En una entrada anterior del blog hablamos de este problema y proporcionamos un documento con los elemento a configurar para poder realizar el trasporte de los valores de clasificación en las estrategias. Sobre todo recomendable en sistema donde tenemos gran complejidad en las estrategias de liberación con muchos registros de configuración.

4. Borrado o cambios en la clasificación de las estrategias de liberación.

Si borramos estrategias en la parametrización de SAP, hemos de asegurarnos que también se borra la información de clasificación. Es habitual que esto no se haga y tengamos comportamientos inesperados en la asignación de estrategias a los documentos.

Para ello, nos aseguraremos que hemos borrado la asignación de la clasificación a la estrategia usando la transaccion CL24N.

Otro chequeo interesante es utilizar la CL30N para hacer una simulación de la estrategia que sería asignada a un documento. Indicamos los criterios del documento utilizados en la clasificación, importe, etc y buscamos las estrategias que cumplen la condición. Solo debería de aparecer una.

Si hay mas de una, deberemos de revisar la configuración de nuestras estrategias, ya que es incorrecta.

5. Chequeo de inconsistencias en las estrategias de liberación.

Cuando hacemos cambios importantes en las estrategias de liberación, es posible que la parametrización se nos quede en un estado inconsistente. En dicho caso, es conveniente seguir las instrucciones de la nota 365604, paso 5.

Podremos usar el report RCCLZUOB para chequear la consistencia, con el tipo de clase 032 y tabla de objecto KSSK. También la transacción OMGSCK que nos hace un chequeo general de toda la configuración de las estrategias.

6. Estrategias de liberación utilizando valores de posiciones.

Cuando definimos las estrategias de liberación, hay que tener cuidado si utilizamos campos que se encuentren a nivel de posición. Por ejemplo, el centro receptor o el grupo de artículos.

Según se explica en la nota OSS 47089, Sap intenta agregar el importe de las posiciones que tenga el mismo centro o grupo de artículos (si hemos definido estos campos en las características de la estrategia). Si hay posiciones con diferentes valores, Sap agrega todos los valores llevando el valor de los campos en blanco a la estrategia.

Esto puede hacer que no se determine una estrategia de liberación y tengamos problemas con algunos documentos.

La alternativa que da Sap es definir también una estrategia con el valor del centro o del grupo de materiales en blanco (que será la que aplique cuando se produzca este caso).

Otra opción será realizar controles por exit o badi para evitar que un documento tenga valores divergentes de centro o grupo de artículo en las posiciones. Tambien podemos intentar solucionarlo con las exits de las estrategias de liberación.

7. Modificabilidad de los documentos ya liberados.

Cuando definimos las estrategias de liberación, podemos gestionar como se comportaran estas cuando se realicen modificaciones en los documentos una vez ya liberados. Esto se indica en los indicadores de liberación, que no son más que los estados de liberación. Normalmente habrá uno de los “estados” que indicará que el documento está liberado, y con el valor “Modific.” en la su parametrización podremos configurar el comportamiento deseado:

Los posibles valores son los siguientes:

1 – No modificable: no se podrá modificar el pedido una vez se haya
liberado (evitamos cualquier cambio después de su aprobación). Habría que
anular la liberación para poder cambiarlo.
2 – Modificable, sin nueva determinación de estrategia: se permite
modificar el pedido, y no se determina nunca una nueva liberación.
3 – Modificable, nvo.liberac.en caso nvo.estrat.: se permite modificar. Solo
será una nueva liberación si cambia la información del documento y esto
produce que se determine una nueva estrategia de liberación.
4 – Modificable, nvo.liberac si nueva estrat.o modif.val: se permite
modificar. Será necesaría una nueva liberación si se cumplen las condiciones
del valor 3 o el importe de modificación del pedido supera al porcentaje de
modificación.
5 – Modificable, nueva liber.si nueva estrat./sal.: idem del 3, pero también
afecta cuando el documento ya se ha impreso (en el caso 3 no afecta).
6 – Modificable, nvo.liberac.si nvo.etrat.sin modif.val./sal.: idem del 4,
pero también afecta cuando el documento ya se ha impreso (en el caso 4 no
afecta).

8. Criterios de selección propios en las estrategias de liberación.

Por suerte, Sap también nos deja la puerta abierta para definir nuestros propios criterios en la configuración de las estrategias de liberación.

En el truco 41 hablamos sobre ello y en la forma de hacerlo. Por un lado, tenemos que ampliar la correspondiente estructura de intercambio con una estructura append:

  • Solicitudes de pedido: estructura CEBAN.
  • Documentos de compras (pedido, oferta, contratos): estructura CEKKO.
  • Hojas de entrada de servicio: estructura CESSR.

Y a continuación utilizar la correspondiente ampliación (exit CMOD) para llenar los campos y que tengan valor cuando llegan al análisis de las estrategias.

  • Solicitudes de pedido: ampliación M06B0005, que llama al módulo de función EXIT_SAPLEBND_004.
  • Documentos de compra: ampliación M06E0004 , que llama al módulo de función EXIT_SAPLEBND_002.
  • Hoja de entrada de servicio: ampliación SRVREL, que llama al modulo de funcion EXIT_SAPLEBND_003.

9. Autorizaciones para las estrategias.

Si utilizamos estrategias de liberación en las solpeds sin clasificación, el objeto de autorización que se utiliza es el M_BANF_FRG.

En el resto de estrategias, cuando se utiliza clasificación (tanto en solpeds, documentos de compra o entrada de actividad en pedidos de servicios), el objeto de autorización utilizado es el M_EINK_FRG.

Cuando accedemos a las transacciones de liberación de solicitudes de pedido (ME29N) o de liberación de pedidos (ME54N), la persona autorizada puede visualizar y modificar el documento y efecturar su liberación con el código de liberación que le otorga la autorización. Se realiza en estos casos la verificación de autorización del objeto M_EINK_FRG.

Cuando se ha creado el pedido, el sistema ha revisado la parametrización del sistema y asignado una estrategia de liberación, incluida en un grupo de liberación.

Igualmente, en la estrategia se habrá asignado los códigos de liberación de los diferentes intervinientes en el proceso de liberación.

La combinación de esos dos valores será lo que necesite el usuario en sus roles de autorización, con el objeto M_EINK_FRG. En mi ejemplo, el usuario DIRECCION tendrá el valor Z1 en el campo FRGGR y Z3 en el campo FRGCO. Si el usuario no dispone de esos valores, no estará habilitado el botón para realizar la liberación.

Ejemplo de definición de Rol de autorizaciones con el objeto M_EINK_FRG

En las transacciones de liberación masiva (ME55 para solpeds o ME28 para pedidos), el usuario ha de indicar su código de liberación en los criterios de selección. Aquí se realizará igualmente la verificación de autorizaciones con el criterio indicado, y el usuario solo podrá ver los pedidos conforme a las autorizaciones asignadas.

10. Analizando nuestras estrategias.

Como hemos indicado, las estrategias utilizan el sistema de clasificación para definir las condiciones que se han de cumplir para que las estrategias apliquen. Tenemos varias transacciones interesantes para poder consultar los valores de la clasificación, como son las CL30N/CL31, CL20N, CL24N

Para mas información ver la entrada del blog donde hablábamos de esto. Y también de la posibilidad de realizar modificaciones masivas utilizando las transacciones CLMM o CL20N/CL24N(ver esta otra entrada del blog).

CLMM_5

Bibliografía:

Si tenéis aun más dudas o problemas relacionados con las estrategias, os recomiendo revisar las siguientes notas de sap:

Publicado en Formacion, SAP MM | Etiquetado , , , | 1 Comentario