Una integración puede responder correctamente y, aun así, dejar datos distintos en dos sistemas. Una petición puede agotarse después de que el sistema externo haya guardado el cambio; un evento puede llegar tarde; o una actualización local puede modificar un campo que el otro sistema también controla. Por eso, además de sincronizar eventos, conviene poder comparar estados y resolver discrepancias de forma deliberada.
La conciliación de datos entre sistemas en PHP es un proceso periódico o bajo demanda que identifica diferencias entre registros relacionados, determina qué significan y propone o aplica una acción. No consiste en copiar indiscriminadamente un sistema sobre otro. Para evitar perder información válida, hay que definir la autoridad de cada dato, conservar evidencia de la comparación y proteger la aplicación de correcciones repetidas o masivas.
Definir qué sistema tiene autoridad antes de comparar
La fuente de verdad no siempre es única para toda una entidad. El CRM puede ser responsable del nombre comercial y los datos de contacto, mientras que el sistema de facturación controla el estado de pago y el identificador fiscal validado. Si se designa un sistema completo como autoridad sin revisar los campos, la conciliación puede reemplazar información correcta con una copia antigua o incompleta.
Documenta la propiedad de los campos que se intercambian. Para cada uno, registra qué sistema puede originar cambios, cuál debe prevalecer ante un conflicto, si el valor puede ser nulo y qué transformaciones son aceptables. También conviene distinguir entre campos editables y derivados: un total calculado, por ejemplo, puede tener que regenerarse a partir de sus componentes en vez de copiarse.
- Autoridad por campo: define quién decide su valor y qué hacer si ambos sistemas presentan cambios.
- Reglas de combinación: especifica si se puede completar un dato ausente sin reemplazar uno existente.
- Excepciones: señala qué conflictos necesitan aprobación, validación adicional o intervención del equipo responsable.
Cuando no hay una regla segura, la acción correcta es marcar el conflicto para revisión, no elegir arbitrariamente el registro con la fecha más reciente. Los relojes pueden diferir y una marca temporal no demuestra, por sí sola, que un cambio sea legítimo.
Hacer la comparación reproducible
Una comparación útil necesita identificar el mismo registro en ambos lados. Usa un identificador estable compartido o una tabla de correspondencias mantenida explícitamente. No dependas únicamente de nombres, correos u otros campos que puedan cambiar, repetirse o normalizarse de forma distinta. Si no se encuentra una relación inequívoca, clasifica el caso como pendiente de vinculación en lugar de fusionar registros por aproximación.
Compara valores normalizados según reglas documentadas: por ejemplo, espacios, mayúsculas o formatos de fecha. Conserva también el valor original, porque normalizar para comparar no autoriza a cambiar el dato persistido. Ten cuidado con zonas horarias, precisión decimal, valores vacíos y diferencias entre un campo ausente y uno presente con valor nulo. Tratar estos estados como equivalentes puede ocultar cambios relevantes.
En conjuntos grandes, define una ventana de trabajo y una marca de agua, como una fecha de modificación o un cursor de paginación. Guarda el punto de avance sólo cuando el lote se haya procesado de forma consistente. Si el proveedor no ofrece marcas fiables, una exploración completa menos frecuente o una combinación de muestreo y reconciliación dirigida puede ser más segura que fingir una incrementalidad que la API no garantiza. La estrategia depende de los límites, la estabilidad y las garantías reales de cada sistema.
En PHP, separa la obtención de datos de la comparación y de la persistencia de resultados. Por ejemplo, una función de comparación puede recibir dos representaciones normalizadas y devolver una lista de diferencias tipadas, sin ejecutar llamadas remotas ni actualizar registros. Esta separación permite probar reglas con casos controlados y revisar propuestas antes de habilitar escrituras.
Clasificar discrepancias y decidir la respuesta
No todas las diferencias indican un error, y cada clase requiere una política distinta. Una clasificación explícita mejora el diagnóstico y evita que una única regla destructiva se aplique a situaciones diferentes.
- Faltante: el registro existe en un sistema, pero no en el otro. Comprueba si se trata de una creación reciente, una eliminación legítima, un filtro o un fallo de paginación.
- Duplicado: varios registros parecen corresponder a una entidad. No elijas uno automáticamente sin una regla de identidad verificable.
- Cambio incompatible: ambos lados han cambiado un campo controlado por ambos. Aplica una política de propiedad o envía el conflicto a revisión.
- Dato inválido: el valor no cumple el formato o las restricciones esperadas. Ponlo en cuarentena y evita propagarlo.
- Desfase temporal: la diferencia puede deberse a retraso de entrega o procesamiento. Reintenta o espera una ventana definida antes de declarar un conflicto persistente.
Separa tres etapas: detección de la diferencia, decisión sobre la acción y aplicación del cambio. Una propuesta puede consistir en actualizar un campo, crear una asociación, solicitar revisión o no hacer nada. Mantener estas etapas separadas permite empezar en modo de solo lectura y entender qué habría cambiado antes de activar correcciones automáticas.
Aplicar cambios sin crear daños nuevos
Automatiza únicamente los casos cubiertos por reglas claras y verificables. Para los demás, ofrece una cola de revisión con el identificador de la entidad, los valores observados, la regla que se activaría y la acción propuesta. La interfaz o el proceso operativo deben permitir aceptar, rechazar o escalar la propuesta, y dejar constancia de quién tomó la decisión cuando corresponda.
Diseña las operaciones para que sean idempotentes: volver a procesar la misma discrepancia no debe crear duplicados ni alternar valores indefinidamente. Antes de escribir, comprueba que el registro sigue en el estado esperado. Si cambió desde la lectura, detén la actualización y vuelve a comparar. Cuando la API externa lo permita, utiliza versiones, condiciones de escritura o claves de idempotencia; no supongas que existen sin verificarlo.
Limita el alcance con lotes pequeños, límites de cambios por ejecución y opciones de pausa. Una corrección que supera el volumen previsto debe detenerse o requerir autorización, no continuar silenciosamente. Para cambios de alto impacto, registra una operación compensatoria posible, pero no la presentes como garantía de reversión: puede haber cambios posteriores o efectos externos que no se puedan deshacer.
Registrar cada ejecución para investigar y repetir
Guarda un identificador de ejecución, su inicio y fin, el rango o cursor procesado, los sistemas consultados, el resultado por categoría y los errores. Para cada discrepancia, conserva la clave de correlación, los valores relevantes o una representación protegida, la regla evaluada, la acción propuesta y el resultado de la aplicación. Así se puede explicar por qué se tomó una decisión y distinguir un fallo de integración de un conflicto real.
Protege los registros: pueden contener datos personales, credenciales indirectas o información comercial. Evita volcar cargas completas cuando basten campos concretos, limita el acceso y define retención. Incluye referencias a los registros de origen y hora de observación para facilitar investigaciones sin convertir el log en una segunda base de datos sin control.
Reintenta sólo los fallos transitorios, con límites y espera progresiva. Registra los reintentos y separa los errores permanentes —como datos inválidos o permisos insuficientes— para evitar ciclos que repitan el mismo problema. Una ejecución debe poder reanudarse con un criterio conocido, no depender de que el proceso PHP permanezca activo indefinidamente.
Lista de comprobación antes de automatizar
- ¿Está definida la autoridad para cada campo y el tratamiento de nulos y eliminaciones?
- ¿Los identificadores enlazan registros sin ambigüedad y se gestionan los duplicados?
- ¿Se han probado paginación, retrasos, límites de API, reintentos y cambios concurrentes?
- ¿Las diferencias están clasificadas y las excepciones se envían a revisión o cuarentena?
- ¿La comparación puede ejecutarse en modo de solo lectura y mostrar las acciones que propone?
- ¿Las escrituras son idempotentes, condicionadas al estado esperado y acotadas por volumen?
- ¿Se registran decisiones y resultados con protección de datos y acceso apropiados?
- ¿Hay pruebas con datos representativos, incluidos conflictos, valores vacíos, duplicados y fallos parciales?
Empieza observando y clasificando, no corrigiendo. Tras validar las reglas con datos reales y revisar las propuestas, activa la automatización sólo para discrepancias de bajo riesgo. Mantén una vía de pausa y revisa periódicamente falsos positivos, casos sin resolver y cambios en los sistemas externos. Así la conciliación se convierte en un control operativo repetible, en vez de una sincronización que oculta conflictos hasta que alguien detecta sus consecuencias.
