💳 D365 Finance 10.0.49 desacopla la liquidación de los diarios de pago
💳 D365 Finance 10.0.49 desacopla la liquidación de los diarios de pago
En Dynamics 365 Finance, contabilizar un diario de pagos y liquidar las transacciones marcadas han formado tradicionalmente una única operación. Es cómodo cuando todo funciona, pero crea un acoplamiento peligroso: un bloqueo, una inconsistencia o un error de validación durante la liquidación puede impedir que se contabilice un pago que sí es válido.
La versión 10.0.49 incorpora en preview la característica Decouple settlement from journal posting. Al activarla, Finance contabiliza el pago, conserva la relación de liquidación en una cola y procesa esa liquidación por separado. El cambio no altera las reglas de matching; cambia el momento y el aislamiento transaccional con el que se ejecutan.
Estado a 27 de agosto de 2026: requiere Dynamics 365 Finance 10.0.49 y activación explícita en Feature management. La 10.0.49 está disponible como preview para desarrollo y pruebas; su disponibilidad general para self-update está prevista para el 11 de septiembre de 2026. Microsoft indica que una preview no puede utilizarse en producción.
Qué problema resuelve
En el flujo estándar, el posting del diario y la liquidación se ejecutan juntos:
Diario de pagos
│
▼
Contabilizar pago + liquidar facturas
│
├── todo correcto ──► Diario contabilizado
│
└── error de liquidación ──► Se bloquea la operación completa
Esto mezcla dos responsabilidades distintas:
- registrar contablemente un pago válido;
- aplicar ese pago a una o varias transacciones abiertas.
Con volúmenes altos, los bloqueos de registros o una incidencia en una sola transacción pueden convertir la liquidación en un cuello de botella para todo el diario. La nueva característica separa ambos pasos:
Diario de pagos
│
▼
Contabilizar pago
│
├──► Pago contabilizado inmediatamente
│
└──► Relación de liquidación guardada en cola
│
▼
Automatización cada 5 minutos
│
┌───────────┴───────────┐
▼ ▼
Success Partial success / Failed
│
▼
Revisión y reintento manual
El beneficio arquitectónico es el aislamiento del fallo: un problema de liquidación ya no invalida por sí solo la contabilización de un pago correcto.
Disponibilidad y requisitos
Microsoft documenta estos prerrequisitos:
| Requisito | Detalle |
|---|---|
| Versión | Dynamics 365 Finance 10.0.49 |
| Estado | Preview en agosto de 2026 |
| Entornos preview | Desarrollo o pruebas; no producción |
| Activación global | Feature management |
| Activación funcional | Por nombre de diario |
| Tipos compatibles | Diarios de pago de clientes y proveedores |
El calendario vigente de la 10.0.49 es:
| Hito | Fecha publicada por Microsoft |
|---|---|
| Primera preview | 27 de julio de 2026 |
| Última actualización posible de preview | 17 de agosto de 2026 |
| General availability para self-update | 11 de septiembre de 2026 |
| Primera ventana de autoupdate en producción | 2 de octubre de 2026 |
| Segunda ventana de autoupdate en producción | 1 de noviembre de 2026 |
Estas fechas están sujetas a cambios. Además, que la versión 10.0.49 esté disponible no implica que la característica se active sola: Microsoft la publica como una funcionalidad que debe habilitarse y configurarse.
Funcionamiento interno documentado
Cuando se contabiliza un diario compatible con la liquidación diferida:
- Finance contabiliza el pago.
- En lugar de liquidar en la misma operación, guarda la relación entre el pago y las transacciones marcadas.
- Crea una entrada en la cola de liquidaciones.
- Una automatización en segundo plano recoge entradas preparadas cada cinco minutos.
- Si la liquidación termina correctamente, la entrada pasa a
Success. - Si solo se procesa una parte o aparece un error, queda disponible para intervención manual.
La documentación deja claro que la lógica de liquidación no cambia. Continúan aplicándose las reglas existentes para marcar, casar y aplicar transacciones. Por eso esta funcionalidad no debe evaluarse como un nuevo motor de conciliación o matching, sino como un nuevo patrón de ejecución y recuperación.
Estados de la cola
| Estado | Significado operativo |
|---|---|
Prepared | La relación está guardada y espera procesamiento. |
Processing | La liquidación se está ejecutando. |
Partial success | Algunas transacciones se liquidaron y otras siguen pendientes. |
Success | Todas las transacciones marcadas se liquidaron. |
Failed | El intento falló y necesita revisión y reintento manual. |
Hay un matiz crítico: la automatización no vuelve a procesar automáticamente las entradas en estado Failed. Si nadie actúa, permanecen abiertas indefinidamente.
Configuración paso a paso
1. Desplegar la versión en un entorno de prueba
Obtén el paquete preview de la 10.0.49 desde la Shared Asset Library de Lifecycle Services y aplícalo únicamente a un entorno de desarrollo o pruebas. Acepta los términos de preview y valida antes tus personalizaciones y procesos críticos.
2. Activar la característica
- Ve a Workspaces > Feature management.
- Busca Decouple settlement from journal posting.
- Selecciona la característica y pulsa Enable now.
Si posteriormente se desactiva, las liquidaciones que ya estén en la cola continúan procesándose; simplemente dejan de generarse nuevas entradas.
3. Activarla en los nombres de diario necesarios
- Ve a General ledger > Journal setup > Journal names.
- Abre un nombre de diario de pago de cliente o proveedor.
- Activa la opción de liquidación diferida para ese diario.
Microsoft documenta dos controles funcionales:
- Decouple settlement on posting: determina si el posting guarda la liquidación para procesarla por separado.
- Access to Settlement in queue: permite acceder a la página desde la que se revisan y procesan las entradas.
Conviene habilitarlo primero en uno o dos diarios controlados, no en todos a la vez. Así se puede medir el volumen generado, el porcentaje de fallos y la carga operativa real.
4. Supervisar la cola
La página está en Cash and bank management > Periodic tasks > Settlement in queue. Desde ella se puede:
- ejecutar inmediatamente una liquidación con Settle now;
- lanzarla como batch con Settle in batch now;
- abrir las transacciones marcadas;
- cancelar la liquidación pendiente;
- consultar el error y reintentar una entrada fallida.
Cancelar una entrada elimina la marca de liquidación, pero no revierte el pago ya contabilizado. Esta separación es intencionada y debe quedar reflejada en el procedimiento de soporte, especialmente para pagos a proveedores.
Bloqueos y consistencia mientras la entrada está pendiente
Una cola asíncrona reduce el acoplamiento, pero introduce un estado intermedio que hay que gobernar. Mientras una liquidación está en cola:
- las facturas abiertas implicadas quedan bloqueadas para edición manual y liquidación automática;
- el formulario de liquidación muestra un indicador de liquidación diferida;
- el pago ya existe contablemente aunque la factura continúe abierta;
- si la entrada falla, no hay retry automático;
- cancelar la cola no deshace el posting.
Por tanto, el saldo contable de caja puede actualizarse antes que el estado operativo de las partidas abiertas. Informes, integraciones y alertas que asuman que posting y settlement ocurren en el mismo instante deben probarse expresamente.
Seguridad y separación de funciones
La característica no documenta nuevos roles de seguridad estándar. Sí introduce una operación sensible nueva: revisar, cancelar y reintentar liquidaciones ya separadas de un pago contabilizado.
Antes de activarla en producción, revisaría al menos:
- quién puede modificar los nombres de diario y activar la opción;
- quién puede abrir Settlement in queue;
- quién puede cancelar, reintentar o ejecutar en batch;
- cómo queda registrada cada intervención en la auditoría disponible;
- qué equipo recibe y resuelve las entradas
Failed.
No conviene conceder acceso general a la cola solo porque los usuarios ya puedan contabilizar diarios. La capacidad de contabilizar un pago y la de gestionar excepciones de liquidación pueden necesitar responsables distintos.
Plan de pruebas recomendado
La prueba feliz no es suficiente. Prepararía una matriz que cubra:
| Escenario | Resultado esperado |
|---|---|
| Pago de cliente con una factura | Posting inmediato y liquidación posterior correcta. |
| Pago de proveedor con varias facturas | Una entrada trazable y aplicación íntegra. |
| Bloqueo sobre una factura | Pago contabilizado; cola fallida o pendiente sin perder relación. |
| Error en una de varias transacciones | Estado Partial success y remanente identificable. |
| Reintento manual | Solo se procesa lo pendiente. |
| Cancelación | Se elimina la marca; el pago no se revierte. |
| Desactivación de la feature | La cola existente sigue; no se crean nuevas entradas. |
| Integración o informe de partidas abiertas | Tolera el intervalo entre posting y settlement. |
Microsoft señala además que el comportamiento del posting automático y batch de diarios de pago no cambia. Esta limitación debe verificarse con los mecanismos concretos que utilice cada implantación; no hay que asumir que todos los canales de contabilización adoptan el flujo diferido de la misma forma.
Monitorización operativa
Para explotar la característica de forma segura, crearía un cuadro de mando o, como mínimo, una revisión periódica con:
- entradas por estado y antigüedad;
- tiempo medio desde
PreparedhastaSuccess; - entradas
Failedsin responsable; - liquidaciones en
Partial success; - diarios que generan más excepciones;
- pagos contabilizados cuya liquidación permanece pendiente fuera del SLA.
Microsoft no documenta en esta característica una API específica ni nombres de tablas soportados para consultar la cola. Evitaría integraciones directas contra tablas internas hasta disponer de un contrato de extensibilidad oficial. Para automatizar alertas, utilizaría únicamente entidades, eventos o puntos de extensión soportados y confirmados en el entorno objetivo.
Licenciamiento
La documentación de la característica no indica una licencia adicional. El requisito técnico publicado es Dynamics 365 Finance 10.0.49. Aun así, preview, disponibilidad regional y derechos de uso del entorno deben validarse conforme al contrato y al calendario del tenant antes de planificar el despliegue.
Recomendaciones prácticas
- No llevar la preview a producción. Utiliza la 10.0.49 preview para validar procesos y personalizaciones antes de la GA para self-update.
- Activar por fases. Empieza por diarios de bajo riesgo y amplía cuando la operación de la cola esté estabilizada.
- Definir un owner de excepciones. Una entrada
Failedno se reintenta sola. - Separar permisos. Revisa quién puede contabilizar, consultar, cancelar y reintentar.
- Probar consumidores downstream. Los pagos y las partidas abiertas pueden quedar temporalmente desalineados.
- Establecer alertas por antigüedad. Una cola sin vigilancia cambia un bloqueo visible por una deuda operativa silenciosa.
- Documentar la cancelación. Cancelar la liquidación no revierte el pago.
Conclusión
La liquidación diferida de Dynamics 365 Finance 10.0.49 es una mejora pequeña en superficie, pero importante en arquitectura operativa. Separa un posting válido de una liquidación potencialmente problemática, reduce el radio de impacto de bloqueos y errores y aporta una vía explícita de recuperación.
El precio de ese desacoplamiento es una nueva responsabilidad: gobernar la cola. Sin monitorización, ownership y procedimientos de retry, el sistema puede acumular pagos contabilizados pendientes de aplicar. Bien implantada, la funcionalidad convierte un fallo síncrono que bloquea negocio en una excepción aislada, trazable y recuperable.