Mercura + Microsoft Dynamics 365 Finance & Supply Chain Management
Configurez des produits complexes, calculez une tarification spécifique à la configuration, générez des devis prêts pour le client et transférez le résultat validé dans Dynamics 365.
Mercura ajoute une couche CPQ et de configuration produit orientée vente autour de Microsoft Dynamics 365 Finance and Supply Chain Management — souvent appelé Dynamics 365 F&O ou FSCM — tandis que votre ERP reste responsable des processus opérationnels qu'il gère déjà.
Offre de vente
La réponse en 30 secondes
Le CPQ pour Dynamics 365 F&O relie Configure, Price, Quote (configurer, tarifer, proposer) aux données produit, client et opérationnelles gérées dans Microsoft Dynamics 365 Finance and Supply Chain Management. Au lieu de demander à un commercial de traduire manuellement les exigences client en numéros d'article, dimensions, options, composants de nomenclature et prix, Mercura guide l'utilisateur dans la configuration et produit un résultat commercial structuré que Dynamics 365 peut exécuter.
Exigences client → Configuration produit → Tarification → Devis → Validation → Offre/commande Dynamics 365 → Fabrication
Dynamics 365 reste votre plateforme ERP et supply chain. Mercura gère les décisions commerciales à forte intensité de connaissance qui doivent intervenir avant que la bonne commande puisse être créée.
Distinction importante
Microsoft Dynamics 365 Supply Chain Management inclut des technologies natives de configuration produit. Ses modèles de configuration basés sur des contraintes peuvent contenir des attributs, contraintes, calculs, composants, lignes de nomenclature et opérations de gamme, et les produits configurables peuvent être utilisés sur les offres et commandes de vente. Pour de nombreux fabricants, cette capacité native est précieuse.
La question n'est pas :
Dynamics 365 peut-il configurer un produit ?
Oui.
La vraie question est :
Où la configuration produit doit-elle s'arrêter, et où l'expérience de vente doit-elle commencer ?
La configuration native Dynamics est étroitement liée à la structure produit, fabrication et ERP. Mercura CPQ se concentre sur :
Vous n'avez pas nécessairement à choisir l'un ou l'autre configurateur. Pour de nombreuses entreprises, l'architecture la plus solide est une combinaison de logique produit opérationnelle Dynamics 365 + configuration commerciale Mercura.
Responsabilité système
Une architecture propre ne duplique pas votre ERP. Elle attribue à chaque système une responsabilité claire.
ERP et contexte opérationnel
Configure · Price · Quote
Exécution
L'architecture suit votre implémentation Dynamics 365. Mercura n'exige pas que chaque fabricant restructure ses produits, nomenclatures ou processus de vente autour d'un modèle de données CPQ prédéfini.
Configuration native vs. CPQ
La configuration produit Dynamics 365 est étroitement liée à la structure opérationnelle produit et fabrication. Mercura CPQ se concentre sur tout ce qui est nécessaire pour transformer une exigence client en une solution vendable, compréhensible et commercialement correcte.
| Exigence | Configuration produit Dynamics 365 SCM | Mercura CPQ |
|---|---|---|
| Référentiels produit et produits publiés | Responsabilité principale | Consomme ou mappe les données pertinentes |
| Dimensions produit | Responsabilité principale | Peut exposer les dimensions dans des parcours orientés vente |
| Configuration basée sur des contraintes | Prise en charge | Prise en charge |
| Configuration de nomenclature | Capacité fabrication principale | Peut calculer ou mapper la sortie commerciale/composants |
| Opérations de gamme | Capacité fabrication principale | Généralement confiées à SCM/ingénierie |
| Configuration depuis commande de vente | Capacité principale | Peut créer une expérience de vente en amont |
| Vente guidée à partir des exigences client | Orientée ERP | Capacité CPQ principale |
| UX de vente non technique | Ce n'est pas l'objectif principal | Capacité principale |
| Configurateur revendeur | Nécessite une solution environnante | Cas d'usage principal |
| Self-service client | Nécessite une solution environnante | Cas d'usage principal |
| Configuration visuelle 2D / 3D | Ce n'est pas l'objectif principal | Capacité principale |
| Documents de proposition spécifiques à la configuration | Processus documentaire ERP | Capacité principale |
| Calculs commerciaux complexes | Dépend du modèle ERP | Capacité principale |
| Frontend headless/personnalisé | Nécessite une architecture personnalisée | Approche native Mercura |
| Configuration pilotée par le CRM | Nécessite une intégration | Conçu pour des processus de vente connectés |
Dynamics 365 seul convient quand
Votre configuration sert principalement à déterminer une variante produit ERP valide, une nomenclature et une gamme, et vos utilisateurs sont à l'aise pour configurer les produits dans le processus Dynamics 365.
Mercura convient quand
L'exigence client doit d'abord être traduite en sélections techniques, options commerciales, calculs, visualisation ou proposition client avant que la transaction ERP puisse être créée.
Combiner les deux quand
Dynamics 365 contient déjà une logique de configuration fabrication précieuse qui doit rester faisant autorité, tandis que les ventes ont besoin d'une expérience plus simple et plus puissante autour.
Il n'existe pas une seule architecture CPQ F&O correcte. Le bon modèle dépend de l'endroit où votre savoir produit réside déjà.
Votre entreprise dispose déjà de modèles de configuration produit Dynamics 365 matures. Mercura fournit le parcours de vente et capture les entrées requises. L'intégration convenue traduit ces entrées dans le processus de configuration Dynamics 365, là où c'est techniquement approprié.
Idéal lorsque :
Mercura contient les règles nécessaires pour déterminer la configuration vendable et produit les articles, quantités, paramètres et valeurs commerciales requis par Dynamics 365.
Idéal lorsque :
Mercura automatise la configuration commerciale répétable et transmet des paramètres structurés à l'ingénierie, au CAD, au PLM ou à un autre système technique. Le résultat ingénierie validé poursuit ensuite dans Dynamics 365.
Idéal lorsque :
Mercura peut s'intégrer aux systèmes autour de Dynamics 365 plutôt que de forcer chaque élément de logique produit dans une seule application.
L'expérience de vente
Un client n'arrive généralement pas en connaissant les référentiels produit, dimensions de configuration, numéros d'article, variantes de nomenclature, codes composants, gammes, entrepôts ou attributs ingénierie. Il arrive avec une exigence.
"Nous avons besoin d'un système de remplissage pour 3 000 bouteilles par heure, avec cette taille de bouteille, un bouchage automatique et ces exigences d'hygiène."
Capturer capacité, environnement, dimensions, exigences d'installation et préférences client.
Utiliser les règles pour déterminer quelle famille produit, machine ou système convient.
Présenter uniquement les options, composants et accessoires compatibles.
Calculer dimensions, quantités, valeurs ingénierie, coûts, majorations et prix commerciaux.
Mettre à jour images, dessins ou 3D interactif au fil des changements de configuration.
Générer une proposition qui explique ce que le client achète.
Transférer la configuration validée dans le workflow d'offre, commande et fabrication convenu.
De la configuration au devis
Les données ERP et les informations client servent des objectifs différents. Mercura utilise la configuration structurée pour produire des documents de vente contenant les informations dont le client a réellement besoin. La même configuration peut simultanément produire une sortie plus technique pour Dynamics 365. Cela supprime le besoin de recréer manuellement la solution vendue après l'acceptation du devis.
De nombreux environnements Dynamics enterprise utilisent plus d'une application Dynamics.
Le système de référence exact pour client, offre et informations produit dépend de votre architecture Microsoft. Mercura n'exige pas que le processus commercial commence dans l'ERP.
Il n'existe pas de promesse crédible de brancher un plug-in sur n'importe quelle instance F&O et que tout fonctionne. Une intégration CPQ correcte commence par comprendre comment votre environnement Dynamics fonctionne réellement.
Intégration technique
Les applications finance and operations de Dynamics 365 exposent plusieurs modèles d'intégration. L'interface correcte dépend du volume, des exigences de latence, de vos extensions existantes et du fait que le processus soit synchrone ou asynchrone. Le contrat final est convenu au niveau des champs lors de l'implémentation.
| Donnée | Direction | Approche typique | Objectif |
|---|---|---|---|
| Produits publiés | Dynamics 365 → Mercura | Entité de données publique / OData / couche d'intégration | Réutiliser le référentiel produit ERP |
| Attributs produit | Dynamics 365 → Mercura | Entité de données / intégration mappée | Contexte de configuration |
| Clients | Dynamics 365 → Mercura | Entité de données publique / OData | Vente spécifique au client |
| Unités et devises | Dynamics 365 → Mercura | Entités de données | Calculs commerciaux cohérents |
| Entrées de prix | Dynamics 365 → Mercura | OData, service ou intégration mappée | Réutiliser les données commerciales ERP |
| Contexte inventaire | Dynamics 365 → Mercura | OData/service si nécessaire | Vente tenant compte de la disponibilité |
| Configuration | Mercura → Dynamics 365 | Entité de données, endpoint mappé ou service personnalisé | Préserver ce qui a été vendu |
| Offre de vente | Mercura → Dynamics 365 | Entité de données / service | Poursuivre le flux d'offre ERP |
| Commande de vente | Mercura → Dynamics 365 | Entité de données / service | Créer une commande prête à l'exécution |
| Composants / entrée nomenclature | Mercura → Dynamics 365 | Intégration spécifique à l'implémentation | Transfert configure-to-order |
| Paramètres ingénierie | Mercura → Dynamics 365 / CAD / PLM | Mapping API | Automatisation technique en aval |
| Référence Mercura | Mercura → Dynamics 365 | Champ mappé | Traçabilité de bout en bout |
Dynamics 365 prend en charge plusieurs modèles d'intégration, et ils ne doivent pas être traités comme interchangeables.
Les applications finance and operations exposent des entités de données publiques via un endpoint REST OData.
Le Data Management Framework prend en charge les entités de données et packages de données pour l'import, l'export et l'intégration.
Les intégrations récurrentes peuvent échanger des documents ou fichiers entre les applications finance and operations et des applications externes.
Toutes les implémentations Dynamics 365 ne peuvent pas être représentées par des entités publiques standard. Des services personnalisés ou extensions peuvent être la bonne approche lorsque le processus dépend de tables personnalisées, champs, logique métier, tarification spécialisée, logique de configuration produit, création de commande spécifique à l'entreprise ou processus de fabrication.
La conception d'intégration Mercura part du processus métier et sélectionne l'interface Dynamics 365 appropriée — plutôt que de promettre que chaque implémentation est une connexion OData en un clic.
Les intégrations finance and operations de Dynamics 365 peuvent utiliser OAuth 2.0 et des identités d'application Microsoft Entra pour une communication authentifiée système à système. L'architecture de sécurité exacte dépend du modèle d'intégration et de votre environnement Dynamics 365.
Lors de l'implémentation, nous définissons notamment :
Il n'existe pas de réponse universelle. Dupliquer chaque règle de prix Dynamics 365 dans le CPQ est généralement aussi indésirable que de forcer chaque calcul spécifique à la configuration dans l'ERP.
Mercura détermine la configuration tandis que le prix commercial pertinent provient de Dynamics 365.
Idéal lorsque : L'ERP produit déjà le prix final requis par le processus de vente.
Dynamics 365 fournit les prix article, informations client ou autres entrées commerciales. Mercura calcule la partie spécifique à la configuration.
Machine de base + majoration largeur + facteur inox + moteur haute capacité + pack contrôles + installation − remise client = prix de vente configuré
Idéal lorsque : La tarification ERP fonctionne bien pour les produits standards, mais la solution configurée introduit des formules et une tarification dépendante des options.
Mercura gère le modèle de tarification CPQ complet et envoie le prix de vente validé à Dynamics 365 avec la structure de commande.
Idéal lorsque : Le prix dépend fortement des paramètres de configuration, calculs, exigences client ou relations produit.
La propriété de la tarification est une décision d'architecture, pas une checklist de fonctionnalités CPQ.
Pour les fabricants, produire le devis n'est que la moitié du problème. Les opérations doivent aussi savoir : qu'avons-nous exactement vendu, et que devons-nous fabriquer ?
Mercura identifie un produit ou une variante vendable/fabricable existant.
Résultat : Produit + référence configuration + quantité + prix
La configuration produit Dynamics 365 reste responsable de la génération de la structure opérationnelle produit. Mercura fournit le contexte de configuration orienté vente requis par le processus convenu.
Résultat : Paramètres de configuration → configuration Dynamics 365
Mercura détermine quels composants et quantités appartiennent à la configuration vendue. Le résultat est mappé dans le processus de fabrication Dynamics 365 convenu.
Résultat : Produit parent + composants + quantités + valeurs de configuration
Mercura crée la configuration commerciale et envoie des paramètres structurés au CAD, au PLM ou à l'ingénierie. La structure ingénierie résultante devient la définition de fabrication utilisée en aval.
Résultat : Paramètres CPQ → ingénierie → structure de production finale → Dynamics 365
Implémentation
L'intégration est un flux de travail. Le gain le plus important vient de rendre le savoir produit, tarification et vente suffisamment explicite pour être automatisé.
Choisir un produit contenant assez de complexité pour prouver l'architecture. Capturer exigences client, options, dépendances, calculs, tarification, composants et sortie Dynamics attendue.
Sortie : Modèle CPQ pilote validé
Identifier les entités de données, produits, clients, entrées de prix, objets offre/commande, sortie fabrication et extensions requis.
Sortie : Spécification d'intégration au niveau des champs
Concevoir l'expérience autour des personnes qui l'utilisent : ventes internes, ingénieurs, revendeurs et clients. Ajouter règles, visualisation, documents et validations.
Sortie : Workflow de vente de bout en bout testable
Comparer le résultat de Mercura avec la transaction Dynamics 365 et la structure de fabrication attendues.
Sortie : Processus devis-commande réconcilié
Étendre famille par famille produit tout en gardant explicite la gouvernance produit et intégration.
Sortie : Déploiement CPQ maintenable
Où cela paie
Configurer capacités, dimensions, matériaux, moteurs, packs de contrôle et accessoires.
Signal d'achat: Les ventes ont régulièrement besoin de l'ingénierie pour valider un devis.
Transformer les exigences en machine, structure de modules, options et entrée fabrication.
Signal d'achat: Chaque commande nécessite plusieurs décisions techniques avant qu'un article puisse être sélectionné.
Calculer tailles, matériaux, exigences de montage, finitions et options d'installation.
Signal d'achat: Le produit final dépend de dimensions et formules plutôt que d'une simple sélection SKU.
Configurer plusieurs produits en une solution commerciale ingénierisée.
Signal d'achat: Les ventes vendent réellement un système plutôt qu'un article individuel.
Donner aux distributeurs un accès contrôlé au savoir produit, à la configuration et à la tarification.
Signal d'achat: La croissance des revendeurs augmente la charge de support pour les équipes internes ingénierie et ventes.
Automatiser les 80 % répétables de la sélection produit avant que l'ingénierie finalise le travail technique.
Signal d'achat: Les ingénieurs consacrent un temps significatif à répondre aux mêmes questions de configuration pour les ventes.
Aide à la décision
Le CPQ Dynamics 365 F&O est une solution Configure, Price, Quote connectée aux applications finance and operations de Microsoft Dynamics 365. Il aide les équipes commerciales à transformer les exigences client en configurations, prix et offres valides avant d'envoyer le résultat validé dans Dynamics 365 pour l'exécution commande et opérationnelle.
La terminologie a évolué au fil du temps. Dynamics 365 F&O est encore largement utilisé pour décrire la plateforme et l'écosystème finance and operations de Dynamics 365. Microsoft commercialise actuellement Dynamics 365 Finance et Dynamics 365 Supply Chain Management comme applications distinctes. Certains partenaires d'implémentation et clients utilisent FSCM ou F&SCM comme abréviation de Finance + Supply Chain Management. Pour les acheteurs CPQ, ces termes décrivent souvent le même paysage d'intégration sous-jacent.
Dynamics 365 Supply Chain Management oui. Microsoft prend en charge les variantes prédéfinies, la configuration basée sur les dimensions et la configuration produit basée sur des contraintes. Les modèles de configuration basés sur des contraintes peuvent contenir attributs, contraintes, calculs, composants, lignes de nomenclature et opérations de gamme et peuvent être utilisés lors de la configuration de produits à partir d'offres et commandes de vente. Cela signifie qu'un CPQ externe ne devrait pas automatiquement remplacer le configurateur natif. Mercura est particulièrement pertinent lorsque vous avez aussi besoin de vente guidée, configuration client, visualisation, logique commerciale sophistiquée ou automatisation de devis plus riche.
Microsoft : Vue d'ensemble des modèles de configuration produit →Le configurateur Dynamics 365 aide principalement à définir un produit valide et une structure opérationnelle dans Supply Chain Management. Le CPQ couvre le problème commercial plus large : de quoi le client a-t-il besoin, que pouvons-nous vendre, combien cela doit-il coûter, comment le présenter, et que l'ERP doit-il exécuter. Les entreprises peuvent utiliser l'un ou l'autre système indépendamment ou les combiner.
Potentiellement oui. L'architecture correcte dépend de la structure de ces modèles et de la façon dont ils doivent participer au processus de vente. Nous déterminons d'abord si la meilleure approche est de garder la configuration Dynamics native faisant autorité, de modéliser la configuration commerciale dans Mercura et de mapper la sortie vers Dynamics, ou de répartir les responsabilités entre les deux. Nous ne recommandons pas de reconstruire une logique de configuration ERP mature sans raison métier.
Oui, lorsque cela est inclus dans l'intégration convenue. Mercura peut mapper une configuration validée dans le processus d'offre ou de commande de vente Dynamics 365 pertinent, y compris références, produits, quantités, valeurs commerciales et informations de configuration. L'interface exacte dépend de vos entités de données, extensions et structure de commande disponibles.
Oui, mais envoyer une nomenclature peut signifier plusieurs choses différentes dans Dynamics 365. L'implémentation doit établir si la configuration vendue doit sélectionner une variante existante, déclencher un modèle de configuration produit existant, référencer une nomenclature existante, créer des données composants spécifiques à la configuration, ou alimenter l'ingénierie avant que la nomenclature finale existe. Nous concevons l'intégration autour du processus de fabrication plutôt que de supposer que chaque produit configurable doit créer une nouvelle nomenclature.
Elle peut rester dans Dynamics 365, être répartie entre Dynamics 365 et Mercura, ou être calculée dans Mercura. Le bon choix dépend du fait que votre tarification soit principalement basée sur l'ERP/client ou sur la configuration.
Non. Mercura peut alimenter des applications de vente internes, des workflows connectés à Dynamics, des portails revendeurs, des portails clients, des configurateurs web et des applications personnalisées. Le même moteur de configuration peut servir différents canaux tandis que Dynamics 365 reste le backend opérationnel.
Les technologies d'intégration Microsoft courantes incluent OData et entités de données publiques, Data Management Framework, API REST, intégrations récurrentes, services personnalisés et extensions, et authentification Microsoft Entra ID. L'architecture exacte dépend des volumes de données, exigences de latence, extensions et processus métier.
Oui. Dans une architecture Microsoft plus large, Dynamics 365 Sales peut gérer l'activité CRM et les opportunités, Mercura peut gérer la configuration et les devis, et Finance & Supply Chain Management peut gérer la commande, la fabrication et les processus financiers en aval.
Ressources techniques officielles
Contenu technique révisé pour la dernière fois le 30 août 2026. Validez les hypothèses par rapport à votre édition, version et extensions Dynamics 365.
Explorez la pile de capacités
Voyez-le sur votre processus
Le moyen le plus rapide d'évaluer le CPQ Dynamics 365 n'est pas avec une checklist générique de fonctionnalités. Apportez un produit représentatif et un processus de devis réel. Nous mapperons exigence client → configuration → tarification → devis → Dynamics 365 → fabrication et vous montrerons quelles responsabilités doivent rester dans Finance & Supply Chain Management et lesquelles Mercura peut automatiser.
Demander une démonstration CPQ