Cómo probar que una conciliación detecta registros ausentes

Una comprobación de integración cuenta tres registros en cada sistema y da la transferencia por completa. Sin embargo, el origen contiene R101, R102 y R103, mientras el destino contiene R101 dos veces y R103 una. Los totales coinciden; falta R102.

Este ejemplo ficticio sirve como prueba de aceptación de una conciliación. En lugar de esperar a que un cliente descubra una omisión, introduce pequeños defectos deliberados en un entorno de pruebas y comprueba los hallazgos. El ejercicio siguiente supone que cada registro de origen debe producir un registro de destino.

Definir el contrato de comparación

Elige una organización, un tipo de registro y una ventana acotada del origen. Especifica qué fecha selecciona los registros, su zona horaria y si incluye el inicio y excluye el final. Anota los estados excluidos. Relaciona los registros mediante ID estables del origen y su referencia guardada en el destino; comparar solo nombres puede confundir solicitudes diferentes.

Mantén fijo el primer conjunto de prueba durante la comparación. En una comprobación real, registra los momentos de extracción y las versiones o referencias de instantáneas disponibles. Si los registros cambian durante la lectura y no puedes establecer observaciones comparables, clasifica la ejecución como inconclusa. Un filtro de fechas no congela los sistemas.

Confirma que ambas extracciones incluyen todas las páginas necesarias y que la cuenta lectora tiene el alcance organizativo previsto. Una lectura fallida no debe convertirse en una lista vacía: un problema de acceso podría parecer un borrado masivo o un resultado correcto.

Comparar identidad y significado

La documentación de AWS DMS ilustra la validación por filas: el servicio compara cada fila del origen con su correspondiente en el destino y comunica diferencias. También distingue validaciones pendientes y suspendidas. Es una función concreta de migración, no evidencia de que cualquier integración empresarial ya haga esas comprobaciones.

Para este flujo propuesto de uno a uno, informa de ID ausentes en el destino, referencias repetidas, referencias inesperadas y diferencias en los campos seleccionados. Define cómo comparar valores transformados. Por ejemplo, dos etiquetas de estado distintas pueden representar legítimamente el mismo estado empresarial acordado.

Introducir defectos deliberados

Empieza con los registros ficticios R101, R102 y R103 y un destino equivalente. Restaura esa base antes de cada variación para que el resultado esperado no sea ambiguo.

1. Base correcta: cada ID aparece una vez en el destino con los campos previstos. El informe no encuentra diferencias en este conjunto.
2. Totales iguales con una omisión: retira R102 y añade otro registro de destino que referencie R101. El informe debe identificar tanto el ID ausente como la referencia duplicada.
3. Campo incorrecto: conserva los tres ID, pero asigna a R103 un estado transformado incorrecto. La coincidencia de identidad no debe ocultar la diferencia del campo.
4. Registro inesperado: añade R999 sin un equivalente elegible en el origen de prueba. El informe debe señalarlo para investigar, no eliminarlo.
5. Observación incompleta: provoca un fallo de lectura de prueba o detenla antes de la última página. La ejecución debe mostrar evidencia incompleta, no una comparación exitosa.

Distinguir un retraso de una diferencia pendiente

Ensaya otra variación retrasando R102 deliberadamente. Acuerda el plazo esperado de entrega con el responsable de la integración y comprueba una vez dentro de ese margen y otra después. Registra los momentos reales de observación. Dentro del margen, márcalo como pendiente; después, como diferencia vencida que requiere investigación. Ninguna etiqueta demuestra por sí sola una pérdida permanente.

Stripe documenta reintentos automáticos y advierte que no garantiza el orden de entrega de eventos. Verifica aparte el comportamiento de tu proveedor. La ausencia de errores registrados no demuestra que cada registro empresarial esperado haya llegado al destino.

Demostrar la detección antes de reparar

Guarda para cada variación la versión del conjunto, el alcance, los hallazgos esperados, los observados y quién los revisó. Después de que el desarrollador corrija los datos mediante el flujo de pruebas aprobado, repite el mismo alcance y confirma que desaparece la diferencia correspondiente sin ocultar otra.

Mantén la conciliación productiva en modo de lectura hasta definir por separado quién puede reparar, con qué autorización y cómo evitar duplicados. El informe debe conducir a evidencia, no sobrescribir silenciosamente trabajo manual. Asigna responsable y próxima revisión a los elementos pendientes.

Revisa con Dynelink una prueba de conciliación de tu integración: trae una relación entre registros y ejemplos de omisiones, repeticiones o retrasos que necesites detectar.

Ilustración conceptual generada con IA; no es una captura de un cliente.