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/

Esta entrada fue publicada en Formacion, SAP MM y etiquetada , , , , . Guarda el enlace permanente.

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

  1. Angeles dijo:

    Excelente¡! super detallado y muy clara la explicacion. Gracias por compartir.
    Saludos.
    Angeles

  2. Agusto dijo:

    Hola Roberto,

    Excelente ayuda la que ofreces a trabajes de tu página.

    Quería hacerte una pregunta?

    Cuando estas configurando, siempre haces una copia de lo que te ofrece el estándar o haces uso del estándar? Por ejemplo cuando creas tipos de materiales, clases de documentos, entre otros, que acostumbras?

    Un abrazo,

    • Hola Augusto:

      Es una buena practica hacer copia del estandar. Por ejemplo, un tipo de material para mercaderia. El estandar es HAWA, pues creo uno como copia de este llamado ZHAW. Asi te aseguras una correcta configuracion y luego modificas lo que tu estimas.

      Saludos

  3. Marko dijo:

    Hola Roberto buenas tardes,
    agradezco la gran ayuda que nos brindas a varios de nosotr@

    Me puedes orientar por favor como puedo hacer que el campo de cabera Texto sea obligatorio en la solicitud de pedido en la transacción ME51N, y ME52N??

    Saludos!

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios .