Überblick und Betrachtung des bisherigen OneOrder Models als Ausgangspunkt der Entwicklung
Überblick
Seit S/4HANA 1709 war das „Customer Management“ als Add-On für S/4HANA verfügbar, allerdings noch mit abgespeckter Funktionalität im Vergleich zum CRM on-premise (lediglich der Service Prozess und das Interaction Center waren verfügbar). Ab S/4HANA 1909 ist das „Customer Management“ nun als S/4HANA Service im S/4 HANA Core integriert und bietet annähernd dieselbe Funktionalität, wie das CRM on-premise.
Auch wenn die altbekannte Web Oberfläche des S/4HANA Service im neuen „Belize“-Kleid ein wenig anders aussieht als im CRM, ist doch hier fast alles beim Alten geblieben. Zumal der „Belize“-Theme, der im S/4HANA vorrangig zur Harmonisierung mit der Fiori 2.0 Oberfläche beitragen soll, auch im CRM on-premise verfügbar ist.
Aber unter der Haube hat sich im Vergleich zum CRM natürlich einiges verändert. Insbesondere das Datenmodell. Wir schauen uns in diesem Blog einmal das OneOrder Framework im S/4 Service genauer an. Dieses ist im CRM der Dreh- und Angelpunkt für die Implementierung von Belegen.
Dieser Blog richtet sich vorrangig an Entwickler and technisch versierte Berater, die aus der CRM Welt in die S4CRM Welt eintauchen möchten.
OneOrder Modell im CRM
Wie der Name schon vermuten lässt, basiert die Abbildung der Belege und deren abhängiger Segmente im CRM (egal, ob Sales, Service, etc.) auf demselben Datenmodell. Dies ist sehr eingängig: Belege bestehen aus einem Kopf und in der Regal aus 0..n Positionen: Für beide Objekte gibt es jeweils eine Administrationstabelle, die den Einstieg ins Datenmodell ermöglicht: CRMD_ORDERADM_H und CRMD_ORDERADM_I. Jede dieser beiden Tabellen hat sog. Extension-Tabellen, die Kardinalität zwischen Administrations- und Extension-Tabelle ist immer 1..1. Kennt man die GUID des Kopf- oder Itemdatensatzes, kann man mit dieser als Schlüssel den zugehörigen Datensatz in der jeweiligen Extension-Tabelle finden. Neben den Extensions gibt es noch sog. Sets.
Diese können sowohl mit dem Belegkopf oder mit den Belegpositionen verknüpft werden. Die Kardinalität zwischen Administrationstabelle und Set-Tabelle ist hierbei 1..n. Um die Sets mit den Administrationstabellen zu verknüpfen kommt nun die Tabelle CRMD_LINK ins Spiel. Auch hier gilt: hat man die GUID des Kopf- oder Itemdatensatzes, kann man mit dieser als Schlüssel in der CRMD_LINK nach den jeweiligen Sets dazu suchen. Die Treffermenge enthält wiederum GUIDs, mit denen man dann in der betreffenden Set-Tabelle, die zugehörigen Datensätze findet.
Oder man nutzt einfach den Standard-Report CRM_ORDER_READ ?
Außerdem gibt es für Analysezwecke im CRM noch die Tabelle CRMD_ORDER_INDEX. Hier werden Daten aus Header und Items, sowie wichtigen Segmenten und Extensions in einer Tabelle dargestellt. Um bei der Analyse eine bessere Performance zu haben und sich den Zugriff auf viele einzelne Tabellen zu sparen, wird hier die doppelte Datenhaltung in Kauf genommen.
Auch diese Tabelle ist im S/4 obsolet. Stattdessen sollte man sich als Anwendungsentwickler eigene CDS Views (Core Data Services – Views auf Datenbanktabellen) anlegen, die lediglich die Daten bereitstellen, die auch für den jeweiligen Anwendungsfall benötigt werden
Im zweiten Teil wird aufgezeigt, wie im Vergleich das OneOrder Model im S4SCRM aufgebaut ist.