Mercura + Microsoft Dynamics 365 Finance & Supply Chain Management
Konfigurieren Sie komplexe Produkte, berechnen Sie konfigurationsabhängige Preise, erstellen Sie professionelle Angebote und übertragen Sie das freigegebene Ergebnis an Microsoft Dynamics 365.
Mercura ergänzt Microsoft Dynamics 365 Finance und Supply Chain Management – häufig als Dynamics 365 F&O oder FSCM bezeichnet – um eine vertriebsorientierte CPQ- und Produktkonfigurationsschicht. Dynamics 365 bleibt dabei das führende System für die operativen Prozesse, die dort bereits abgebildet sind.
Verkaufsangebot
Die 30-Sekunden-Antwort
CPQ für Dynamics 365 F&O verbindet Configure, Price, Quote mit Produkt-, Kunden- und Betriebsdaten aus Microsoft Dynamics 365 Finance und Supply Chain Management. Statt Kundenanforderungen manuell in Artikelnummern, Dimensionen, Optionen, Stücklistenpositionen und Preise zu übersetzen, führt Mercura den Anwender durch eine strukturierte Konfiguration und erzeugt ein kommerziell und technisch verwertbares Ergebnis für Dynamics 365.
Kundenanforderung → Produktkonfiguration → Preisfindung → Angebot → Freigabe → Dynamics 365 Angebot/Auftrag → Produktion
Dynamics 365 bleibt ERP- und Supply-Chain-Plattform. Mercura übernimmt die wissensintensiven Vertriebsentscheidungen, die erforderlich sind, bevor ein korrekter Auftrag entstehen kann.
Wichtige Unterscheidung
Microsoft Dynamics 365 Supply Chain Management bietet native Technologien zur Produktkonfiguration. Constraint-basierte Produktkonfigurationsmodelle können Attribute, Constraints, Berechnungen, Komponenten, Stücklistenpositionen und Arbeitsgänge enthalten. Konfigurierbare Produkte können zudem in Verkaufsangeboten und -aufträgen eingesetzt werden. Für viele Hersteller sind diese Funktionen sehr wertvoll.
Die Frage lautet nicht:
Kann Dynamics 365 ein Produkt konfigurieren?
Ja, das kann es.
Die bessere Frage ist:
Wo endet die technische Produktkonfiguration – und wo beginnt der Verkaufsprozess?
Die native Dynamics-Produktkonfiguration ist eng mit Produkt-, Produktions- und ERP-Strukturen verbunden. Mercura CPQ konzentriert sich auf:
Sie müssen sich nicht zwingend zwischen den beiden Konfiguratoren entscheiden. Für viele Unternehmen ist die beste Architektur: Dynamics 365 für operative Produktlogik + Mercura für Vertriebskonfiguration und CPQ.
Systemverantwortung
Eine gute Architektur dupliziert nicht das ERP. Sie definiert klare Verantwortlichkeiten.
ERP und operative Daten
Configure · Price · Quote
Ausführung
Die Architektur richtet sich nach Ihrer Dynamics-365-Implementierung. Mercura verlangt nicht, dass Hersteller ihre Produkte, Stücklisten oder Vertriebsprozesse an ein vordefiniertes CPQ-Datenmodell anpassen.
Native Konfiguration vs. CPQ
Die Dynamics-365-Produktkonfiguration ist eng mit der operativen Produkt- und Fertigungsstruktur verbunden. Mercura CPQ konzentriert sich auf alles, was erforderlich ist, um eine Kundenanforderung in eine verkaufbare, verständliche und kommerziell korrekte Lösung zu übersetzen.
| Anforderung | Dynamics 365 SCM Produktkonfiguration | Mercura CPQ |
|---|---|---|
| Produktstämme und freigegebene Produkte | Kernfunktion | Nutzt bzw. mappt relevante Daten |
| Produktdimensionen | Kernfunktion | Vertriebsorientierte Darstellung möglich |
| Constraint-basierte Konfiguration | Unterstützt | Unterstützt |
| Stücklistenkonfiguration | Kernfunktion für Produktion | Kann kommerzielle/technische Ausgabe berechnen |
| Arbeitsgänge | Kernfunktion | Normalerweise Übergabe an SCM/Engineering |
| Konfiguration aus Auftrag | Kernfunktion | Vertriebsprozess kann vorgelagert werden |
| Guided Selling | Nicht primärer Fokus | Kernfunktion |
| Nicht-technische Vertriebsoberfläche | Nicht primärer Fokus | Kernfunktion |
| Händlerkonfigurator | Zusätzliche Lösung erforderlich | Kernanwendungsfall |
| Kunden-Self-Service | Zusätzliche Lösung erforderlich | Kernanwendungsfall |
| 2D-/3D-Konfiguration | Nicht primärer Fokus | Kernfunktion |
| Konfigurationsabhängige Angebote | ERP-Dokumentprozess | Kernfunktion |
| Komplexe kommerzielle Berechnungen | Abhängig vom ERP-Modell | Kernfunktion |
| Headless / individuelles Frontend | Individuelle Architektur | Native Mercura-Ausrichtung |
| CRM-gesteuerte Konfiguration | Erfordert Integration | Für vernetzte Vertriebsprozesse konzipiert |
Dynamics 365 allein eignet sich, wenn
Ihre Konfiguration primär eine gültige ERP-Produktvariante, Stückliste oder Route bestimmen soll und die Anwender direkt im Dynamics-Prozess arbeiten.
Mercura eignet sich zusätzlich, wenn
Kundenanforderungen zunächst in technische Auswahlmöglichkeiten, Berechnungen, Visualisierung, kommerzielle Optionen oder ein professionelles Angebot übersetzt werden müssen, bevor die ERP-Transaktion erstellt werden kann.
Beide Systeme kombinieren, wenn
In Dynamics 365 bereits wertvolle Produktions- und Konfigurationslogik vorhanden ist, während der Vertrieb eine einfachere und leistungsfähigere Nutzererfahrung benötigt.
Es gibt keine einzige richtige F&O-CPQ-Architektur. Das passende Modell hängt davon ab, wo Ihr Produktwissen bereits liegt.
Sie verfügen bereits über ausgereifte Produktkonfigurationsmodelle in Dynamics 365. Mercura stellt die Vertriebsoberfläche bereit und erfasst die relevanten Eingaben. Die Integration übersetzt diese Eingaben in den vereinbarten Dynamics-Konfigurationsprozess.
Geeignet, wenn:
Mercura enthält die Regeln, mit denen die verkaufbare Lösung bestimmt wird, und erzeugt die Artikel, Mengen, Parameter und kommerziellen Werte für Dynamics 365.
Geeignet, wenn:
Mercura automatisiert die wiederholbare kommerzielle Konfiguration und übergibt strukturierte Parameter an CAD, PLM oder Engineering. Das validierte technische Ergebnis fließt anschließend in Dynamics 365.
Geeignet, wenn:
Mercura kann sich mit Systemen rund um Dynamics 365 integrieren, statt jede Produktlogik in eine einzige Anwendung zu zwingen.
Das Vertriebserlebnis
Ein Kunde kommt selten mit Produktstamm, Konfigurationsdimension, Artikelnummer, Stücklistenvariante, Komponentencode, Route oder Engineering-Attribut. Er kommt mit einer Anforderung.
"Wir benötigen eine Abfüllanlage für 3.000 Flaschen pro Stunde, mit dieser Flaschengröße, automatischer Verschließung und diesen Hygieneanforderungen."
Kapazität, Umgebung, Abmessungen, Installation und Kundenpräferenzen erfassen.
Regeln bestimmen geeignete Produktfamilien, Maschinen und Systeme.
Nur kompatible Optionen, Komponenten und Zubehör anzeigen.
Dimensionen, Mengen, technische Werte, Kosten, Zuschläge und Verkaufspreise berechnen.
Bilder, Zeichnungen oder interaktive 3D-Modelle aktualisieren.
Ein Angebot generieren, das verständlich erklärt, was der Kunde kauft.
Die freigegebene Konfiguration in den vereinbarten Angebots-, Auftrags- und Produktionsprozess übertragen.
Von der Konfiguration zum Angebot
ERP-Daten und Kundendokumente verfolgen unterschiedliche Ziele. Mercura kann aus derselben strukturierten Konfiguration ein Angebot mit den Informationen generieren, die der Kunde tatsächlich braucht. Gleichzeitig kann die Konfiguration eine technischere Struktur für Dynamics 365 erzeugen. Damit muss die verkaufte Lösung nach Annahme des Angebots nicht manuell neu erfasst werden.
In einer breiteren Microsoft-Landschaft kann der Prozess über mehrere Dynamics-Anwendungen laufen.
Das führende System für Kunden-, Angebots- und Produktinformationen hängt von Ihrer Microsoft-Architektur ab. Mercura verlangt nicht, dass der kommerzielle Prozess im ERP beginnt.
Es gibt kein glaubwürdiges Plug-in-in-jede-F&O-Instanz-und-alles-funktioniert-Versprechen. Eine saubere CPQ-Integration beginnt damit zu verstehen, wie Ihre Dynamics-Umgebung tatsächlich arbeitet.
Technische Integration
Dynamics-365-Finance-and-Operations-Apps stellen mehrere Integrationsmuster bereit. Die passende Schnittstelle hängt von Volumen, Latenzanforderungen, vorhandenen Erweiterungen und davon ab, ob der Prozess synchron oder asynchron ist. Der finale Vertrag wird auf Feldebene während der Implementierung vereinbart.
| Daten | Richtung | Typischer Ansatz | Zweck |
|---|---|---|---|
| Freigegebene Produkte | Dynamics 365 → Mercura | Public Data Entity / OData / Integration Layer | ERP-Produktdaten verwenden |
| Produktattribute | Dynamics 365 → Mercura | Data Entity / Mapping | Konfigurationskontext |
| Kunden | Dynamics 365 → Mercura | Public Data Entity / OData | Kundenspezifischer Vertrieb |
| Einheiten und Währungen | Dynamics 365 → Mercura | Data Entities | Konsistente Berechnungen |
| Preisgrundlagen | Dynamics 365 → Mercura | OData / Service | ERP-Preisdaten verwenden |
| Bestandsinformationen | Dynamics 365 → Mercura | OData / Service | Verfügbarkeit |
| Konfiguration | Mercura → Dynamics 365 | Data Entity / Endpoint / Service | Verkaufte Konfiguration erhalten |
| Verkaufsangebot | Mercura → Dynamics 365 | Data Entity / Service | ERP-Angebotsprozess |
| Verkaufsauftrag | Mercura → Dynamics 365 | Data Entity / Service | Auftragsausführung |
| Komponenten / BOM | Mercura → Dynamics 365 | Implementierungsspezifisch | Configure-to-Order |
| Engineering-Parameter | Mercura → Dynamics 365 / CAD / PLM | API-Mapping | Technische Automation |
| Mercura-Referenz | Mercura → Dynamics 365 | Gemapptes Feld | Traceability |
Dynamics 365 stellt mehrere Integrationsmuster bereit, die nicht als austauschbar behandelt werden sollten.
Finance-and-Operations-Apps stellen öffentliche Data Entities über einen OData-REST-Endpunkt bereit.
Das Data Management Framework unterstützt Data Entities und Datenpakete für Import, Export und Integration.
Recurring Integrations können Dokumente oder Dateien zwischen Finance-and-Operations-Apps und externen Anwendungen austauschen.
Nicht jede Dynamics-365-Implementierung lässt sich vollständig über Standard-Public-Entities abbilden. Benutzerdefinierte Services oder Erweiterungen können sinnvoll sein, wenn der Prozess von individuellen Tabellen, Feldern, Business Logic, spezieller Preislogik, Produktkonfigurationslogik, unternehmensspezifischer Auftragserstellung oder Fertigungsprozessen abhängt.
Mercuras Integrationsdesign beginnt mit dem Geschäftsprozess und wählt die passende Dynamics-365-Schnittstelle, statt zu versprechen, dass jede Implementierung eine One-Click-OData-Verbindung ist.
Dynamics-365-finance-and-operations-Integrationen können OAuth 2.0 und Microsoft-Entra-Anwendungsidentitäten für System-zu-System-Kommunikation nutzen. Die genaue Sicherheitsarchitektur hängt vom Integrationsmuster und Ihrer Dynamics-365-Umgebung ab.
Im Projekt definieren wir unter anderem:
Es gibt keine universelle Antwort. Jede Preisregel in CPQ zu duplizieren ist meist genauso unerwünscht wie jede konfigurationsspezifische Berechnung ins ERP zu zwingen.
Mercura bestimmt die Konfiguration, Dynamics liefert den relevanten kommerziellen Preis.
Geeignet, wenn: Das ERP bereits den finalen Preis für den Vertriebsprozess berechnet.
Dynamics liefert Artikel-, Kunden- oder Basispreise. Mercura berechnet konfigurationsabhängige Ergänzungen.
Basismaschine + Breitenzuschlag + Edelstahlfaktor + Motorupgrade + Steuerungspaket + Installation − Kundenrabatt = konfigurierter Verkaufspreis
Geeignet, wenn: ERP-Preise für Standardprodukte gut funktionieren, die konfigurierte Lösung jedoch Formeln und optionsabhängige Preise einführt.
Mercura übernimmt das komplette CPQ-Preismodell und übergibt den freigegebenen Preis an Dynamics.
Geeignet, wenn: Der Preis stark von Konfigurationsparametern, Berechnungen, Kundenanforderungen oder Produktbeziehungen abhängt.
Die Preisverantwortung ist eine Architekturentscheidung, keine Feature-Checkbox.
Für Hersteller ist das Angebot nur die halbe Aufgabe. Der Betrieb muss auch wissen: Was genau haben wir verkauft, und was sollen wir produzieren?
Mercura identifiziert einen bestehenden verkaufs- bzw. fertigungsfähigen Artikel oder eine bestehende Variante.
Ergebnis: Produkt + Konfigurationsreferenz + Menge + Preis
Dynamics 365 bleibt für die operative Produktstruktur verantwortlich. Mercura liefert den Vertriebs- und Konfigurationskontext für den vereinbarten Prozess.
Ergebnis: Konfigurationsparameter → Dynamics-365-Konfiguration
Mercura berechnet Komponenten und Mengen für die verkaufte Konfiguration und übergibt das Ergebnis an den vereinbarten Dynamics-Prozess.
Ergebnis: Hauptprodukt + Komponenten + Mengen + Konfigurationswerte
Mercura erzeugt die kommerzielle Konfiguration und übergibt Parameter an CAD, PLM oder Engineering. Die daraus entstehende technische Struktur wird anschließend in Dynamics verarbeitet.
Ergebnis: CPQ-Parameter → Engineering → finale Produktionsstruktur → Dynamics 365
Implementierung
Die Integration ist ein Arbeitspaket. Der größere Gewinn entsteht, wenn Produkt-, Preis- und Vertriebswissen explizit genug wird, um es zu automatisieren.
Ein ausreichend komplexes Produkt auswählen und Anforderungen, Optionen, Regeln, Preise und erwartete Dynamics-Ausgabe definieren.
Output: Validiertes CPQ-Pilotmodell
Benötigte Data Entities, Produkte, Kunden, Preisgrundlagen, Angebots-/Auftragsobjekte, Produktionsausgaben und Erweiterungen identifizieren.
Output: Feldebene Integrations-Spezifikation
Das Erlebnis für Vertrieb, Engineering, Händler oder Kunden gestalten. Regeln, Visualisierung, Dokumente und Freigaben ergänzen.
Output: Testbarer End-to-End-Vertriebsworkflow
Mercura-Ergebnis mit dem erwarteten Dynamics-365-Transaktions- und Fertigungsoutput vergleichen.
Output: Abgestimmter Quote-to-Order-Prozess
Produktgruppe für Produktgruppe ausrollen und Produkt- sowie Integrations-Governance explizit halten.
Output: Wartbarer CPQ-Rollout
Wo es sich auszahlt
Kapazitäten, Abmessungen, Materialien, Motoren, Steuerungspakete und Zubehör konfigurieren.
Kaufsignal: Der Vertrieb benötigt regelmäßig Engineering zur Validierung eines Angebots.
Anforderungen in Maschine, Modulstruktur, Optionen und Produktionsinput umsetzen.
Kaufsignal: Jeder Auftrag erfordert mehrere technische Entscheidungen, bevor ein Artikel ausgewählt werden kann.
Größen, Materialien, Montageanforderungen, Oberflächen und Installationsoptionen berechnen.
Kaufsignal: Das Endprodukt hängt von Abmessungen und Formeln ab, nicht von einer einfachen SKU-Auswahl.
Mehrere Produkte zu einer technisch durchdachten kommerziellen Lösung konfigurieren.
Kaufsignal: Der Vertrieb verkauft ein System, nicht einen einzelnen Artikel.
Vertriebspartnern kontrollierten Zugang zu Produktwissen, Konfiguration und Preisen geben.
Kaufsignal: Händlerwachstum erhöht die Supportlast für internes Engineering und den Vertrieb.
Die wiederholbaren 80 % der Produktauswahl automatisieren, bevor Engineering die finale technische Arbeit abschließt.
Kaufsignal: Ingenieure verbringen viel Zeit damit, dem Vertrieb dieselben Konfigurationsfragen zu beantworten.
Entscheidungshilfe
Dynamics 365 F&O CPQ verbindet Configure, Price, Quote mit Microsoft Dynamics 365 Finance und Supply Chain Management. Vertriebsteams können Kundenanforderungen in gültige Konfigurationen, Preise und Angebote übersetzen, bevor das freigegebene Ergebnis in Dynamics 365 ausgeführt wird.
Dynamics 365 F&O wird weiterhin häufig als Bezeichnung für die Finance-and-Operations-Plattform verwendet. Microsoft vermarktet heute Dynamics 365 Finance und Dynamics 365 Supply Chain Management als eigenständige Anwendungen. FSCM bzw. F&SCM wird in vielen Implementierungsprojekten als Kurzform für Finance + Supply Chain Management verwendet. Für CPQ-Käufer beschreiben diese Begriffe häufig dieselbe Integrationslandschaft.
Dynamics 365 Supply Chain Management verfügt über native Produktkonfigurationsfunktionen, einschließlich constraint-basierter Konfiguration. Mercura wird insbesondere relevant, wenn zusätzlich Guided Selling, vertriebsorientierte Benutzeroberflächen, Visualisierung, komplexe kommerzielle Logik oder automatisierte Angebotsdokumente benötigt werden.
Microsoft: Übersicht über Produktkonfigurationsmodelle →Der Dynamics-365-Konfigurator hilft vor allem, eine gültige Produkt- und Betriebsstruktur in Supply Chain Management zu definieren. CPQ deckt das breitere Vertriebsproblem ab: Was braucht der Kunde, was können wir verkaufen, was soll es kosten, wie präsentieren wir es, und was soll das ERP ausführen? Unternehmen können beide Systeme unabhängig oder kombiniert nutzen.
Potenziell ja. Die richtige Architektur hängt davon ab, wie diese Modelle aufgebaut sind und wie sie am Vertriebsprozess teilnehmen sollen. Wir klären zuerst, ob native Dynamics-Konfiguration führend bleiben, die Vertriebskonfiguration in Mercura modelliert und in Dynamics gemappt wird oder Verantwortlichkeiten geteilt werden. Ausgereifte ERP-Konfigurationslogik ohne Geschäftsgrund neu aufzubauen, empfehlen wir nicht.
Ja, sofern dies Teil der vereinbarten Integration ist. Produkte, Mengen, Preise, Konfigurationsinformationen und Referenzen können auf die entsprechenden Dynamics-Prozesse gemappt werden. Die genaue Schnittstelle hängt von verfügbaren Data Entities, Erweiterungen und der Auftragsstruktur ab.
Ja. Entscheidend ist jedoch, ob der Prozess eine vorhandene Stückliste auswählt, ein natives Konfigurationsmodell verwendet, Komponenten berechnet oder zunächst Engineering durchläuft. Wir gestalten die Integration um den Fertigungsprozess herum, statt anzunehmen, dass jedes konfigurierbare Produkt eine neue Stückliste erzeugen soll.
In Dynamics 365, in Mercura oder verteilt auf beide Systeme. Für jeden Teil der Preisberechnung sollte eine eindeutige Source of Truth definiert werden.
Nein. Mercura kann interne Anwendungen, Händlerportale, Kundenportale, Website-Konfiguratoren und individuelle Frontends bereitstellen und das Ergebnis anschließend mit Dynamics 365 synchronisieren.
Je nach Architektur beispielsweise über OData, Data Entities, Data Management Framework, Recurring Integrations, REST APIs, benutzerdefinierte Services und Microsoft Entra ID. Die genaue Architektur hängt von Datenvolumen, Latenz, Erweiterungen und Geschäftsprozess ab.
Ja. Dynamics 365 Sales kann CRM und Opportunities verwalten, Mercura Konfiguration und Angebote und Finance & Supply Chain Management die operative Ausführung.
Offizielle technische Ressourcen
Technische Inhalte zuletzt geprüft am 30. August 2026. Validieren Sie Annahmen anhand Ihrer Dynamics-365-Edition, -Version und -Erweiterungen.
Den CPQ-Funktionsumfang erkunden
In Ihrem Prozess erleben
Der beste Weg, Dynamics 365 CPQ zu bewerten, ist kein generischer Feature-Vergleich. Bringen Sie ein repräsentatives Produkt und einen echten Angebotsprozess mit. Wir mappen Kundenanforderung → Konfiguration → Preis → Angebot → Dynamics 365 → Produktion und zeigen, welche Verantwortung in Finance & Supply Chain Management bleiben sollte und welche Prozesse Mercura automatisieren kann.
CPQ-Demo anfordern