🌍 D365 SCM centraliza el pricing multidivisa en una moneda base
🌍 D365 SCM centraliza el pricing multidivisa en una moneda base
Microsoft ha publicado la guía técnica completa para gestionar reglas de precio mediante una moneda base genérica en Unified pricing management. Una empresa puede mantener una regla una sola vez en EUR, USD u otra divisa de referencia y dejar que el motor la convierta a la moneda de la transacción cuando calcula el precio.
No es únicamente una comodidad de mantenimiento. La divisa pasa a formar parte de la selección de reglas, la conversión usa el tipo y la fecha de cambio configurados, y una regla global puede competir o acumularse con otra creada específicamente para la moneda local. Eso convierte la funcionalidad en una decisión de arquitectura de pricing.
Diagrama original. El motor selecciona reglas en la moneda de la transacción y reglas marcadas en la moneda genérica; convierte estas últimas antes de resolver concurrencia, composición y redondeo.
Qué ha cambiado
Sin esta capacidad, una organización que vende el mismo catálogo en cinco monedas suele duplicar acuerdos comerciales, ajustes de margen y descuentos cinco veces. Cada cambio comercial se convierte en cinco cambios de datos maestros, con riesgo de divergencia.
Con la moneda genérica, cada regla puede adoptar uno de estos comportamientos:
| Tipo de regla | Divisa | Marca Include generic currency | Candidata para un pedido en USD |
|---|---|---|---|
| Local | USD | No | Sí |
| Genérica | EUR, si EUR es la moneda genérica | Sí | Sí, después de convertir a USD |
| Otra moneda | GBP | No | No |
| EUR no genérica | EUR | No | No |
La distinción importante es que la regla genérica no es un fallback. El motor la evalúa junto con las reglas en la divisa de la transacción. Después aplica la estructura de precios y las reglas de concurrencia habituales para decidir cuál gana o cómo se acumulan los componentes.
Por tanto, activar esta opción no equivale a decir «usa EUR solo cuando no exista USD». Si conviven ambas reglas, ambas pueden participar en el cálculo.
Disponibilidad y requisitos
La capacidad requiere:
- Dynamics 365 Supply Chain Management o Dynamics 365 Commerce 10.0.47 o posterior;
- el módulo Unified pricing management habilitado en Feature management;
- tipos de cambio configurados entre la moneda genérica y todas las monedas de transacción necesarias.
El plan oficial sitúa la preview pública el 26 de enero de 2026 y la disponibilidad general el 13 de marzo de 2026. SCM 10.0.47 la enumera como habilitada de forma predeterminada, pero esto no elimina dos pasos funcionales: Unified pricing management debe estar activo y Enable generic currency debe configurarse antes de marcar reglas genéricas.
Microsoft no documenta un SKU adicional ni un medidor de consumo específico. Se aplican las licencias normales de Supply Chain Management o Commerce y los requisitos del módulo Unified pricing management.
Cómo funciona el cálculo
En una transacción con moneda USD, el motor construye el conjunto de candidatos con:
- reglas cuya moneda sea USD;
- reglas cuya moneda sea la genérica y tengan activa la marca Include generic currency.
Las reglas en cualquier otra moneda se ignoran. Para cada candidata genérica, el motor:
- obtiene el tipo de cambio definido en Pricing management parameters;
- busca el cambio aplicable en la fecha de pricing;
- convierte el importe a la moneda de la transacción;
- aplica, si está habilitado, el redondeo inteligente de esa moneda;
- deja que la estructura de precios resuelva concurrencia y composición.
El campo Date type de Pricing management parameters decide qué fecha utiliza el motor. Una cotización recalculada para una fecha pasada utiliza el cambio de esa fecha, no necesariamente el actual. Esta dependencia debe tratarse como parte del contrato de precio, especialmente si una cotización se mantiene abierta durante semanas.
Alcance confirmado
La documentación incluye la moneda genérica en:
- precios de acuerdos comerciales de venta;
- ajustes de precio por componente de margen;
- todos los tipos de descuento, incluidos los descuentos por umbral de envío;
- pedidos de venta;
- cotizaciones de venta;
- transacciones de punto de venta.
No todas las reglas necesitan convertirse en globales. Es válido mantener un precio base centralizado y añadir descuentos locales en la moneda del mercado. Precisamente por eso hay que diseñar la concurrencia: una regla local puede complementar o competir con la genérica.
Ejemplo de cálculo
Supongamos esta configuración:
- moneda genérica: EUR;
- tipo de cambio de pricing:
1 EUR = 1,10 USD; - precio genérico del producto:
100 EUR; - redondeo inteligente de USD: al múltiplo comercial configurado;
- precio local alternativo:
112 USD.
El precio genérico genera un candidato de 110 USD antes del redondeo. El precio local genera otro de 112 USD. No debe asumirse que el motor escogerá siempre 110 USD: el resultado depende del modelo de concurrencia, del rango de combinación de atributos y de la estructura de componentes.
El ejemplo sirve para detectar el principal riesgo de adopción. Una configuración que parece correcta al revisar cada regla por separado puede producir un resultado inesperado cuando reglas locales y genéricas entran juntas en el mismo cálculo.
Configuración paso a paso
1. Activar Unified pricing management
En Feature management, localiza:
- módulo: Sales and marketing;
- característica: Unified pricing management.
Actívala primero en un sandbox y valida las personalizaciones de pricing existentes. La característica opcional Unified pricing management pricing rule performance enhancement mejora rendimiento y entidades de importación/exportación, pero no es el interruptor de la moneda genérica.
2. Definir la moneda y la conversión
Abre Pricing management > Setup > Pricing management parameters, pestaña General, y despliega Generic currency and smart rounding.
Configura:
- Enable generic currency: incorpora la divisa como criterio de selección y muestra la marca en las reglas;
- Generic currency: moneda en la que se mantendrán las reglas centrales;
- Exchange rate type: conjunto de tipos de cambio usado exclusivamente por este cálculo;
- Apply smart rounding after currency conversion: redondea el importe convertido según las reglas de la moneda de transacción.
Los campos Generic currency y Exchange rate type deben informarse juntos o dejarse ambos vacíos. Además, se comparten con Accounts receivable parameters: un cambio en una página aparece también en la otra.
3. Mantener tipos de cambio
En General ledger > Currencies > Currency exchange rates:
- selecciona el tipo configurado para pricing;
- crea el par desde la moneda genérica hacia cada moneda de venta;
- define periodos sin huecos ni solapamientos inesperados;
- verifica la unidad del cambio, especialmente en divisas cotizadas por 100 unidades;
- establece un responsable y una frecuencia de actualización.
El motor solo puede convertir si existe un cambio para el par, tipo y fecha correspondientes. La publicación oficial no promete un fallback a otro tipo de cambio; por eso un hueco debe considerarse un error de datos maestros y probarse explícitamente.
4. Crear precios de acuerdo comercial
Para un precio de acuerdo comercial:
- abre Pricing management > During-sales pricing > Sales trade agreement price > Trade agreement journals;
- crea o selecciona un diario y abre Lines;
- asigna a la línea la moneda genérica;
- activa Include generic currency;
- completa dimensiones, atributos, fechas e importe;
- contabiliza el diario.
La casilla solo está disponible cuando la moneda de la línea coincide con la moneda genérica configurada. Tras marcarla, la moneda queda bloqueada en esa línea. El indicador se conserva en el acuerdo activo para facilitar su revisión.
5. Crear ajustes y descuentos
Para ajustes de margen y descuentos:
- abre la página del tipo de regla correspondiente;
- crea una regla o deshabilita una existente para editarla;
- asigna la moneda genérica;
- activa Include generic currency;
- completa atributos, componentes, fechas y condiciones;
- habilita la regla.
La marca no convierte automáticamente todas las reglas que ya estén denominadas en esa divisa. Hay que aplicarla deliberadamente a cada regla que deba operar entre mercados.
Diseño de gobierno recomendado
Antes de migrar miles de reglas, define una matriz de propiedad:
| Elemento | Propietario recomendado | Control |
|---|---|---|
| Moneda y tipo de cambio de pricing | Arquitectura funcional/Finanzas | Cambio aprobado y probado |
| Tipos de cambio | Tesorería o Finanzas | Calendario, fuente y doble revisión |
| Reglas genéricas | Pricing central | Vigencia y alcance global |
| Reglas locales | Responsable de mercado | Justificación de excepción |
| Concurrencia y estructura | Arquitecto de solución | Casos automatizados de regresión |
| Smart rounding | Pricing local | Validación comercial por moneda |
La separación entre mantenimiento de cambios, creación de acuerdos, contabilización de diarios y activación de descuentos reduce el riesgo de que una sola persona altere tanto la referencia como el resultado final.
Plan de migración
Una adopción segura puede dividirse en cinco fases:
- Inventario: exporta reglas por moneda, vigencia, producto, cliente y componente.
- Normalización: identifica duplicados reales; no consolides excepciones locales legítimas.
- Simulación: compara precio actual y futuro en pedidos representativos sin sustituir aún las reglas productivas.
- Piloto: activa una familia de productos y dos monedas con poco volumen.
- Despliegue: migra por oleadas, deshabilita duplicados controladamente y conserva evidencia de resultados.
Evita convertir importes de manera masiva usando el cambio del día si las reglas tienen vigencias históricas o futuras. La regla central debe expresar la política comercial, no ser simplemente una fotografía aritmética del catálogo local.
Matriz mínima de pruebas
Prueba como mínimo:
- transacción en la misma moneda genérica;
- transacción en cada moneda local soportada;
- regla genérica sin equivalente local;
- regla genérica y local concurrentes;
- fecha actual, pasada y futura;
- ausencia de tipo de cambio;
- cambio de tipo dentro de la vigencia de una cotización;
- redondeo activado y desactivado;
- precios, ajustes, descuentos simples, cantidad, mix-and-match y umbral;
- pedido, cotización y POS;
- devolución y corrección de una operación original;
- recálculo después de modificar moneda, fecha o cantidad;
- importación masiva y activación de reglas;
- rendimiento con el volumen real de candidatos.
Guarda no solo el precio final, sino también el desglose de componentes. Dos cálculos pueden terminar en el mismo total por casualidad y haber seleccionado reglas distintas.
Integraciones y extensibilidad
La publicación no anuncia una API nueva. Las integraciones que invocan el motor de Unified pricing management siguen recibiendo el precio en la moneda de la transacción, pero ahora el origen puede ser una regla convertida.
Revisa especialmente:
- motores externos que comparen el importe devuelto con una lista local;
- cachés de precios que no incluyan fecha, moneda o tipo de cambio en su clave;
- exportaciones que necesiten distinguir regla central y excepción local;
- personalizaciones que filtren reglas únicamente por coincidencia exacta de divisa;
- procesos batch que calculen precios antes de actualizar los tipos de cambio.
No dependas de tablas o campos internos no documentados. Si necesitas auditar el origen del cálculo, usa los desgloses y contratos soportados de Unified pricing management y valida su comportamiento en el build implantado.
Seguridad y operación
La superficie de riesgo no está en un nuevo endpoint, sino en el alcance de cada dato maestro. Una modificación en una regla genérica puede afectar simultáneamente pedidos, cotizaciones y POS de varias monedas.
Aplica estas medidas:
- mínimo privilegio para parámetros, tipos de cambio y reglas;
- segregación entre creación, aprobación y activación;
- alertas sobre huecos de cambio y reglas próximas a expirar;
- trazabilidad de cambios de parámetros y diarios contabilizados;
- pruebas con roles reales, no solo con System administrator;
- ventana de despliegue que permita invalidar cachés y recalcular ejemplos.
Limitaciones y matices
- Solo se evalúa una moneda genérica configurada; no es una jerarquía de varias monedas base.
- La regla genérica no sustituye a las reglas locales ni actúa como fallback.
- La conversión introduce volatilidad: el precio local puede cambiar sin modificar la regla comercial.
- El redondeo ocurre después de convertir y puede generar diferencias frente a catálogos calculados fuera de D365.
- La capacidad requiere Unified pricing management; no cambia el comportamiento del motor de precios heredado.
- Commerce sin Unified pricing management continúa sin admitir la moneda genérica en su motor de pricing tradicional.
- La documentación no define un nuevo contrato OData ni una entidad específica para esta función.
- Un cambio de moneda genérica obliga a revisar las reglas marcadas y sus tipos de cambio; no debe tratarse como un ajuste rutinario.
Recomendación práctica
Empieza por un catálogo estable y conserva una pequeña capa de excepciones locales. Antes de activar, modela explícitamente qué ocurre cuando coinciden una regla local y otra genérica. Después, monitoriza tanto el total como el desglose del precio.
El verdadero valor no es ahorrar registros, sino establecer una política central de precios sin perder la capacidad de responder a cada mercado. Si los tipos de cambio, la concurrencia y el redondeo no están gobernados, la simplificación administrativa puede transformarse en variabilidad comercial difícil de explicar.