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


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

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

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

Veamos en detalle las tres opciones.

Grupos de autorizaciones.

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

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

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

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

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

Clases de autorizaciones.

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

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

 

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

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

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

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

Grupos de campos relevantes para autorizaciones.

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

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

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

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

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

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

 

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

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

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

Funciones similares si aun seguimos en R3.

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

Bibliografia.

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

Sap Business Partner Security – Ayuda de Sap.

Publicado en Formacion, S/4HANA, Sap FI, SAP MM, Sap SD | Etiquetado , , , | 5 comentarios

Truco 114. Nuevas herramientas de búsqueda en S/4HANA.


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

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

Trucos 113. Comparar tablas o parametrización entre mandantes o sistemas.


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.

Truco113_img1

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.

Truco113_img2

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.

Truco113_img3

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.

Truco113_img4

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.

Truco113_img5

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:

Truco113_img6

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:

Truco113_img7

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

Truco113_img8

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

Truco113_img9

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

Truco113_img10

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

Truco113_img11

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/

Publicado en Formacion, Sap Basis | Etiquetado , , , | 1 Comentario

Empezando con S/4HANA. Business Partner (BP).


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

image-1

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.

BP_013

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

BP_004

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

BP_001

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

BP_002

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

BP_007

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.

BP_008

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

BP_009

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.

BP_012

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.

BP_005

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.

BP_006

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

BP_010

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

BP_011

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/

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

Truco 112. Personalización del registro de factura de compras (MIRO)


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.

Truco112_img1

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

Truco112_img2

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

Truco112_img3

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

Truco112_img5

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

Truco112_img6

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 rbkpXBLNR.
  DATAlv_duplic(1),
       lv_text(30).

  clear lv_duplic.
  IF sytcode ‘MIRO’.
    IF i_rbkpvxblnr NE space and i_rbkpvlifnr is not initial.
      lv_document_nr i_rbkpvxblnr.

* 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_rbkpvgjahr
                      AND    XBLNR  lv_document_nr
                      AND    BUDAT  <> i_rbkpvbudat
                      AND    LIFNR  i_rbkpvlifnr.
        IF sysubrc 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_rbkpvgjahr
                      AND    XBLNR  lv_document_nr
                      AND    LIFNR  i_rbkpvlifnr.
           IF sysubrc eq 0.
              lv_duplic ‘X’.
              lv_text ‘Existe en otro año’.
           ENDIF.
        endif.
        if lv_duplic ‘X’.
           message W000(zsistemaswith lv_text
                                     wa_rbkpBELNR
                                     wa_rbkpGJAHR.
        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:

Truco112_img4

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/

Publicado en Formacion, SAP MM | Etiquetado , , , , | 8 comentarios

Truco 111. Bloqueo de entrega / factura en pedidos. Desactivar la modificación del bloqueo mediante autorizaciones.


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.

Truco111_img1

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

Truco111_img16

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

Truco111_img2

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.

Truco111_img4

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:

Truco111_img5

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). También podremos utilizar la transacción VDBLOCK.

Truco111_img6

  • 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. También podremos utilizar la transacción VBBLOCK, que es muy similar.
  • V.23: similar a la anterior, pero nos permite eliminar los bloqueos de facturación de forma masiva, sin tener que entrar documento por 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.

Truco111_img3

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

Truco111_img10

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

Truco111_img7

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.

Truco111_img8

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

Truco111_img9

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.

Truco111_img11

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:

Truco111_img12

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!».

Truco111_img13

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.

Truco111_img15

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

Truco111_img14

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.

lib_pvta1

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.

lib_pvta9

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

lib_pvta6

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/

Publicado en Autorizaciones, Formacion, Sap SD | Etiquetado , , , , , | 4 comentarios

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.

Haz clic para acceder a 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 | 6 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 , , , | 4 comentarios