La IA, en tu trabajo.

Qué cambia

Microsoft integró el 27 de octubre la solicitud #13272 en la rama principal de BCApps. Describe un problema al desliquidar pagos con fecha anterior: las diferencias de cambio no realizadas podían desplazarse entre periodos aunque el saldo global siguiera cuadrando. Solicitud original.

El cambio reconstruye las revaluaciones posteriores con sus fechas y factores registrados. El alcance declarado comprende clientes, proveedores y empleados en W1 y RU. El diff consultado contiene lógica de ajuste y pruebas de regresión; Nexo no las ha ejecutado. Commit registrado.

Por qué importa en el cierre

Business Central permite revisar los movimientos previstos antes de registrar un ajuste de cambio. Microsoft también explica que desliquidar y revertir un pago previamente ajustado genera movimientos de reversión y puede exigir otro ajuste para obtener el saldo actual correcto. Documentación de divisas.

Interpretación de Nexo: una conciliación acumulada puede ocultar una distribución temporal incorrecta. El criterio de aceptación debería comprobar qué saldo queda en cada fecha de corte y qué movimientos explican las diferencias, manteniendo la misma configuración y los mismos filtros durante la comparación.

Disponibilidad y reservas

Las adaptaciones a releases/29.x y releases/29.0 se integraron el 5 de noviembre. Sus hitos son Version 29.1 y Version 29.0, respectivamente. Estas referencias identifican destinos de código; las páginas consultadas no acreditan una compilación distribuida o su instalación en un cliente. Adaptación 29.x, adaptación 29.0.

Una revisión automatizada publicada en ambas solicitudes señala un posible caso límite: un ajuste redondeado a cero podría actualizar el factor sin generar el detalle necesario para reconstruirlo. Es una observación de revisión sin ejecución de pruebas, no un resultado reproducido por Nexo. La integración posterior no basta para dar esa reserva por resuelta. Revisión en 29.0.

Tampoco queda establecido cómo se comporta cada instalación ante fechas de registro bloqueadas. Antes de trasladar una conclusión a producción, el equipo responsable debe identificar la compilación, localización, extensiones y restricciones de fechas del entorno evaluado.

Ejemplo ficticio: el total no cuenta toda la historia

Supongamos que una empresa de prueba espera conservar los siguientes saldos históricos tras completar una aplicación y su desliquidación. Las cifras son sintéticas, en moneda local; ilustran una comparación y no reproducen el fallo ni constituyen resultados de Business Central.

Cómo convertirlo en una prueba funcional

En el ejemplo, julio coincide y junio presenta una desviación de 100. Son saldos a fechas distintas: no deben sumarse. La coincidencia final no explica ni valida el cambio de junio.

Propuesta de Nexo para una empresa de pruebas:

• Guardar los saldos históricos de referencia y los movimientos que los sustentan antes del ciclo de aplicación y desliquidación.
• Comparar cada fecha de corte, con idénticos filtros, y justificar cualquier diferencia mediante movimientos concretos.
• Incluir pagos parciales, varios ajustes posteriores, repetición del ciclo y ajustes cuyo importe redondee a cero.
• Comprobar separadamente las restricciones de fechas de registro, sin asumir que la corrección permite operar sobre periodos bloqueados.
• Registrar compilación, localización y extensiones junto con el resultado observado; no extrapolar una prueba satisfactoria a otros entornos.