Lesefassung aus einem fiktiven Unternehmensszenario. Der Wortlaut stammt unverändert aus dem vollständigen Original.
Für Salesforce und Dynamics liegt ein plausibler Entwurf vor, der eine stabile Geschäftstransaktion über Wiederholungen hinweg verfolgt und unklare ERP-Ergebnisse vor einer erneuten Anlage prüft. Dieser E3-Entwurf trägt die Auswahl; er ist noch nicht umgesetzt oder getestet.
Business Central erzeugt den Auftrag in beiden Optionen. Beide Wege benötigen dort dieselbe kontrollierte Prüfung und eindeutige Vorgangsführung. Der CRM-Wechsel allein beseitigt dieses Risiko daher nicht.
Im Ausgangsstand sind fünf doppelte ERP-Aufträge in zwölf Monaten und elf fehlende CRM-Rückmeldungen in einem Jahr vorgegeben. Bei unklarem Ausgang wird teilweise manuell im ERP geprüft.
Business Central prüft externalDocumentNumber nicht auf Eindeutigkeit. Salesforce und Microsoft stellen Bausteine für Identitäten, Erweiterungen und Wiederholungen bereit. Diese belegen die grundsätzliche Gestaltungsmöglichkeit; die gemeinsame Transaktionskontrolle entsteht erst im konkreten Entwurf.
Aus Kernfelds vorgegebenen Vorfällen und den dokumentierten Herstellergrenzen leiten wir die Anforderung ab, den fachlichen Geschäftsvorgang und sein bereits erreichtes Ergebnis eindeutig zu verfolgen. Die folgende Kontrollarchitektur ist unser analytischer E3-Entwurf.
BusinessTransactionID. Eine neue Ereigniszustellung erhält keine neue Geschäftstransaktion.Das Register und sein eindeutiger Zugriff sind vorgeschlagene E3-Architektur. Die konkrete AL-Tabelle, Schlüssel, Sperr-/Transaktionsgrenzen und parallele Ausführung müssen spezifiziert und später geprüft werden.
Ein Timeout kann bedeuten, dass nur die Antwort verloren ging. Deshalb muss die Fortsetzung vom nachgewiesenen Zustand abhängen.
Register und Auftrag über die Geschäftstransaktions-ID prüfen. Ist der Auftrag vorhanden, seine ID übernehmen und die Rückmeldung fortsetzen. Kann seine Abwesenheit nicht eindeutig festgestellt werden, bleibt der Vorgang in manueller Klärung.
Nur die Rückmeldung an das CRM wiederholen. Der ERP-Auftrag wird dabei nicht erneut erzeugt.
Am letzten sicheren Checkpoint fortsetzen. Bestätigte Teile erhalten ihren Zustand und werden nicht neu erzeugt.
Stoppen und gezielt korrigieren beziehungsweise eskalieren. Eine endlose technische Wiederholung löst diesen Fehler nicht.
Ein persistenter CRM-Transaktionszustand und Apex führen Kennung, Fehlerklasse, Checkpoint und Rückmeldung. Die Business-Central-Erweiterung führt das gemeinsame ERP-Transaktionsregister.
SC-01 / SC-03 · analytischer EntwurfDataverse hält den Transaktionszustand. Ein Plug-in beziehungsweise expliziter Koordinationsbaustein führt Prüfung und Fortsetzung; Business Central benötigt dasselbe ERP-Register. Die Standard-Synchronisation allein zählt nicht als Wiederanlaufnachweis.
SC-02 / SC-04 · analytischer EntwurfG4/G5 sind für beide Optionen auf der Auswahlstufe plausibel geschlossen. Ein vollständiger, fachlich bestätigter Daten-, Zustands- und Wiederanlaufvertrag bleibt vor Vertragsbindung offen (CM-01). Umsetzung (E4), repräsentative Fehler- und Paralleltests (E5) und die spätere Betriebsbeobachtung (E6) liegen noch nicht vor.
Vor Vertragsbindung müssen die Verantwortlichen das konkrete E3-Design prüfen und bestätigen. Danach werden auf der umgesetzten Version insbesondere parallele Wiederholung, verlorene Antworten, Teilfehler und getrennte CRM-Rückmeldung tatsächlich getestet.
Dynamics 365 Sales brächte eine CRM-Datenmigration, den Neuaufbau der direkten ERP-Kopplung und ein neues Betriebsmodell mit sich. Ein ausreichender kompensierender Nutzen ist aktuell nicht belegt.
Der zusätzliche Umstellungsaufwand wird nicht als kostenloser Bestandteil von „integrierter Standardanbindung“ behandelt.
Dynamics bleibt als mögliche Alternative erhalten; ein technischer Ausschluss ist nicht belegt.