Por qué CALL TRANSACTION falla en modo de proceso automático para ciertas transacciones

Este es de los que te hacen dudar de tu propio código: la automatización con CALL TRANSACTION funciona perfecto cuando la pruebas en dialogo, funciona perfecto para la mayoría de transacciones en background… y falla, silenciosa o ruidosamente, para una transacción concreta.

El síntoma

El job termina “bien” (no hay dump), pero el documento no se crea, o se crea a medias, o la BDCMSGCOLL devuelve mensajes que no tienen sentido con lo que ves si ejecutas la transacción a mano. A veces el efecto es peor: el CALL TRANSACTION sencillamente cuelga el job hasta timeout.

La causa real

CALL TRANSACTION simula la interacción de un usuario navegando pantallas: rellena campos de dynpro y “pulsa” el botón que le digas (ENTER, BACK, etc.), según el mapping BDC que le pases. Esto asume que la transacción se comporta igual delante de un usuario que delante de un batch input. No siempre es así.

Muchas transacciones —sobre todo las que tienen lógica custom en user-exits, BAdIs, o simplemente código antiguo— comprueban explícitamente el modo de ejecución:

IF sy-batch = abap_true.
  " comportamiento distinto: se salta una validación,
  " no dispara un POPUP, cambia el flujo de pantallas...
ENDIF.

IF sy-binpt = abap_true.
  " sy-binpt indica "estamos en batch input",
  " y aquí es fácil encontrar código que asume
  " que ciertos campos ya vienen rellenados
  " de una pantalla anterior que en tu mapping no existe
ENDIF.

Cuando la transacción tiene un CALL SCREEN condicional (por ejemplo, un popup de confirmación que en modo diálogo se muestra pero en batch input se salta o se auto-confirma con un valor por defecto que no es el que tú esperabas), tu mapping de campos deja de encajar con la secuencia real de pantallas. El resultado es justo la clase de fallo silencioso descrita arriba.

Cómo confirmarlo

Antes de perder horas ajustando el mapping BDC a ciegas:

1. Ejecuta la transacción a mano en modo “Mostrar todas las pantallas” desde SHDB grabando la misma secuencia que intentas automatizar, y compara el número y orden de pantallas contra tu mapping.
2. Revisa si la transacción llama a algún BAdI/user-exit conocido que consulte sy-batch o sy-binpt — un SE24/SE18 con “dónde se usa” sobre esas variables del sistema en los includes de la transacción suele delatarlo rápido.
3. Comprueba el modo de CALL TRANSACTION que estás usando: 'A' (todas las pantallas, para depurar), 'E' (solo errores) o 'N' (sin pantallas, el que usarías en background real). El comportamiento puede variar entre estos tres.

La solución que funciona

Cuando confirmas que la transacción tiene lógica dependiente del modo de ejecución, seguir insistiendo con BDC es pelear contra el estándar. Las alternativas que sí funcionan, de mejor a peor:

1. Usar la BAPI o función estándar equivalente, si existe, en lugar de simular pantallas. La mayoría de transacciones de creación de documentos (pedidos, facturas, materiales) tienen una BAPI detrás que no depende de dynpros ni de sy-batch.
2. Si no hay BAPI, aislar el problema con un mapping BDC específico para modo batch (a veces la solución es tan simple como añadir un valor de campo distinto solo para ese escenario, no reescribir toda la lógica).
3. Como último recurso, y solo si nada de lo anterior es viable, CALL TRANSACTION en modo 'A' con manejo de excepción para el popup concreto — más frágil, pero explícito sobre qué estás forzando.

La lección

CALL TRANSACTION no es “grabar y reproducir”: es simular una interacción con una pantalla que puede comportarse de forma distinta según el contexto de ejecución. Cuando algo falla solo en background, la primera sospecha no debería ser tu mapping — debería ser cómo la transacción trata sy-batch y sy-binpt.