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.

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

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

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

Exit disponibles.

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

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

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

Badis disponibles.

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

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

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

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

Ejemplo práctico.

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

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

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

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

method IF_EX_MRM_HEADER_CHECK~HEADERDATA_CHECK.

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

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

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

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

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

Bibliografía.

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

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

Nota 1156325 – BAdIs in the Logistics Invoice Verification environment MIRO

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