MIRO en proceso batch: por qué la contabilización MM-FI se bloquea por el periodo abierto

Este problema tiene un patrón muy reconocible: la automatización de verificación de facturas (MIRO) funciona sin fallos durante semanas, y de repente, los primeros días de cada mes, empieza a rechazar documentos en bloque.

El síntoma

El job de contabilización automática de facturas devuelve un error del tipo “Periodo no permitido” o “No se ha abierto el periodo contable” (mensaje de la clase F5, típicamente F5 063 o similar, a veces M8 021 según el flujo). Lo curioso es que, si contabilizas el mismo documento a mano un rato después, funciona. El equipo de FI jura que el periodo está abierto.

La causa real

No es una única causa: son dos calendarios que no están sincronizados.

• El periodo contable se controla en OB52 (variante de periodo contable, tabla T001B), donde FI define qué periodos están abiertos para qué rangos de cuentas/sociedades.
• El documento que genera tu job de automatización usa como fecha de contabilización (BLDAT/BUDAT) la fecha en la que el job se ejecuta, no necesariamente la fecha en la que el pedido/factura se originó.

Cuando el job de MIRO se planifica para ejecutarse, por ejemplo, a las 00:30, y FI cierra el periodo anterior a primera hora del día siguiente (o incluso el mismo día a medianoche por un proceso de cierre automatizado), hay una ventana en la que:

1. El documento a contabilizar tiene una fecha de contabilización que tu programa calculó como “hoy”, pero “hoy” ya pertenece al periodo nuevo.
2. Ese periodo nuevo puede no estar abierto todavía para todos los tipos de cuenta (proveedores, por ejemplo, se abren más tarde que otros).
3. O al revés: el documento arrastra una fecha de periodo anterior (por un retraso en la cola, ver el problema de saturación de jobs) que ya se cerró.

El resultado es el mismo mensaje de error tanto si vas demasiado rápido como si vas demasiado lento respecto al calendario de cierre de FI.

Cómo confirmarlo

" Comprobar si el periodo de la fecha de contabilización propuesta
" está realmente abierto para la sociedad y tipo de cuenta antes de intentar MIRO
CALL FUNCTION 'FI_PERIOD_CHECK'
  EXPORTING
    i_bukrs = ls_factura-bukrs
    i_budat = ls_factura-budat
    i_koart = 'K'   " proveedores
  EXCEPTIONS
    error_period = 1
    OTHERS       = 2.

IF sy-subrc <> 0.
  " no insistas: registra el motivo real y decide fecha alternativa o reintento
ENDIF.

Comprobar esto antes de invocar BAPI_INCOMINGINVOICE_CREATE (la BAPI estándar detrás de MIRO) evita el error genérico y te da margen para decidir qué hacer, en lugar de descubrirlo por el mensaje de fallo.

La solución que funciona

1. No asumir “hoy” como fecha de contabilización por defecto. Calcularla explícitamente contra el calendario de periodos abiertos, con una regla clara para el caso límite (por ejemplo: si el periodo de hoy no está abierto para el tipo de cuenta necesario, usar el último periodo abierto, no forzar el actual).
2. Verificar el periodo con FI_PERIOD_CHECK (o equivalente) antes de contabilizar, no dejar que el error salga de la propia contabilización. Un rechazo controlado con un mensaje propio es mucho más fácil de monitorizar que un F5 063 perdido en el log del job.
3. Coordinar la ventana de ejecución del job con el calendario de cierre de FI, que normalmente ya existe como proceso conocido (cierre de periodo, apertura del siguiente). No tiene sentido programar la automatización justo en el borde de esa ventana.

La lección

Cuando un proceso cruza MM y FI, los errores más molestos no están en la lógica de ninguno de los dos módulos por separado: están en la frontera, en supuestos implícitos sobre fechas y calendarios que cada lado da por hechos de forma distinta. Haz explícito ese supuesto (el periodo abierto) en lugar de dejar que lo descubra el mensaje de error.