Minería del cobre

Documentos tributarios rechazados en masa: encontrar la causa en horas, no en semanas

Un rechazo masivo de documentos tributarios electrónicos no siempre viene de un cambio propio. Cuando el diagnóstico empieza por el mensaje y no por el sistema, la causa aparece rápido.

Horas no semanas: causa raíz identificada Payload real diagnóstico por mensaje, no por configuración Totalidad documentos reprocesados y aceptados

Cliente

Faena minera con facturación de alto volumen hacia proveedores y clientes, integrada desde S/4HANA SD hacia el servicio de facturación electrónica a través de SAP CPI.

Situación inicial

De un día para otro empezaron a rechazarse documentos tributarios electrónicos. El área comercial reportó un volumen creciente de documentos rechazados antes de que el equipo técnico se enterara. No había habido despliegue ni cambio en la interfaz. La hipótesis inicial del equipo interno apuntaba al iFlow, y ya se estaba preparando un rollback de un cambio que no era el culpable.

Restricciones

  • Facturación detenida: cada hora sin emitir tiene impacto directo en cobranza.
  • Sin acceso inmediato a los logs del proveedor del servicio de facturación.
  • Presión para revertir un despliegue que, de hecho, no tenía relación con el problema.
  • El volumen impedía revisar documentos uno a uno.

Decisión de arquitectura

Antes de revertir nada, se comparó el mensaje efectivamente enviado en un caso rechazado contra uno aceptado de la semana anterior. Ese paso —mirar el payload real, no la configuración— acotó el problema en menos de una hora: la diferencia no estaba en el iFlow sino en un dato de origen, un campo que había empezado a llegar desde S/4HANA con un formato que el esquema de destino toleraba antes y ya no.

La decisión de no revertir fue tan importante como el diagnóstico. Un rollback habría consumido horas, habría reintroducido un comportamiento anterior sin corregir la causa, y habría dejado al equipo convencido de que el problema estaba resuelto.

La corrección se aplicó en el mapeo, con validación explícita del campo y un mensaje de error legible, en vez de dejar que el rechazo llegara desde el receptor.

Ejecución

Se identificaron los documentos afectados por patrón en lugar de uno a uno, se corrigió el mapeo con validación en origen y se reprocesaron los rechazados en lotes controlados, verificando aceptación antes de liberar el siguiente. Se agregó una alerta sobre la tasa de rechazo para que una desviación futura se detecte en minutos y no cuando la reporta el área comercial.

Resultado

Causa raíz identificada en horas, no en semanas, y facturación normalizada poco después, con la totalidad de los documentos reprocesados y aceptados. Quedó operativa la alerta por tasa de rechazo, que no existía antes.

Lo que dejó

Cuando algo falla sin que nadie haya cambiado nada, alguien cambió algo. Empezar por el mensaje real y no por la configuración es lo que separa un diagnóstico de horas de uno de semanas.

Stack

SAP CPI S/4HANA SD Facturación electrónica Groovy OAuth 2.0
¿Tiene un caso parecido? Conversemos Ver los otros casos