Datos distintos en el portal de clientes y el ERP: cómo encontrar la causa

Un cliente entra en el portal y ve una factura como pendiente, pero el equipo administrativo la encuentra pagada en el ERP. Antes de corregir la pantalla o volver a ejecutar una integración, hay que saber qué representa cada estado, cuándo cambió y de dónde procede. Un ajuste apresurado puede mostrar información incorrecta a más clientes o sobrescribir una corrección válida.

La desincronización entre portal de clientes y ERP no siempre significa que la integración esté rota. Puede haber un retraso previsto, un dato calculado de forma diferente o una modificación manual que solo existe en un sistema. El objetivo del diagnóstico es reconstruir el recorrido del dato y elegir una corrección proporcionada, no hacer que ambas pantallas coincidan a cualquier precio.

Del síntoma a una pregunta verificable

Empieza por concretar la discrepancia. «Los datos no cuadran» es demasiado amplio; «el portal muestra pendiente para esta factura mientras el ERP registra un pago aplicado» permite investigar. Anota el identificador del registro, los valores visibles, las horas de consulta y el usuario o rol con el que se observó cada pantalla. Si hay varios casos, agrúpalos por campo, cliente y tipo de operación: un problema que afecta solo a facturas recientes apunta a causas distintas de otro que aparece tras editar datos históricos.

Comprueba también si las dos vistas deberían coincidir. Un ERP puede mostrar el estado contable de una factura y el portal un estado simplificado para el cliente. Si las definiciones difieren, no basta con copiar un campo: hay que acordar qué significado tendrá en cada interfaz y cómo se explicarán las transiciones, por ejemplo, entre «pago recibido» y «pago aplicado».

Evita modificar registros mientras reúnes evidencias, salvo que exista una necesidad operativa urgente y se documente la intervención. Capturas con marcas de tiempo, identificadores internos y registros de eventos suelen ser más útiles que una descripción basada en la memoria. Para investigar, utiliza solo los datos personales imprescindibles y limita el acceso a quienes participan en la revisión.

Sigue el recorrido de cada dato

La primera pregunta es quién es responsable del campo. El ERP puede ser la fuente de verdad para el estado de una factura, mientras que un contacto de proyecto se mantiene en el portal y se envía después al ERP. Documenta esa dirección campo por campo: origen, destino, transformación, responsable de cambios y comportamiento esperado si ambos sistemas reciben una edición.

Después, reconstruye una línea temporal de algunos registros afectados. ¿Cuándo se guardó el cambio en el origen? ¿Cuándo se emitió o recogió el evento? ¿Cuándo lo procesó la integración? ¿Cuándo actualizó el destino su base de datos o su caché? Distinguir estas horas ayuda a separar un retraso normal de un procesamiento detenido. Revisa la frecuencia prevista: una actualización periódica no ofrece la misma experiencia que un cambio visible casi inmediatamente, y el portal debería comunicarlo cuando importe al usuario.

Busca el mismo registro a lo largo del trayecto usando identificadores estables. Si el portal y el ERP asignan claves diferentes, verifica la tabla o regla que las relaciona. Un identificador ausente puede impedir una actualización; uno mal asociado puede aplicar el cambio a otro registro. No des por hecho que una coincidencia por nombre de cliente o número mostrado sea suficiente, especialmente si esos valores pueden repetirse o cambiar.

Distingue fallos técnicos de cambios legítimos

Los registros de integración permiten comprobar si el evento llegó, falló, quedó pendiente o se procesó más de una vez. Revisa errores de validación, permisos, límites de la interfaz de integración y reintentos, pero también los casos en los que la operación figura como correcta aunque un campo se haya omitido. Un éxito técnico no garantiza que el resultado de negocio sea el esperado.

Investiga las transformaciones. Fechas interpretadas en zonas horarias distintas, reglas de redondeo, campos opcionales vacíos o catálogos de estados que no coinciden pueden crear diferencias sin que falle ninguna petición. Comprueba asimismo si el portal muestra una caché antigua o datos condicionados por permisos: dos usuarios podrían ver información diferente sin que el ERP haya cambiado.

Por último, revisa las intervenciones manuales. Un administrador puede haber corregido un dato en el ERP después de la última exportación, o un responsable de cuenta puede haber editado el portal para resolver una incidencia urgente. Esos cambios pueden ser válidos. Antes de sustituirlos, determina quién los hizo, por qué y qué sistema debía conservarlos. Si no existe una regla de resolución de conflictos, la discrepancia revela una decisión de producto pendiente, no solo un defecto de código.

Corrige la causa y comprueba el resultado

La solución depende de lo encontrado. Si hay un retraso esperado, puede bastar con mostrar la hora de actualización y definir cuándo refrescar la vista. Si hay eventos fallidos, conviene corregir el error y reprocesarlos con controles para evitar duplicados. Si el problema es de correspondencia entre registros o de transformación, primero se repara la regla; después se identifican los datos afectados antes de ejecutar una corrección supervisada. Una resincronización completa, sin ese análisis, puede multiplicar las inconsistencias.

Para cambios manuales recurrentes, aclara la propiedad de cada campo y diseña una forma de registrar excepciones sin que la siguiente sincronización las borre silenciosamente. Añade una comprobación periódica de registros relevantes y una vía clara para investigar diferencias. Las alertas son útiles cuando indican qué falló y quién debe actuar, no cuando generan avisos indistintos que nadie puede resolver.

Antes de desplegar, prueba altas, ediciones, reintentos, cambios simultáneos y registros antiguos en un entorno controlado. Acuerda qué dato debe verse en el portal durante un retraso y cómo se recuperará el sistema si una actualización vuelve a fallar. Después del despliegue, revisa una muestra de casos reales y confirma tanto el valor como su significado para el usuario.

Si tienes una discrepancia concreta entre portal y ERP, Cibercoding puede ayudarte a trazar el recorrido del dato y delimitar una corrección segura.